You have watched this feature die before. A tool you use every day ships an update, a banner announces the new AI assistant, and you try it once. It summarizes a page you had already read, or proposes a rewrite you did not ask for, and you never open the panel again. Every product category collected a graveyard of these features in the last few years, and most failed the same way: the team added AI before deciding which job the AI was hired to do.
For most builds the real question is not whether to use AI but where to use it, because AI can do several different jobs and each one behaves differently.
AI can hold four distinct roles in a build, and the role decides what it costs you and how it can fail.
Keep the roles separate and you stay out of that graveyard.
The four roles AI can play in a build
Sort any AI feature by asking who the AI works for, you or your user, and when it runs, while you build or while people use the product. Each role below has a shipped product that shows it in pure form.
Role one: AI writes the code. You describe what you want, a tool generates the code, and you review and ship it. Vercel's v0 lives here, since writing working code from a prompt is its whole pitch. This AI sits on your side of the keyboard, and by the time anyone else touches the product its output is ordinary code.
Role two: AI generates content for your user at runtime. Runtime means while someone is in the product. The user acts, your product calls a model over an API, the round trip from APIs, how systems talk to each other, and the result renders on their screen. Notion's AI holds this role, writing and editing inside the document while the user watches.
Role three: AI automates work behind the scenes. The model runs as one step in your backend, on a schedule or a trigger, with nobody watching. Granola holds this role in meetings, turning the audio into notes in the background while you talk, so the notes are waiting when the meeting ends.
Role four: AI is the product. Strip the model out and there is nothing left to sell. ChatGPT is the defining example, since the conversation with the model is the entire product and the app around it is packaging. This is the hardest role to compete in, because your user can reach the same model straight from the provider, so a build here needs a sharp answer to what it adds.
One product can hold several roles, but a single feature holds exactly one, and the feature is where the sorting pays off. A meeting tool producing notes in the background holds role three, while the same tool answering a question on demand holds role two. Naming the role tells you what a feature costs and how it fails.
The role decides the cost and the risk
- Role one bills once, while you build. You pay for a coding tool like any subscription, the meter stops when the session ends, and a wrong answer lands on your own machine, where review catches it before any user exists. This is the cheapest and safest seat AI will ever hold in your build.
- Role two bills on every use, in front of an audience. Each request costs money, so the bill scales with usage and spikes with it, and a wrong, slow, or strange answer plays out live on a real person's screen. Quality problems in this role are product problems.
- Role three bills on a schedule you set. Batch size and frequency are knobs you control, so the spend is predictable, and mistakes land in stored output where a check can catch them. The danger is that nobody runs the check, and a bad job can fill a database with wrong labels for weeks.
- Role four bills like role two, on everything. Every interaction is a model call, so the model bill is your entire cost structure and any model failure is a product failure.
Per-request prices change too often to print here, so we speak in orders of magnitude and leave current numbers to the providers' pricing pages and the Playbook's cost section.
Where AI does not fit
It is at least as valuable to know where a model is the wrong tool.
- Deterministic work with one correct answer. Code computes totals, conversions, and date arithmetic exactly, instantly, and for free, while a model produces them approximately and for money.
- Lookups that must be exact. An order status, an account balance, or the record that matches a search has one right value. A model generates plausible text, and plausible is the wrong standard when only the actual record will do.
- Decisions where a confident wrong answer is expensive. Legal, medical, financial, or irreversible calls need a final word from a person or from deterministic code, because a model returns wrong answers in the same fluent register as right ones.
The cheapest test is to imagine the product with the AI removed. If nothing meaningful degrades, the AI was decoration, and the graveyard in the opening is full of features that failed exactly this test. The Playbook's When not to use AI section goes deeper.
Run the four-role audit
Take the build you chose in Find your build and pick its shape and write the four roles as four lines. Mark each line yes or no, and give every yes one sentence naming what specifically the AI would do. A vague yes rarely survives being written as a sentence.
Nearly every build in this course gets a yes on role one, since a model writing the code is what lets a non-engineer ship at all. Most builds add one more yes among the other roles, matching the problem they solve. Some audits come back with role one as the only yes, which is a respectable result, not a failure of ambition; every build we have shipped starts with that yes, and more than one stops there. Keep the four lines, because they go straight into your plan in Write your Build Plan and start the build.
Try it now
No setup: Classify two AI products you already use. For each, name the feature you actually touch and assign it a role by asking whether the model wrote code for a builder, generates content while you wait, works behind the scenes, or is the product itself. Then run the four-role audit on your own build, with yes or no on each line and one sentence per yes on what the AI would do. Expect at least one product to hold two roles, and expect your own audit to be shorter than you assumed.
With your tools: Open Claude Code, paste your audit, and ask: "For each yes, estimate the monthly cost at small scale, list the assumptions behind the estimate, and name which yes is most likely to be wrong in front of a user." Challenge the assumptions that do not match your build. In Codex or Cursor the move is the same: paste the audit into the sidebar chat and ask for the cost and the risk of each yes. If your tools are not set up yet, the Setup Clinic gets you there in one sitting.
Chapter Summary
- The question is not whether to use AI but where, since most builds have a few good places for it and many bad ones.
- AI can hold one of four roles in a build: it writes the code, it generates content for users while they wait, it works behind the scenes, or it is the whole product.
- One product can hold several roles, but a single feature holds exactly one, so sort feature by feature.
- The role sets the bill. Role one stops costing you when you stop building, while the runtime roles charge you on every use.
- The role also sets how a feature fails. A mistake in role one lands on your own machine, while a mistake in a runtime role plays out live in front of a real user.
- AI is the wrong tool for exact math, exact lookups, and high-stakes calls, because it returns a confident wrong answer in the same voice as a right one.
- To test whether a feature needs AI at all, picture the product with it removed. If nothing real gets worse, the AI was decoration.
- Run the four-role audit on your build: yes or no on each line, one sentence per yes. Treat a yes in every role as a warning, and know that role one alone is an honest result.
- Role one is the seat you will operate every day, and Working with AI as a builder teaches you how to run it well.
Sources
- Vercel v0 product documentation, 2026.
- Notion AI help documentation, 2026.
- Granola product documentation, 2026.