Where AI actually fits

If there is a single lesson in this course we suspect you will think about for years, it is this one.

The question "should I use AI in my build" has the same shape as "should I use water in my soup." Yes, obviously, and the interesting question is how. Today is about how.

The four roles AI can play in a build

AI shows up in software in basically four ways. Each one is the right answer for a different kind of need, and confusing them is what gives you the "we added AI to it" products that nobody uses.

Role 1. AI writes the code.

This is the role most readers of this course are already familiar with. You sit with Claude or Cursor, you describe what you want, AI writes the actual code, you review and ship. The end user of the product never sees the AI, the AI is just on your side of the keyboard.

Use this role when: you are the builder and you want to ship faster. Almost everyone in this course will use AI in this role for every build, because the alternative (writing the code yourself as a non-engineer) is so much slower.

Role 2. AI generates content at runtime, for the user.

The user does something in your product, your code calls an AI API (Day 10), the AI returns some text or an image or a summary, and your code displays it to the user.

Examples: a meeting-notes app that summarizes the transcript, a writing assistant that suggests edits, a customer-support tool that drafts a reply for the human to review.

Use this role when: you are doing something that genuinely needs language understanding or content generation in the moment, on real user input. Watch the costs, because every call costs you money, and bursty user behavior can make those costs unpredictable (Day 12).

Role 3. AI automates workflows behind the scenes.

Your code runs on a schedule (a cron job, Day 9), processes a batch of data, uses AI as one step in the pipeline, and produces some output (a report, an updated database, a Slack message). The user does not directly trigger the AI, the AI just does its job in the background.

Examples: a daily digest that summarizes your team's PRs, a weekly report that categorizes customer feedback, an internal tool that classifies incoming support tickets.

Use this role when: there is a repetitive, language-intensive task you would happily delegate to a tireless intern, and the output does not need to be perfect (because no real-time user is waiting on it).

Role 4. AI is the product itself.

The whole point of the product IS the AI, and the rest of the app is mostly a wrapper around a model. The classic examples are ChatGPT itself and most of the apps that the App Store now refers to as "AI assistants."

Use this role when: your differentiation comes from a specific model, prompt, or fine-tuning, and you have a real reason to believe that what you can do is meaningfully different from what someone could get by going directly to the model provider themselves. This is the hardest role to win in, because the providers are usually a click away.

Where AI specifically does not fit

It is at least as valuable to know when AI is the wrong tool.

• When the task is deterministic and has a known correct answer. Math, currency conversion, deterministic lookups. Use code, not a model.
• When the cost of a wrong answer is high and not easily caught. Legal advice, medical diagnosis, financial decisions where the user assumes the output is trustworthy. AI can assist a qualified human reviewer here, but it should not be the final word.
• When the user's expectation is precision. A search bar that should return exact matches, a calculator, a database query interface.
• When you are mostly using AI for the marketing optics. If removing the AI would not meaningfully degrade the product, it probably should not be in there.

A short exercise for your build

For the idea you chose on Day 15 and the shape you chose on Day 16, write down each of the four roles. For each one, write down whether your build needs it (yes or no) and, if yes, what specifically the AI would do.

Most builds will have a yes for Role 1 (you using AI to write the code) and one of Roles 2, 3, or 4 (depending on whether the AI shows up at runtime, in the background, or as the whole product). A small number will have no AI in any user-facing role at all, which is also a perfectly fine answer.

Forward references

Day 18 covers the meta-skill almost no other AI course teaches: how to actually collaborate with AI as the builder (context engineering, tool selection, the iteration loop). Day 19 returns to AI use through the guardrail lens, especially around cost and verification. Day 21 brings the whole thing together when you sketch and submit your Build Plan.

Day 17 wrap

The thing you can now say plainly. AI shows up in builds in four roles (writing the code, generating content at runtime, automating workflows in the background, being the product itself). Each is the right answer for a different need.

The thing you can now do. For your build, mark which of the four roles AI plays and where it explicitly does not.

The guardrail to remember. "We added AI to it" is not a product strategy. The right question is which specific role AI plays in solving the specific problem you picked on Day 15.

See you on Day 18, where we cover the meta-skill of actually working with AI.