AI Code Review in Five Layers: How the Claude Code Team Tiers Human Approval

Claude now writes roughly 90% of the code in Claude Code, and Anthropic has explained how its engineers keep up with that output. The answer is not more people reading more lines. Anthropic dropped “did a human read this code?” as its safety test and replaced it with two questions: what could go wrong, and which automated or manual check is best at catching it? The result is a stack of five review layers, with human sign-off scaled to risk and fast rollbacks as the final backstop. Between June and September, the Claude Code team more than doubled its merged pull requests, the proposed code changes that go through review before joining the codebase, while the share that had to be reverted fell by more than 40%. For any team handing more of its coding to AI agents, the design looks like a useful template, as long as its numbers and costs are read with care.

Why reading every line stopped working

The volume explains the shift. In May 2026, Anthropic’s main monorepo (a single repository that holds many projects) merged about 2,500 changes a day. On its busiest day in September, it merged 30,401. Individual engineers move fast too: in March 2026, Boris Cherny, who created Claude Code, said he was shipping 20 to 30 pull requests, or PRs, a day by running five Claude sessions side by side in separate terminal tabs. At that pace, a human reading each change line by line is simply not possible.

So Anthropic treats “a human read it” as an imprecise stand-in for quality and reliability. Its goal now is for most PRs to merge with at most one human involved, and that person can be the author. Two metrics keep the goal honest: the revert rate and the production incident rate. If either climbs, the team has not saved any time. It has only moved effort from reviewing code to cleaning up after it.

Five layers of Swiss cheese

Anthropic compares the setup to the Swiss cheese model of safety. Each slice catches a different kind of problem, and whatever slips through every slice is caught by the ability to roll back quickly.

Layer 1: Checks inside the author’s session

The first review happens before a PR even exists. Inside the engineer’s own Claude session, Claude runs the tests, builds the application and takes screenshots to compare against the design mocks. It then hands the diff, the set of changed lines, to a subagent: a helper agent that starts with a fresh context, without the conversation in which the code was written.

Layer 2: Finders and voters

Opening a PR triggers Claude Code Review, Anthropic’s automated reviewer. Several “finder” agents scan the change in parallel and propose candidate bugs, such as “draft may be null,” “save() can run twice on blur,” “missing await” or “value is unused.” Then “voter” agents decide which candidates are real problems, and only those become review comments. Splitting the work this way is meant to reduce the hallucinations (confident but false claims) and false positives that come from relying on a single agent.

▲ Finder and voter agents

When Claude makes the same mistake across many PRs, engineers do not fix each PR by hand. They remove the pattern at its source with a linter rule (an automated style and correctness check) or a line in CLAUDE.md, the instruction file Claude Code reads at the start of a session. For example, if Claude keeps calling an outdated helper such as legacyFormatDate instead of the current formatDate, a team can add an ESLint rule that bans the old helper and note the convention in CLAUDE.md.

Code owners also write a REVIEW.md file that tells the reviewer what failure looks like in their part of the codebase and what to ignore:

• Documentation that lies: a README says the autoSave setting is on by default, while config.ts sets it to false.
• Configuration that misroutes: DATABASE_URL points to production instead of staging.
• Files to skip: generated client code that does not need review.

Layers 3 and 4: Security review and CI

The automated security review is a hard gate. If it finds a vulnerability, such as unescaped input in a query, the PR cannot merge until the issue is fixed in a new commit or marked as a false positive with a written reason. After that come the standard CI checks, the automated builds and tests that run on every change. Every PR also follows a template that states how the change was tested and how to roll it back.

Layer 5: Human approval set by risk

Only at the last layer do people formally sign off, and how many depends on risk rather than on the author’s judgment. Documentation changes count as low risk, and so does code behind a feature flag, a switch that lets a team ship code while keeping the new behavior turned off.

An AI classifier assigns each PR its tier, and a second, independent classifier double-checks whether human oversight is needed.

▲ Human approvals by risk tier

Testing the reviewer every day

An automated reviewer is only as good as its track record, so Anthropic tests it daily. Production incidents and reverts are turned into test cases. Engineers who know that area of the code verify each case before it joins the evaluation set, and the reviewer is scored against the full set every day. A proposed change to the reviewer’s prompts, tools or model is accepted only if the overall score goes up.

Scoring only on bugs caught would create a perverse incentive: a reviewer that flags every line would look excellent. To counter that, Anthropic also tracks how authors respond to review comments, which lets it measure noise and penalize it.

When agents review agents

A new problem appears when both the author and the reviewer are AI agents: the review may never end. In one case, a PR to an internal command-line tool went through more than 50 rounds of review and fixes overnight before an engineer stepped in. Looking at repeat rounds, Anthropic found that about 59% of flagged issues pointed at code that had been there since the first pass, not at defects introduced by the latest edits. In other words, the loop kept resurfacing old code rather than finding new bugs.

Three changes fixed it:

• A three-round cap. After three rounds, the author agent is told to step back and rethink its approach.
• Diff-only follow-ups. Later rounds review only the lines that changed since the previous round.
• Flagging whole bug classes. If “user can be null” appears in api.ts, form.ts, list.ts and menu.ts, the reviewer reports all four at once, so the author agent can fix every instance in a single commit.

Two caveats: reverts and cost

The headline revert figure deserves a second look. A 40% drop in the share of PRs that get reverted sounds like a clear win, but the number of PRs more than doubled over the same period. Twice the volume at 60% of the old revert rate works out to roughly 20% more reverts in absolute terms. A falling share does not by itself mean fewer things went wrong, so absolute counts belong next to it.

Cost is the other caveat. Commenters on Hacker News noted that Anthropic can afford token-heavy, multi-agent reviews because it has plenty of internal tokens, the units AI models use to process text. Because it owns the models, it can make dozens of model calls on a single PR. Outside customers pay $15 to $25 per review on average for Claude Code Review. For a typical company or a solo developer, that bill may become hard to justify at scale.

What stays with people

None of this removes engineers from the loop. It moves them to the decisions machines handle poorly: system architecture, weighing evidence, deciding whether a feature should be built at all, and reviewing the most critical code.

Anthropic’s rule for accountability is “You land it, you own it.” The engineer who merges a change is responsible for debugging and fixing it if it breaks in production. Telemetry (automatic data about how software behaves in production), fast reverts and feature flags make that responsibility practical. AI can shrink the time spent writing and reviewing code, but the operational responsibility stays entirely with the engineer.

What your team can borrow

You do not need Anthropic’s scale or token budget to use the core ideas:

1. Keep CLAUDE.md short. Move recurring rules into linters and automated tests instead of ever-longer instructions.
2. Write a REVIEW.md. Tell the reviewer what failure looks like in each directory and which files to skip.
3. Cap review loops. Stop agent-to-agent review after three rounds, review only new changes afterward and flag bug classes once.
4. Tie human approval to risk. Never count a bot’s approval as a human one on high-risk, security-sensitive or architectural changes.
5. Track reverts both ways. Watch the absolute count as well as the share, and make whoever merges a change own it.

Before rolling out automated review, estimate what it will cost per PR at your volume. The point of reviewing less by hand is to save time, not to move that time into incident response.