The model is a part, not a coder

The assistant that built the box is not in the box

The sting in that transcript is how well the build had gone. You put the box together in an afternoon with a coding assistant: you described the feature, it wrote the form, the endpoint, and the model call, and you read every line before accepting it. Weeks of working that way build real trust, and the trust is earned: every output crossed your desk before it could cost anything.

The assistant does not ship, though. By the time Priya typed her question, its work had become ordinary code, and the thing that answered her was a different system: a model your product calls over an API while she waits, carrying a one-line prompt ("You are a helpful assistant for our store. Answer customer questions.") and no reviewer between its output and her screen.

The AI that helped you build your product and the AI inside your product are two different systems: the first hands everything it produces to you, and the second hands everything it produces to your users.

The difference between them is not the meter. Coding assistants are metered too, and an agent left running on a long task keeps billing after you stand up. What separates the two systems is who receives the output: everything the build-time assistant produces reaches you, a reviewer with context and a veto, while everything the run-time model produces reaches whoever asked. Priya read her answer with none of your context and all of your brand's authority.

Our fridge feature, end to end

We ship the second kind of AI ourselves. FuelTheFam is our family nutrition app, and its fridge feature runs a model in exactly the position the luggage box did: you snap a photo of your fridge, the app sends the photo to a multimodal model, and a shopping list comes back while you wait. Everything that burned the box is visible here, so we will take the feature apart.

It bills per use. The photo call runs the route fixed in the backend chapter: the app sends the photo to our server, and our server attaches the key and calls the model. One list costs a fraction of a cent at current mid-tier rates, and the figure matters less than what multiplies it: the meter runs on our account every time anyone snaps a photo, so the bill tracks our users' behavior rather than our effort and climbs fastest when the feature succeeds. Rates move too quickly for prose, so hard numbers live in the Playbook's cost section.

It ships unreviewed. Nobody on our team reads a shopping list before the user sees it; a human in that gap would erase the point of a list that arrives while you stand at the open fridge. So the review happens before ship, in how the call is built: the fridge prompt tells the model to return only items visible in the photo, and an unreadable photo gets a retake request instead of a guess. The clearest catch during the build came when we asked for a bare list of items and the model returned "Sure! It looks like you have milk, a dozen eggs, and some spinach in there," a reply that reads perfectly to a person and breaks any code expecting a list. Elsewhere in the same app the stakes climb: a confidently wrong nutrition estimate on a photographed dinner plate tells a parent their underfed kid is fine, so estimates like that are blocked from ever appearing. Once nobody stands between the model and the user, the review has to be designed into the product itself.

It answers strangers. While we built the feature, we chose every input: our own fridges, decent light, groceries we recognized. In production the input belongs to whoever taps the button, which can mean a fridge photographed in the dark, a shelf of unlabeled leftovers, or a photo with no fridge in it. The model produces a response to whatever it is handed, and at run time we no longer choose what it is handed. The retake rule closes that gap, a product decision rather than a model setting.

The obvious objection is that the two systems are often the same technology, sometimes literally the same model, so trust earned with one should carry to the other. The reason it does not has nothing to do with the model. During the build, every output passed through a reviewer who could reject it, so the system you learned to trust was never the model alone; it was the model plus you, and shipping deletes the plus-you. The same class of model that writes an endpoint cleanly under review returned our "Sure! It looks like..." reply the moment code, rather than our eyes, was the reader.

The trust you built steering your coding assistant does not transfer to the model inside your product, because that trust was earned in a loop with a reviewer in it, and your product runs the same loop without one.

A part you specify, not a coder you hired

This is why the title insists on the word part. "Adding AI" sounds like hiring the assistant, but what you actually do is wire a specific model into a specific spot in your build, hand it a narrow job, and own what it sends to strangers, the same way you own what your database returns. A part can be specified, and the chapters ahead do that in a fixed order: make your first call, write the prompt as instructions rather than wishes, force the output into a structure code can parse, then attach the context and the tools the model lacks, with fine-tuning last because each earlier rung is cheaper and easier to undo. The fridge feature runs on a prompt and a one-field schema, and most first features need no more.

Try it now

The drill takes fifteen minutes and spends nothing. It arrives with the one-pager v1 you wrote in Find your build and give the model a job, and it leaves behind the Component Spec: two lines added to that one-pager, one stating the model's job in your build and who calls it, one stating who pays per call and what ships to a stranger unreviewed.

No setup: Write the fridge feature's spec first, as a worked example: "A multimodal model turns a fridge photo into a shopping list; our server calls it on every snap, key held server-side" and "Each call bills our account a fraction of a cent, and the finished list reaches the user with nobody reading it first." Then open your one-pager and write the same two lines for your own build. If an answer will not come (the caller, the payer, what ships unreviewed), write the question in its place; an honest blank beats a guess.

With your tools: Open Claude Code in the folder that holds your one-pager, paste your two lines, and ask it to attack them: "Here is the model's job in my build, who calls it, who pays, and what ships unreviewed. What am I missing?" Revise until both lines survive the argument. Same move in Codex or Cursor: paste the lines into the sidebar chat and ask for the attack. If nothing is installed yet, the Setup Clinic gets you to a working session.

Chapter Summary

• The AI that helped you build your product and the AI inside your product are two different systems: the first hands its output to you, the second hands its output to your users.
• The meter does not separate them, because assistants bill by usage too and a background agent keeps billing after you walk away; what separates them is who receives the output.
• A run-time model bills your account on every use, so the bill tracks user behavior and climbs fastest when the feature succeeds.
• Run-time output ships unreviewed: nobody on our team reads a FuelTheFam shopping list before the user does, so review has to be designed into the product before ship.
• Run-time input comes from strangers, so decide what the model must never send and make the product enforce it, the way our fridge feature asks for a retake instead of guessing.
• A fluent, confident reply is not evidence of a correct one; the model returns wrong answers in the same register as right ones, under your logo.
• The trust you earned steering a coding assistant came from a loop with a reviewer in it, and it does not transfer to your product's loop, which runs without one.
• Your Component Spec now records, in two lines on the one-pager, the model's job, who calls it, who pays per call, and what ships to a stranger unreviewed.
• Next, Make your first model call puts a real request and a real reply on your own screen.

Sources

• FAA PackSafe guidance on lithium batteries: spare lithium-ion batteries and power banks are prohibited from checked baggage and must travel in the cabin (last verified July 2026).
• Anthropic and OpenAI developer and pricing documentation on metered API usage and usage-billed coding agents (last verified July 2026).
• FuelTheFam (fuelthefam.com), our live family nutrition app; the fridge feature dissected in this chapter ships there.