The spec is what you review now
For well-specified work, the spec is what gets approved, not the diff behind it. Get the spec wrong and you've automated the mistake instead of catching it.
Also available as a standalone Playbook →
Somewhere in the last two years, review started happening at the wrong end of the work.
Most teams still review a diff. An agent produces two hundred lines, a human reads them, approves or doesn't.
The reading is the whole safety net.
That was fine when code was slow and expensive to make and reading it was the cheap part. Not anymore. The code is cheap now. Reading it carefully, at agent volume, is the expensive part.
It's also the part already breaking under the queue.
So spec-driven development moves review earlier. To the one artefact that determines what gets built.
The spec. Not a ticket. Not three lines in a Slack thread. Not a paragraph of vibes an agent is expected to read charitably and fill in around.
A real spec is something an agent can execute against and a human can verify against, independently. The behaviour expected. The inputs and outputs that prove it. The invariants that must hold, the cases that must not break.
Get that right and the diff underneath stops being where the risk lives.
What actually gets approved
Work that's genuinely well-specified, where "did this satisfy it" has one honest answer, gets the spec reviewed and approved.
Not the diff behind it.
If the spec is met and the evals pass, reading every line by hand is redundant work dressed up as rigour. You're re-checking an answer a machine already verified. One that doesn't get tired and doesn't skim.
That's a real change from reading every agent-authored line as though it came from a fast junior, which is still right elsewhere in this track.
It doesn't contradict that lesson. It narrows it.
The junior model still applies to ambiguous work. The kind with no clean spec, where the judgment call is happening inside the diff because nobody wrote it down anywhere else first. Spec-driven review is for the other bucket. The well-bounded slice where the thinking already happened, on paper, before the agent touched anything.
Where the risk actually moved
This doesn't remove risk. It relocates it.
Entirely onto the spec, and that's the part worth being honest about. A vague spec approved quickly produces confidently wrong code quickly, at whatever volume the agent can manage.
A spec that holds up has a specific form.
States inputs and outputs, not intentions. Names the cases that must not break, especially the ugly edge case everyone forgets until it's in production. And it's falsifiable: someone reading it cold can say, definitively, whether an implementation satisfies it, without asking the author what they meant.
If a spec needs its author in the room, it isn't a spec yet. It's a paragraph doing an impression of one.
When it fails, it tends to fail on the same four things: constraints, exit criteria, measurements, boundaries. Vague on those and the agent will fill the gaps itself, confidently, in whatever direction the training data leans.
Evals close the loop, review doesn't disappear
Spec-only review only works if something checks the code against the spec before a human sees it.
Same discipline as evals, not vibes. A real test, run automatically, that fails loudly when the implementation drifts from what the spec promised.
Skip that and "the spec is what we review" quietly becomes "nothing gets reviewed." Different policy. Much worse. Same name.
Diff review doesn't disappear. It becomes exception-based rather than default.
Evals fail. The change touches something with real blast radius however clean the spec looked. The spec turns out ambiguous enough that two reasonable people read it differently. Any of those, somebody reads the actual code.
Set that bar lower than feels comfortable at first. The cost of getting it wrong is a spec nobody verified, shipped at agent speed.
The muscle this actually requires
The shift underneath is real and it isn't small.
Writing a spec precise enough to review instead of a diff is a harder skill than most orgs currently practise. Closer to a formal test plan than a Jira ticket.
Teams that skip to "the agent will figure it out from context" haven't adopted spec-driven development. They've deleted the review step and called the deletion a process.
Start narrow. Pick the class of work with the cleanest specs already: API contracts, data migrations, anything with a well-understood form. Run spec-only review there first. Everything else stays under the old model until the spec-writing habit is actually good enough to trust.