Wire the model into your build

You arrive with a model chosen and a Proof Table of five real inputs from Choose the model you ship. One hour with a coding assistant turns those into a working feature, and rather than describe that hour in the abstract, we replay ours: the session that wired the fridge feature into FuelTheFam. The drill runs the same hour on your build.

The project file: ten lines before the first ask

A session starts from zero: the assistant is handed no record of your product, your users, or your past decisions, and generic defaults fill any gap you leave. So the hour opens with a project file. Claude Code reads a file named CLAUDE.md at the project root at the start of every session, and AGENTS.md is the same convention in other tools. Ours, the day the fridge feature went in, held ten lines:

# FuelTheFam
FuelTheFam is a family nutrition app for busy parents.
A parent photographs the open fridge and a shopping list comes back
while they wait; a photo of a dinner plate becomes a nutrition estimate.
The model holds one runtime job per feature; everything else is code.
The API key stays on the server. Nothing sent to a browser carries it.
An unreadable photo gets a retake request, never a generated guess.
A confident nutrition number for an ambiguous plate must never ship.
Logging a full day of meals must stay under three minutes.
Keep every change small enough to read in one sitting.

That is what the product is, who it serves, the model's job, and what must never ship; then the feature's one-pager went in, pasted whole. The payoff showed at once: every plan and diff was generated against our constraints, and no sign-in screen ever appeared. A correction that repeats across sessions moves into the file too, so it is made once.

A project file is context the tool reads before your first word, turning your constraints from things you repeat into things every session starts from.

The ask, printed

With the file in place, the ask took one message:

Add the fridge feature. When a user submits a photo, send it from our server to the multimodal model named in the config, using the prompt in prompts/fridge.txt exactly as written, and return JSON matching the one-field items schema. Show me the plan before you touch any files.

It names the trigger, the route, the prompt, the structure from Get output you can build on, and a checkpoint. We approved its plan, and the first run, Proof Table photo one, our fridge holding milk, a dozen eggs, and some spinach, drew three rows.

One trip around the loop: find the flaw in the draft

A working demo is where the builder in the opening scene stopped checking, so this is where the loop starts. Verifying is two acts: running a real input, which photo one just covered, and reading the diff, which is where this draft failed. Twelve lines into the new route file sat our credential, pasted into the code:

const API_KEY = "sk-live-8f2..."; // fridge model key

The call still ran on our server, exactly as the file demanded, but a key written into source travels with the file: into git history, onto every laptop that clones it, and into any repository it gets pushed to, where scrapers hunt for this string. The correction went back the way a good bug report reads, naming the symptom, the place, and the behavior we wanted:

The API key is hard-coded in the new route file. Move it to an environment variable, and confirm no other file in the diff contains the key.

The second pass moved the key, and rerunning photo one drew the same three rows; the Proof Table runs after every change, so a fix cannot quietly break what worked.

The first response is a draft; the working feature comes from the loop, describe, watch the plan, verify by running and reading, correct with specifics, one trip per change.

The obvious objection is that the assistant wrote the code and the code ran, so it works. Both are true and the conclusion still fails: "it ran" and "it works" are different claims, because a pasted key works identically to a well-kept one until the code leaves your machine, and the assistant's summary of its own work reads equally confident either way. The next chapter is entirely about reading what came back: the tree, the files, the diff.

The wiring that makes it shippable

A correct answer can still be unshippable: the wait unmanaged, the failure unplanned, the meter uncapped. The rest of the hour went to that wiring, one short ask each.

The call stays on the server. The photo posts to our route, the server attaches the key from its environment and calls the model, and nothing sent to a browser ever carries the credential; the argument was settled in the backend, where a product's real work happens.

The answer streams. A spinner is a stall; items arriving one by one are progress. One ask turned streaming on: the parent at the open fridge watches milk appear while eggs are still on the way.

The failure is written before it happens. When the model reports a photo unreadable, the screen asks for a retake, never a guessed list, because a generated list reads exactly like a real one. Beside it went the timeout: at ten seconds with nothing streamed, the wait ends and a retry is offered.

The meter gets a ceiling. One list costs a fraction of a cent at mid-tier rates, so the cap at the provider console is for the night a retry bug calls the model in a loop, turning that bill from a card limit into lunch money.

The Model Spec's wiring fields, filled

Each decision is a field in the Model Spec, the one-page product document this part fills as decisions get made (blank at the Model Spec starter; not OpenAI's Model Spec, a policy document about model behavior). The hour filled the wiring fields:

• Route: the photo posts to /api/fridge-list; the server holds the key and makes the call.
• Cap: monthly, at the provider console, sized so a runaway loop stays boring.
• Fallback: an unreadable photo gets a retake request; the feature never guesses.
• Timeout: items stream within seconds; at ten, stop waiting and offer a retry.

The spec is signed later, when you write your Build Plan and ship; today you just fill in the entries above.

Try it now

The paper path takes about twenty-five minutes and spends nothing; the tooled path takes about an hour and spends cents. You arrive with the last drill's result, your chosen model and a Proof Table of five real inputs, and you leave with the feature wired into your build, call server-side, streaming on, fallback written, spend cap set, and the Model Spec's wiring fields filled: route, cap, fallback, timeout.

No setup: Walk our printed session end to end on paper. Mark the file line that would have prevented the opening scene and the words in our correction that told the second pass where to land, then fill the wiring fields for your build: where the call runs, the cap, the move for unusable input, and what your user sees at second ten.

With your tools: Write your ten-line project file (what the product is, who it serves, the model's job, what must never ship), paste your one-pager as the first message, and give the ask with a plan checkpoint. Verify both ways: run Proof Table input one and read the diff, then correct once with specifics. Ask for the wiring, streaming, fallback, timeout, cap, and rerun all five Proof Table inputs. Same move in Codex or Cursor: the file is AGENTS.md, and the hour is identical. If nothing is installed, the Setup Clinic gets you running.

Chapter Summary

• The first hour is a script you can replay: project file, one-pager, the ask, one trip around the loop, then the wiring.
• Ten lines in a CLAUDE.md-style file, covering what the product is, who it serves, the model's job, and what must never ship, mean every plan is generated against your constraints instead of generic defaults; AGENTS.md is the same convention in other tools.
• When a correction repeats across sessions, move it into the project file, so it is made once.
• The loop is describe, watch the plan, verify, correct with specifics, and verifying means both running a real input and reading the diff.
• Code that runs is not code that works: our draft passed every photo while the API key sat pasted in the source, a flaw no run would ever show.
• Write corrections like bug reports, naming the symptom, the place, and the behavior you want.
• Rerun the Proof Table after every change, so a fix is proven not to break what already worked.
• The wiring is four decisions: the call server-side with the key in an environment variable, streaming so the wait reads as progress, a fallback that asks for a retake instead of guessing, and a spend cap sized for the failure case.
• Those decisions fill the Model Spec's wiring fields, route, cap, fallback, and timeout, and the spec is signed later with your Build Plan.
• The gap between "it ran" and "it works" is where you go next: Review what the AI built.

Sources

• Anthropic documentation for Claude Code project memory files, CLAUDE.md (last verified July 2026).
• The AGENTS.md open convention documentation (last verified July 2026).
• OpenAI, Model Spec, the model-behavior policy document distinguished from this course's Model Spec artifact (last verified July 2026).
• OpenAI and Anthropic documentation for streaming responses and organization spend limits (last verified July 2026).
• FuelTheFam (fuelthefam.com), our family nutrition app; the session dissected in this chapter wired the fridge feature that ships there.