The loop: intent → generate → review → refine
Everything in this book comes back to one cycle. Internalize it.
The loop spins until the output meets your bar — and review is the gate it has to pass through every time:
┌──────────────────────────────────────────────┐
│ │
▼ │
┌────────┐ ┌──────────┐ ┌────────┐ ┌──────────┐
│ INTENT │ ─▶ │ GENERATE │ ─▶ │ REVIEW │ ─▶ │ REFINE │
│ (spec) │ │ (AI) │ │ (you) │ │ (you) │
└────────┘ └──────────┘ └───┬────┘ └──────────┘
│
pass? ▼
┌──────────┐
│ SHIP │
└──────────┘
- Intent. State what you want and the constraints that matter — inputs, outputs, cases, the stack, the style. Vague intent gets vague code.
- Generate. Let the model write the implementation. Don't hand-hold the syntax; describe the behavior.
- Review. Read what came back. Does it actually do the thing? Does it handle the empty list, the null, the failed network call? Is it the simplest version that works?
- Refine. Point at what's wrong, give a concrete correction, and regenerate. Repeat until it meets your bar.
Most beginners skip step 3. They generate, it runs, they move on. Then it breaks in production on the case they never described. The review step is where the engineering happens.
Here's what a good first in this loop looks like:
Write a TypeScript function `parseDuration(input: string): number`
that converts strings like "1h30m", "45s", "2d" into total seconds.
Requirements:
- Support units: d (days), h (hours), m (minutes), s (seconds).
- Multiple units can combine: "1h30m" = 5400.
- Reject invalid input (empty, unknown units, negative) by throwing
an Error with a clear message.
- No external libraries. Include 5 unit tests covering the edge cases.
Show the function and tests only.
Notice the structure: a precise signature, explicit rules, the edge cases called out, the constraints stated, and a request for tests. You're not hoping the model guesses right — you're removing the ambiguity that produces bad guesses.
The refine step is just as much a skill as the first prompt. Vague feedback gets vague fixes. Compare these two corrections:
Bad: "this is wrong, fix it"
Good: "parseDuration('1h30m') returns 90 instead of 5400 — you're
summing the numbers but ignoring the unit multipliers. Multiply
each value by its unit's seconds (d=86400, h=3600, m=60, s=1)
before summing. Also add a test for the combined case '2d3h'."
The good version names the symptom, the cause, and the fix. You're reviewing like you would a colleague's — and the more precisely you point, the fewer rounds you spend. Each loop should converge. If you find yourself going in circles, that's a signal your intent was underspecified; stop regenerating and rewrite the spec instead.