How the Claude Code team reviews code: seven layers and risk tiers

Claude writes about 90% of Claude Code's own code. With that as a starting point, the question of how to review what goes into the repository stops being theoretical, and the Anthropic team that maintains the tool has just explained its answer in How the Claude Code team does code review, written by Addy Osmani, Morgan Westlee Lunt and Qing Wang and published on 15 October.

The next day Simon Willison highlighted the paragraph that best sums up the shift: "did a human read the code?" is an imprecise proxy for the question that matters, which is what could go wrong with this change and which check, automated or human, is the right one to catch it.

From final gate to continuous spellcheck

The first effect of that reframing is about timing. Before, review was a toll at the end of the road: write the code, open the PR and wait for a colleague. Now it works, in the authors' words, "more like spellcheck while you write". Most changes have already been reviewed and fixed by Claude at least once before anyone on the team looks at them, so routine mistakes are filtered out early and human attention is saved for higher level questions.

The figures in the article explain why they needed to change. Merged PRs in Claude Code more than doubled between June and September 2026, while the revert rate fell by more than 40%. In Anthropic's monorepo, changes landing per day went from about 2,500 in May to more than 30,000 in September. At that volume, a review model based only on people does not scale.

Seven layers instead of one approval

The system they describe has seven layers:

1. Pre-PR verification: agents run tests and lint, and a subagent reviews the diff.
2. AI code review: Claude analyses the change with the context of the whole repository, and several agents verify each finding before it is posted.
3. Security review: a separate automated pass that blocks the merge if issues remain open.
4. Automated CI: lint, type checking, per-platform tests and builds.
5. Risk-based human approval: a classifier assigns a tier. Low risk requires no approvals, medium requires one and high requires two.
6. Merge queue: rechecks every change against the latest main.
7. Post-merge monitoring: feature flags, gradual rollout, on-call and fast rollback.

The fifth point is the most striking. Allowing a change classified as low risk to land without human approval breaks a deeply rooted habit, and the team offsets it with a clear norm for small and medium changes: "you land it, you own it". On top of that, an approval covers one specific commit, not the PR in the abstract.

What it took to tune automated review

The article does not hide the stumbles. The share of PRs receiving substantive comments from automated review rose from 16% to 54%, which forced work on convergence: one PR ran through more than 50 review rounds before it was stopped. After the adjustments, PRs that pass in a single cycle went from 65% to 78%, and those needing five or more rounds dropped from 8.9% to 1.5%.

To guide the reviewer they use two files: `CLAUDE.md`, with the project's conventions, and `REVIEW.md`, where the owners of each part of the code state what they care about in review. Bugs from past incidents are turned into daily evaluation cases. Anyone who wants to replicate part of the workflow has the `/code-review` and `/security-review` commands locally, and the Code Review for Claude Code feature on Team and Enterprise plans.

Where people are still needed

The authors are explicit: strategic direction and scope, high-risk code such as billing, auto-updaters or CI workflows, architecture decisions that set precedent and evaluating the evidence provided by tests and reviews all remain human work, as does accountability for what ships.

They also push back on the argument that going slower is safer. It is, they say, "but mostly because you're doing less". For knowledge sharing they suggest asking Claude for explainers on the module you are about to change rather than relying on passively reading other people's diffs.

Who it is useful for

For teams already working with Claude Code who notice that the PR queue has become the bottleneck, the article is close to a manual. For engineering leads, the value lies in the risk-tier classifier and in measuring reverts and review rounds, not just speed.

The figures come from a team that builds the tool itself, with a very specific monorepo and culture, and they do not carry over as is to a five-person team. What we do think is portable is the starting question: what could go wrong with this change and which check is best placed to catch it.