2x the PRs, 40% lower revert rate: steal Anthropic's code review setup

Claude writes about 90% of Claude Code's own code. You would expect review to become the bottleneck, or quality to drop. Neither happened.

On Oct 15, the Claude Code team published how they do code review. Between June and September, merged PRs to the Claude Code codebase more than doubled, and the share of PRs that had to be reverted fell by more than 40%.

Review also converged faster. On internal PRs, the share that passed after one review-and-fix round went from 65% to 78%. PRs needing five or more rounds dropped from 8.9% to 1.5%. These are Anthropic's own figures from their own repos, so read them as what a good setup can do, not a promise.

Their stack: four checkpoints, not one gate

1. Before the PR. Tests run, and a subagent reviews the diff with fresh context.
2. On every PR. Required CI first. Then several agents look for bugs at the same time, and a separate group votes on each finding. A finding only gets posted if enough of them agree it's real.
3. Approval by risk. A classifier picks the risk tier. Low risk needs no human once automated review and security checks are green. Medium needs one person. High needs two. An agent's approval never counts as a human's.
4. After merge. New behavior ships behind a flag, staged releases go out gradually, and everything can be rolled back in one step.

Layers 1 and 2 are the ones a solo builder can run for free. Here is the version you can copy, taken from the team's own adoption checklist.

Step 1: give the agent checks it can run

A short CLAUDE.md with your stack and the commands that prove the work is done. Swap in your own stack and checks:

# CLAUDE.md

## Stack
Expo app, Supabase, FastAPI

## Checks you can run yourself
npm test
npm run lint
npx tsc --noEmit

## Before you say "done"
- run every check above
- fix what fails, run again

Step 2: tell the reviewer what failure looks like

Anthropic's advice for a REVIEW.md: keep it short, say what failure looks like in each part of the repo, cap the nits, list paths to skip, and ask for a file and line as evidence instead of a guess.

# What failure looks like here
api/       leaks a user's data
payments/  charges the wrong amount
docs/      says something untrue

# Rules
- max 3 nits per review
- skip: generated/, *.lock
- every finding needs file:line
- start with a count of issues
- nothing wrong? say "nothing to fix"

Every time you leave the same review comment twice, move it into this file.

Step 3: run two commands before every PR

Both are built into Claude Code. /code-review reads your diff and looks for bugs, and /security-review checks your changes for security holes. Run them locally, before anyone else sees the code.

Step 4: every PR says how to undo it

Add three fields to your PR template: testing, risk and how to revert.

## What changed

## Testing
- [ ] how I checked it works

## Risk
low / medium / high, and why

## How to revert
one line. if you can't write it, the change is too big

Step 5: cap review rounds at three

After three rounds, their reviewer asks the author to step back and reconsider the approach. Without a cap, one CLI PR went through more than fifty rounds of review and fixes overnight before its author stopped it.

My take

The checklist matters more than the bot. A reviewer only catches what you told it to care about, so write down what failure looks like first, then let the agents read the diff.

Which of the five are you missing? Tell me.