AI
AI Writer-Reviewer Pattern for Coding Agents
August 20269 min read
It is a coding workflow that splits work into two roles: one agent writes the change, and a separate agent reviews only the diff against the acceptance criteria in a fresh context. Because the reviewer never sees the writer's reasoning, it evaluates what the code actually does rather than what the author intended, which surfaces bugs a single agent would miss.
A single session carries every assumption and shortcut from the writing phase into the review, so it tends to confirm its own work rather than challenge it. A fresh reviewer starts cold with no sunk cost in the approach, which is exactly what lets it catch a wrong design or a subtle bug the writer is blind to.
Define the reviewer as a subagent with read-only tools such as read, grep, and glob, and a system prompt that tells it to judge the diff against the acceptance criteria and return a ranked list of concrete findings. Give it only the diff and the requirements, not the writer's chat history, so its independence is preserved.
Yes, it roughly doubles the token spend on a change because the review is a second pass over the work. That cost is trivial for security-sensitive code, migrations, or public API changes, where a missed bug is expensive, but it is overkill for a one-line tweak where a human glance is faster and cheaper.
Give the loop a clear exit: it ends on a clean pass from the reviewer or when it hits a fixed iteration cap. The orchestrator should also triage findings before each new write, routing only real issues back to the writer and dropping false positives, so the loop converges instead of thrashing on noise.
Key Takeaway
The writer-reviewer pattern splits AI coding into two roles: one agent drafts the change, a second reviews only the diff against acceptance criteria in a fresh context. Because the reviewer never sees the author's reasoning, it catches bugs the writer is blind to, turning a single hopeful pass into a checked, self-correcting loop.
Ask an AI agent to write a feature and it will hand you code that looks finished. Looks is the trap. The same model that wrote a subtle off-by-one is the worst possible judge of whether that off-by-one exists, because it is reasoning from the same flawed assumptions that produced it.
The writer-reviewer pattern breaks that blind spot in two. One agent writes; a separate agent, with a clean context and a checklist, reviews. This guide explains why the split works, how to wire it up in an agentic coding tool, and where it quietly fails if you are not careful.
An agent's context is its worldview. When a single session writes code and then reviews it, the review inherits every assumption, shortcut, and misread requirement from the writing phase. It is graded homework marked by the same student who wrote it.
A fresh reviewer changes the incentives. Give a second agent only the diff and the acceptance criteria, and it starts cold, with none of the writer's justifications. That distance is exactly what makes it useful:
In practice the reviewer is a subagent with read-only tools and a sharp system prompt. The writer produces a diff; the orchestrator hands that diff plus the original requirements to the reviewer; the reviewer returns a ranked list of concrete issues, each with a file, a line, and a fix.
A minimal reviewer definition keeps the agent honest and its output actionable:
---
name: diff-reviewer
description: Reviews a diff against acceptance criteria, returns ranked findings
tools: Read, Grep, Glob
---
You review a diff, not a plan. You are given the diff and the
acceptance criteria only. Return a ranked list of concrete issues,
each as: file:line — severity — one-line fix. Judge the change
against the criteria, not against how you would have written it.
If the diff meets every criterion, say PASS and stop.Force the reviewer to return structured output: a ranked list with file, line, severity, and a one-line fix. An agent told to review the code writes an essay; an agent told to return findings writes something the writer can act on in the very next turn.
The pattern only earns its cost when the review feeds back into another write. That feedback loop is the engine that makes the two roles worth running:
Because the two roles are isolated, they can run as separate sessions in separate git worktrees, so a review of one change overlaps with the writing of the next. Anthropic's own multi-agent work leans on this orchestrator-worker shape, where a lead agent coordinates specialists that each own a slice of the task.
The orchestrator's job is contract-writing: state the objective, the boundaries, and the exact output shape for each role. Treat every delegation like an API call, and the parallel version stays debuggable instead of turning into a crowd of agents talking past each other.
A reviewer with no teeth is theater. If the orchestrator forwards every finding uncritically, the writer thrashes on false positives and burns tokens; if it ignores the findings, the review was wasted. Someone, human or orchestrator, has to triage which findings are real before the loop spins again.
The pattern roughly doubles your token spend on a change, so reserve it for work where a missed bug is expensive:
The writer-reviewer pattern is less a feature than a discipline: never let the agent that wrote the code be the only one that grades it. Start with a single read-only reviewer subagent on your riskiest changes, keep its output structured, and let the loop turn a hopeful draft into a checked one.