Review Is the Most Important Handoff

Part 2 ended with a graded plan waiting at a gate: a breakdown the agent produced in minutes, annotated with its own confessions about where it is vague, incomplete or entangled. Review is what happens at that gate. It is the phase where the human finally arrives — and it is deliberately the only phase built around what the human does, because it exists to supply the one input the rest of the workflow cannot manufacture: judgement about what the organisation actually means. Everything the agent will build, and everything Validation will later measure, descends from what leaves this phase. That is why I call its exit the most important handoff in the workflow, and this part is the case for that claim.

Judgement the agent cannot supply

The work of Review is directional, and the direction comes straight from the three scores: raise clarity, raise completion, minimise complexity. Each is a concrete editing activity, not a vibe.

Raising clarity means rewriting ambiguous work packages until each one could be handed to a stranger and executed without a single question coming back. That is the test I apply line by line: not “do I understand this?” — I wrote half the context, of course I do — but "would someone with no access to my head understand this?". An agent is that stranger, permanently.

Raising completion means surfacing what the plan never mentions: the missing requirements, the failure paths nobody wrote down, the error handling, the non-functional concerns — performance, observability, the rules that only apply on the last day of the month. The agent's completion score points at where it knows it is missing something; the human's job is also the harder half, spotting the absences the agent is not even aware of. Domain knowledge lives here. No amount of context engineering fully substitutes for the person who remembers why the last rota system failed its audit.

Minimising complexity means splitting entangled work packages into smaller, independent units with clean input and output boundaries — because every hidden dependency in the plan becomes a runtime surprise in Execution, and runtime surprises inside an unattended agent run are exactly what this workflow exists to prevent.

Three old practices, one new gate

None of this is novel activity, and pretending otherwise would be bad history. Review is three well-worn practices, aimed at a new kind of artefact.

It is backlog refinement from Scrum — the ongoing work of revising and decomposing backlog items, which the Scrum Guide has called refinement since the 2013 edition retired the older name “grooming”. The parallel is close and instructive: refinement is where the team applies domain knowledge the backlog's author did not have. In PREVC the author is an agent, which makes the knowledge gap wider and the refinement correspondingly more valuable, but the move is the same one Scrum teams have practised for years.

It is the design review from traditional software lifecycles — the formal checkpoint where architects interrogate a proposed approach before implementation begins: is this complete, consistent, actually buildable? Review asks those questions of an agent-generated breakdown instead of an architect's design document.

And it is the Check step of PDCA — Shewhart's improvement cycle, the one Deming popularised — applied a phase early. Classic PDCA checks after doing; Review checks the plan itself before anything is done, which project managers know as plan validation: verify the plan is sound before committing resources to it. When the resources commit themselves at machine speed the moment the gate opens, checking early stops being prudence and becomes the whole game.

What the spec-driven people already learnt

There is independent support for putting the human here, and it comes from the practice this workflow operationalises. Thoughtworks named spec-driven development one of 2025's key new AI-assisted engineering practices, and their framing is about feedback: a spec gives you shorter loops — “shorter and effective ones than would otherwise be possible with pure vibe coding”, in their words — because problems surface in a document you can edit rather than in code you must unwind.

Two of their observations matter specifically for Review, and both reward precision. First, Thoughtworks is careful with its verbs: structured specs “help reduce” model hallucinations — reduce, not prevent — and the same piece concedes that “Spec drift and hallucination are inherently difficult to avoid”. Anyone selling you a workflow that prevents hallucination is selling; what a reviewed spec buys is fewer of them and a baseline for catching the rest, which is exactly the honest claim this phase makes. Second, reviewing and validating a specification is, as Thoughtworks puts it, “usually an iterative process that requires a human in the loop”. Review is that sentence, given a place in the workflow and an exit condition. The human in the loop is not a regrettable cost to be optimised away later; in this phase, the human is the feature.

Rewriting package two

Back to Rosterly, the invented rota service from part 2, whose plan flagged its own weakest point: eligibility rules, scored clarity 5, completion 4. Here is what that package looked like arriving at the gate, and what it looked like leaving:

## Before (agent's draft, clarity 5, completion 4)
2. Eligibility rules
   2.1 Check the requesting staff member is qualified for the shift
   2.2 Check rest-period and maximum-hours rules are not violated

## After (reviewed)
2. Eligibility rules
   2.1 Qualification check - a swap target must hold every skill tag on
       the shift definition; skill tags come from the staff profile
       service, read-only, cached for the session
   2.2 Working-time check - apply the tenant's configured rule set (rules
       live in tenant settings, not in code); reject the swap with a
       named reason when a rule fails
   2.3 NEW - both checks run against the rota as it would be *after* the
       swap, not the current rota
   2.4 ESCALATE - if a tenant has no configured rule set, do not guess a
       default; surface it and stop

The edit demonstrates all three directions at once. Clarity: “qualified” now has an operational definition and a named data source. Completion: 2.3 adds the requirement the agent had no way to know — that eligibility is evaluated against the post-swap world — which is precisely the kind of domain fact that sinks implementations silently. Complexity: the vague coupling to “qualification data” became a read-only, cacheable dependency with a boundary. And 2.4 is something else again, which brings me to the half of Review that is not editing.

Encoding intent at the gate

That ESCALATE line is intent, not specification. Review is also where the human encodes the answers to questions the plan never asks out loud: when speed conflicts with quality, which wins, and at what threshold? When the agent meets ambiguity, should it ask or decide? Which trade-offs are acceptable, and which decision boundaries must it never cross on its own authority?

These are not rules in the mechanical sense — they are encoded judgement, the organisation's values translated into constraints an agent can actually follow during Execution. The distinction matters because rules cover the situations you predicted, and an unattended agent will spend most of its interesting time in situations you did not. A trade-off hierarchy and a set of escalation boundaries keep an agent aligned even off the map. Review is the natural place to write them because this is the moment you are already thinking about what could go wrong — every weakness the scores exposed is a prompt for a boundary decision.

The handoff everything hangs on

Review ends when the human is satisfied the breakdown is clear enough, complete enough and simple enough for an agent to execute reliably — three judgements, made deliberately, at a gate. What passes through is no longer a plan. It is the specification: the document Execution implements against and Validation later measures against.

That dual role is the entire argument for this part's title. Review's output is the single most important handoff in the workflow, because it is the only artefact that defines both what will be built and what “correctly built” will mean. A defect that slips through this gate is not one defect; it is two — it will be faithfully implemented by Execution, and then faithfully confirmed by Validation, because both phases inherit the same flawed baseline. Nothing downstream can catch an error in its own measuring stick. Spend your best hour of the cycle here; it is the hour with compound interest. That claim is mine, from my own practice, and the rest of this series either earns it or does not.

The gate opens, the specification crosses, and the agent begins. What happens next is not a single pass of code generation — it is a loop, with three steps and a temper. Next, the Code-Review-Simplify loop.