The AI Code Review Workflow That Catches What You'd Miss

Playbook

The most dangerous phrase in agentic coding is "done — all tests passing." Agents say it constantly, they say it with total confidence, and a meaningful fraction of the time it is simply false. The tests weren't run, or the wrong tests were run, or the tests pass because the agent deleted the assertion that was failing.

You could catch this by reading every diff yourself. On a 400-line change, at the end of a long day, you won't — not really. What actually works is making review a second agent's job, structured so the reviewer can't inherit the author's blind spots. Here's the workflow we run, step by step, in any harness or none.

The six rules

1. The reviewer is a different model than the author

This is the load-bearing rule. If the same model that wrote the code reviews the code, you get the same blind spots twice: the training-data quirks, the API it habitually misremembers, the pattern it favors whether or not it fits. Worse, a model reviewing its own conversation has already committed to the approach — it has loyalty to the mistake.

Cross the lab line. Code authored by a Claude model gets reviewed by a GPT or Gemini model, and vice versa. Different training runs disagree in useful places, and disagreement is precisely what you're paying a reviewer for. In multi-agent setups this falls out naturally from role assignment — we cover the pairings in which model fits each agent role — but even solo, opening a second CLI with a second lab's model costs you one terminal tab.

2. The reviewer re-runs everything, trusting nothing

The reviewer's first act is not reading code. It's independently running the build and the test suite and comparing reality against the author's claims. "Author says tests pass" is a claim; npm test exiting zero in the reviewer's own shell is a fact. When the two disagree — and they will, more often than is comfortable — you've caught the most common agent failure before a human spent a single minute on it.

This also catches the subtler cheat: tests that pass because they were weakened. The reviewer should diff the test files with the same suspicion as the source files. A deleted assertion is a finding, not a cleanup.

3. Review the diff, not the description

Agents write beautiful summaries of what they did. The summary is the author's opinion of the change; the diff is the change. Reviewers that read the summary first anchor on it and skim the code looking for confirmation. So the reviewer gets the raw output of git diff (or the PR diff) as its primary input, and the description last, if at all. Every claim in the description that matters should be independently visible in the diff or the test run.

4. Structured passes, in a fixed order

"Review this" produces vague vibes. A fixed sequence of passes produces findings. Ours, in order:

1. Correctness. Does the change do what was asked? Edge cases, error paths, off-by-ones, broken invariants, concurrency hazards.
2. Security. Hardcoded secrets or keys in the diff. Injection surfaces — SQL, shell, path traversal, anything interpolating untrusted input. Authorization: does every new endpoint or query check who's asking?
3. Scope creep. Everything in the diff that wasn't required by the task. Renamed files, drive-by refactors, new dependencies, reformatting noise. Each unrequested change is either justified explicitly or flagged for removal — this is the pass that keeps agent PRs reviewable at all.
4. Tests. Does new behavior have new tests? Do the tests assert behavior, or just that no exception was thrown? Were any existing tests modified, and is each modification defensible?

5. Findings as path:line with severity

A review that says "there are some error handling concerns" is worthless — nobody can act on it and nobody can verify it. Every finding gets a location, a severity, and a one-line fix direction: src/api/auth.ts:142 — HIGH — token compared with ==, timing-unsafe; use a constant-time compare. Findings in this format can be handed straight back to the author agent as a work list, which is exactly what you'll do with them.

6. The human reads the verdict, not 400 lines of diff

The end product is a short structured report: pass/fail on the independent build and tests, findings by severity, scope-creep list, and a one-paragraph verdict. You read that in ninety seconds and make the actual decision — merge, send back, or dig in yourself on the one HIGH finding that smells real. Your judgment is the scarce resource; the workflow's whole purpose is to spend it on the verdict instead of the archaeology.

The reviewer prompt, ready to paste

Here's the prompt we use, verbatim. Point a fresh session of a different model at the repo and paste:

You are a skeptical senior code reviewer. You did NOT write this change
and you must not trust any claims made about it.

Task context: [one sentence: what the change was supposed to do]

1. VERIFY INDEPENDENTLY. Run the build and the full test suite yourself.
   Report the actual commands you ran and their real output. If anything
   fails, that is your first finding.
2. Review the raw diff (git diff main...HEAD), not any summary or
   description of it.
3. Do four passes, in order:
   a. CORRECTNESS - logic errors, edge cases, error paths, broken invariants
   b. SECURITY - secrets in the diff, injection (SQL/shell/path),
      missing authorization on any new surface
   c. SCOPE CREEP - list every change not required by the task,
      including modified or deleted tests
   d. TESTS - new behavior without tests; assertions weakened or removed
4. Report every finding as: file:line - SEVERITY (HIGH/MED/LOW) -
   one-line description - suggested fix direction.
5. End with a verdict: APPROVE, APPROVE WITH NITS, or REQUEST CHANGES,
   plus a 3-sentence summary a human can act on without reading the diff.

Be specific. "Looks good" is not a review. If you found nothing, say
what you checked and how, so silence is evidence.

Making it a habit

Run this on every autonomous change of consequence and two things happen fast. First, you catch real bugs — the confident-wrong-action failures that slip past a tired human skim. Second, your author agents get better, because you feed the findings back and the fixes happen before you ever look. In our own team runs the review gate is wired in as a standing role rather than a manual step — The Vibe Father makes that a checkbox — but the workflow above needs nothing but two terminals and the discipline to keep the models separated.

For the wider picture of structuring agents into teams with distinct roles, see the multi-agent coding teams field guide. Review is the role we'd add first, every time.