In Class 36 you learned to give a coding agent a job it can actually finish — a bounded task with acceptance checks and a clear "do not touch" boundary. That solves the starting problem. It leaves open the judging problem: when fast generation produces a usable result, and when it only moves uncertainty downstream.

Two loops, neither one the villain

Watch two builders work with the same coding model and you will see two different loops.

Fast improvisation
ask → generate → run → patch → patch the patch

Deliberate AI-assisted delivery
define → inspect → plan → change → review → test → release/hold

The first loop optimizes for how quickly something appears on screen. The second optimizes for how confidently the change keeps its promise once real people, real data, or real money are involved.

Both loops can be appropriate. The mistake is treating the first loop's output as the second loop's result — calling code "done" because it appeared fast and ran once.

Professional work looks slower at the start because it spends time where the improvisation loop skips: defining the promise, inspecting the current system, reviewing the diff, and collecting evidence. That time is not overhead. It is the work that prevents a week of debugging later.

What decides the pace

Three variables decide which loop fits:

1. Cost of being wrong. A typo on a draft page costs minutes. A wrong source date on a published research brief, a broken payment total, or a leaked API key costs trust, money, or security. 2. Number of people affected. Only you see the experiment on your laptop. Dozens or thousands depend on the customer-facing feature. 3. How often the work must change later. A throwaway mockup will be deleted Friday. A scheduled system will be extended, debugged, and maintained for months.

When all three are low, go fast. When any one of them is high, slow the loop down deliberately — smaller scope, tighter review, stronger evidence.

Delivery means promise plus proof

Here is the definition this class will use:

Delivery is a change that meets its promised behavior with enough evidence for the current stakes.

Not "code appeared." Not "the demo worked once on my machine." A delivered change names what it promised and shows the proof that matches the consequence of failure.

A promise without evidence is a claim. Evidence without a promise is activity. Delivery is both, sized to the risk.

The same builder, two different jobs

Take the two running examples side by side.

Job A: a one-off event landing page for the neighborhood events finder. "Summer Block Party — Saturday, 2 PM, Elm Park." One page, static details, no accounts, no payments, no stored personal data. The promise is small: the page shows the right details and looks decent on a phone. The evidence is small too: open the preview, check the date, time, and location, click the links. Speed is the right optimization. If something is slightly off, you edit and redeploy in minutes.

Job B: scheduled briefs for the research dashboard. Every weekday morning the system gathers approved public sources for each company on a user's watchlist and produces a source-linked brief. Now the promise is load-bearing: sources must be fresh and correctly dated, private watchlists must stay private, background work must run while the owner sleeps, paid data calls must stay inside budget, and every claim carries a citation. "It rendered once" proves almost nothing. Delivery needs the data path checked, error states exercised, costs bounded, and a recovery plan written down.

Same builder, same model, opposite delivery bars — because the stakes are opposite. The landing page can legitimately ship on a preview. The scheduled briefs cannot ship without checks, and that is not bureaucracy. The system acquired more responsibility, so it earned more proof.

This is also why a project graduates feature by feature. The dashboard can keep a quickly built marketing page while its sign-in, data ingestion, and scheduled jobs each receive the deliberate loop. You do not rewrite everything. You match each feature's proof to its consequence.

Why demos deceive

A demo hides at least seven costs that arrive later:

• Untested error paths. The happy path worked. Missing dates, empty watchlists, rate-limited APIs, and failed background runs were never tried.
• Unclear ownership. Nobody wrote down who decides, who fixes, and what "correct" means — so every future question becomes an investigation.
• Slow debugging. A patch on top of a patch on top of a guess takes longer to untangle than the original feature took to generate.
• Support burden. Every unhandled edge becomes a message from a confused user.
• Paid waste. An unreviewed loop can call a priced API thousands of times before anyone notices.
• Lost context. The reasoning lived in a chat transcript nobody saved, so the next session starts from zero.
• Brittle changes. The next feature breaks the first one because no test pinned the promised behavior down.

Each of these is invisible in the screenshot and obvious in the second week. The deliberate loop exists to move that discovery earlier, when fixes are cheap.

Choose the pace on purpose

Read the table as a starting position, not a prison. A visual experiment that starts storing emails has moved rows. A customer feature with a trivial blast radius can move up. The professional habit is noticing the move and upgrading the evidence to match.

"Professional" does not mean big-company process for its own sake. It means matching proof and control to consequences — no more, no less.

Practical exercise: price one fast change

Pick one "quick" AI change from your own past — a page, a script, a dashboard tweak.

1. Write where it was fast: what did the model generate in minutes? 2. Write where time was later spent: debugging, support messages, rework, surprise API charges, lost context. 3. Name the single check that would have moved that cost earlier: an acceptance check, an error-state walkthrough, a review of the changed files, a test of one edge case.

Keep it to half a page. You are training the judgment this whole class depends on: speed is measured at delivery, not at first render.

Finish line: a DELIVERY-DEFINITION.md next to the project stating the change, the stakes, the evidence required, and the named decision maker who calls it done:

# Delivery definition: Saturday events filter

- Change: filter the events list by "This Saturday."
- Stakes: public page, no accounts, no payments — moderate.
- Evidence: preview on phone and desktop; empty-Saturday message shown; no other filters broken.
- Decided by: Darin, before Saturday publish.

Verify: can a stranger read the file and say what "done" means without asking you? If not, the promise is still vague.

Common failure mode: writing the evidence list after shipping and backfilling it with what happened to work. Recovery: write the promise and the proof before the model edits anything.

Check your understanding

1. Write both loops from memory. What does the deliberate loop add, and what does each addition buy? 2. Name the three variables that decide the right pace — and apply them to the events landing page versus scheduled briefs. 3. In one sentence, what is delivery? 4. List three hidden demo costs and the earlier check that catches each. 5. Your internal helper just gained user accounts. Which table row did it leave, and what new evidence does it owe?