Most teams use AI coding assistants reactively: a suggestion appears, they accept or reject it, and that is the whole process. This works for trivial completions and fails for anything consequential, because there is no structure governing when to trust the model and when to override it. What is missing is a repeatable loop that assigns each stage of the work to whichever party — human or model — is best at it.
The Draft, Review, Verify loop is that structure. It is a simple three-stage cycle, but its value is in the explicit handoffs between stages and in the principle behind those handoffs: the model drafts, the human reviews, and an objective check verifies. Each stage has a clear owner, and the loop refuses to let any one party do work it is unsuited for.
This framework is deliberately small. A loop you can hold in your head gets used; an elaborate methodology with a dozen steps gets abandoned by the second sprint. Three stages, repeated, is enough to capture most of the discipline that separates productive assistant use from chaotic use.
The Core Principle
The loop assigns work by capability. The model is fast at producing plausible code and weak at judgment. The human is slow at typing and strong at judgment. An automated check is impartial and exhaustive where it applies.
Why Capability-Based Assignment
Every failure mode of AI coding assistants traces to a party doing work it is bad at: the model making architectural decisions, or the human accepting code without review. The loop prevents these by routing each kind of work to the right owner. It is the structural answer to the problems catalogued in Seven Failure Modes That Quietly Wreck AI Pair Programming.
Stage One: Draft
The model produces a first version against a precise specification you provide.
What the Human Does First
Before the model drafts, you define the contract: the interface, the types, the expected behavior, and the edge cases. This front-loaded specification is the single biggest lever on draft quality, because it does the deciding the model cannot do well.
What the Model Does
Given the contract, the model generates an implementation quickly. At this stage, speed is the goal and imperfection is acceptable, because two stages of checking follow.
When to Skip Drafting
For changes where you already know the exact code and typing it is faster than specifying it, skip the model. The loop is a tool, not an obligation.
What a Good Specification Includes
A specification that produces strong drafts covers more than a one-line request. At minimum it names:
- The interface: the function signature, parameter types, and return type.
- The behavior: what the code should do for typical inputs, stated plainly.
- The edge cases: empty inputs, boundary values, and error paths the model tends to skip.
- The constraints: any performance, security, or convention requirements that bound the solution.
Writing this down takes a minute and is the single highest-leverage action in the loop, because it does the deciding the model cannot do and hands the model the part it does well.
Stage Two: Review
A human reads the draft critically, as if reviewing a colleague's pull request.
What Review Catches
Review is where human judgment does its work: checking that the draft matches intent, that it handles the edge cases the contract specified, that it makes no unwarranted architectural assumptions, and that no line is accepted unread. This stage is non-negotiable, which is why drafts must be small enough to review fully.
The Size Constraint
Because review quality falls as draft size rises, the loop enforces small drafts. A draft too large to review in one sitting is too large, full stop. This constraint links directly to the practices in Practices That Earn Trust When Coding With an AI Assistant.
When Review Is Heaviest
For security-sensitive code, architecture, and anything touching multiple services, review carries the most weight, because these are precisely where the model's confident output is most likely to be wrong.
Stage Three: Verify
An objective, automated check confirms the code does what it should.
What Verification Means
Verification is impartial: running the test suite, executing the new tests, dependency scanning, and static analysis. Where review applies human judgment, verification applies machine rigor to the things machines check best.
The Test Caveat
Generated tests are part of verification but must clear review first, because a model that wrote buggy code tends to write tests that pass against the bug. Verification with unreviewed tests is theater. Read them before you trust them.
When Verification Is Light
For pure formatting or comment changes, verification can be minimal. For anything that changes behavior, it is mandatory and automated.
Running the Loop in Practice
The three stages repeat for each unit of work. A typical session is many small loops, not one large pass.
The Cadence
Specify, draft, review, verify, integrate, repeat. Each loop covers a small increment, which keeps review tractable and verification fast. The case study in How One Five-Person Studio Shipped Faster With Coding AI shows a team adopting essentially this cadence after a rough start.
Adapting the Loop
For high-risk work, the review and verify stages expand. For low-risk work, they contract. The loop's shape stays constant; only the weight on each stage shifts with the stakes.
Where the Loop Tends to Break
Knowing the loop's failure points lets you reinforce them before they cost you.
Skipping Specification
The most common breakdown is jumping straight to drafting without specifying the contract first. The draft then targets the model's guess at your intent rather than your actual intent, and review has to reconstruct what should have been stated up front. Discipline at stage one prevents wasted effort at stages two and three.
Rubber-Stamping Review
The second breakdown is treating review as a formality. When drafts grow too large or reviewers trust the model's fluency, review degrades into skimming, and the loop loses the human judgment that justifies it. Keeping drafts small is what keeps review real.
Trusting Generated Tests
The third breakdown is letting unreviewed generated tests stand in for verification. Because a flawed implementation tends to come with tests that pass against the flaw, this turns verification into theater. Reviewing tests before trusting them closes the gap.
Adopting the Loop on a Team
The loop works for an individual immediately, but a team needs a short on-ramp.
Make the Stages Explicit in Review
Have reviewers ask, for any AI-assisted change, whether a contract was specified, whether the diff is small enough to read, and whether tests were reviewed rather than assumed. Encoding the loop into review questions spreads it without a heavy process.
Let the Habits Compound
The loop's stages reinforce one another: specification improves drafts, small drafts enable real review, and real review makes verification meaningful. A team that adopts the stages together sees them compound, which is why partial adoption underperforms full adoption.
Frequently Asked Questions
Is this loop different from normal code review?
It is normal code review with two additions: an explicit specification stage before drafting, and an awareness that the draft's author is a model whose confidence is uncorrelated with correctness. Those additions change how you review.
Does the loop slow things down?
For trivial work, slightly, which is why you can skip stages for trivial work. For consequential work, it is faster overall because it prevents rework that costs far more than the loop's overhead.
Who owns each stage on a team?
The same developer typically runs all three stages for their own work, with a second reviewer for consequential changes. Verification is automated and owned by CI.
How does the loop handle architecture?
It routes architecture to the human in the specification stage and weights review heavily for cross-cutting changes. The model never owns architectural decisions in this loop.
Can the loop be partially automated?
The verify stage is fully automatable and should be. Drafting is the model's job by definition. Only review resists automation, and deliberately so.
What makes this loop reusable across projects?
It assigns work by capability, and the relative capabilities of model, human, and automated check are stable across projects. The specifics change; the assignment principle does not.
Key Takeaways
- The Draft, Review, Verify loop assigns each stage to whichever party is best at it.
- A precise human-written specification before drafting is the biggest lever on quality.
- Review is non-negotiable and requires drafts small enough to read fully.
- Verification applies automated rigor; generated tests must pass review before you trust them.
- Weight on review and verify scales with the stakes of the change.
- A small, memorable loop gets used, where an elaborate methodology gets abandoned.