Why can't one AI agent review its own code reliably?

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.

How do I set up a reviewer agent?

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.

Does the writer-reviewer pattern increase token cost?

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.

How do I stop the review loop from running forever?

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.

AI Writer-Reviewer Pattern for Coding Agents

Q: What is the AI writer-reviewer pattern?

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.

Why one AI agent should never grade its own code, and how a fresh reviewer agent on the diff turns a hopeful draft into a checked, self-correcting loop.

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.

Why one agent cannot check its own work

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:

It reads what the code does, not what the author meant it to do.
It has no sunk cost in the approach, so it will flag a design that should be rewritten rather than patched.
It measures the change against stated criteria, not against the writer's private sense of done.

Wire up the two roles

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.

Close the loop

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:

The writer produces a change and a short summary of what it claims to have done.
The reviewer checks the diff against the acceptance criteria and returns findings, or a clean pass.
The orchestrator routes real findings back to the writer for a fix, and drops false positives.
The loop stops on a clean pass or a fixed iteration cap, so it cannot churn forever.

Run the two roles in parallel

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.

Know when to skip it

The pattern roughly doubles your token spend on a change, so reserve it for work where a missed bug is expensive:

Worth it for security-sensitive code, migrations, and public API changes, where review cost is trivial next to the blast radius of a mistake.
Overkill for a one-line copy tweak or a throwaway script, where a human glance is faster and cheaper than a second agent.
Tune the reviewer model to the stakes: a cheaper model for routine diffs, your strongest model when correctness genuinely matters.

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.

Sources & further reading

Frequently Asked Questions

AI Writer-Reviewer Pattern for Coding Agents

Frequently Asked Questions

AI Writer-Reviewer Pattern for Coding Agents

Why one agent cannot check its own work

Wire up the two roles

Close the loop

Run the two roles in parallel

Know when to skip it

Why one agent cannot check its own work

Wire up the two roles

Close the loop

Run the two roles in parallel

Know when to skip it