Quick summary

• Review becomes a system: Anthropic spreads checks across local verification, automated review, CI, risk-based approval, and rollback.
• People still decide: Human attention goes to product direction, architecture, sensitive changes, and whether the evidence is convincing.
• The results are promising, not proof: Anthropic reports more than twice as many merged Claude Code pull requests and a lower revert share, but the figures do not isolate the review process as the cause.
• Measure the trade-off: Track review effort alongside reverts, incidents, and noisy findings, then make rollback routine.

AI code review faces a new problem: an agent can open more pull requests than a team can carefully read. Adding another reviewer to every change does not solve the bottleneck. The harder question is where human attention still changes the outcome.

That is the problem behind the Claude Code team’s review process. Anthropic says Claude writes about 90% of Claude Code’s code. The team has moved much of the routine inspection to automated checks, while people focus on decisions that require context and judgement. The person directing an agent-written change remains responsible for it.

Anthropic reports that merged pull requests in the Claude Code repositories more than doubled from June to September 2026, while the share later reverted fell by more than 40%. Those are encouraging company-reported results. They show higher throughput and a lower revert share at the same time; they do not show that the review workflow alone caused the change.

One scale figure needs separate context. Anthropic says its main monorepo grew from about 2,500 merged changes a day in May to more than 30,000 in September. Claude Code lives in a different repository. That monorepo surge also pushed source control and CI infrastructure to its limits, prompting Anthropic to build Scion. Our related article looks at that infrastructure problem. This article is about the quality-control problem: how changes are checked, approved, and recovered if something goes wrong.

Code review is more than reading a diff

Anthropic frames review as two jobs: finding defects before release, and helping a team build shared understanding of its code. Its new process focuses mainly on the first job. It asks what could go wrong with a change, then chooses the check most likely to catch that failure.

That distinction matters. A test can confirm expected behavior; a linter can enforce a rule; a security scan can flag a known risk. None decides whether the feature is worth building or whether its design will make sense six months later. Those remain human questions.

How Claude Code review works

The workflow is a series of checks, not a single final approval. Anthropic describes six layers, from work on an engineer’s machine through monitoring after release, with rollback beneath them. Each layer catches different problems, and recovery is there for the ones that escape.

Review depth also varies. Anthropic describes no human sign-off for some low-risk changes after automated checks pass, one person for medium-risk changes, and two for high-risk changes or protected paths. A classifier helps assign the tier, but sensitive areas can still require a person. The person who asked the agent to make the change counts as a reviewer, and an agent cannot fill a human approval slot.

People still decide what deserves to be built, scrutinise architecture and sensitive code, read the verification evidence, and own the result. The workflow also preserves another way to learn the codebase: Anthropic says engineers ask Claude to explain the specific area they need to understand instead of expecting every reviewer to read every diff for context.

What the reported results do, and do not, tell us

The headline figures show what Anthropic is trying to optimise: more merged work without a corresponding rise in reversions or incidents. The team says it tracks human approvals per pull request, including the median and 95th percentile, human comments, and time waiting for a person. Reverts and incidents act as guardrails. Reducing review time would be a false win if it simply created more work fixing bad changes.

Still, the June-to-September comparison is not a controlled test of the process. The post does not separate the effects of review changes from other changes to the codebase, team, tests, or release practices. Nor does a lower revert share mean every escaped defect or incident fell by the same amount. The figures support a narrower conclusion: Anthropic reports higher pull-request volume alongside a lower share of changes that had to be reverted.

Anthropic also describes how it evaluates the reviewer itself. It turns past incidents and reverts into examples the reviewer must catch, and checks known-clean pull requests for harmful false alarms. That is a stronger quality loop than simply counting AI comments. The team also caps repeated review rounds: in one example, many later findings were already present at the first pass. More rounds had become repetition, not necessarily better review.

There is a candid limit, too. Anthropic says it has not yet built automatic circuit breakers that tighten approval rules when revert or incident rates rise. It wants that safeguard before expanding zero-human approval. The process therefore still relies on monitoring and human response, and some of its safeguards are evolving.

What other teams can borrow

Most teams do not need Anthropic’s infrastructure or volume to apply the underlying ideas. Start with the failures that matter in your own codebase, then build checks around them:

1. Make verification concrete. Give the agent runnable checks and ask it to show results, not just say that the change works.
2. Set risk boundaries. Identify paths and changes that always need human approval, especially security-sensitive, financial, deployment, or hard-to-reverse work.
3. Test the reviewer. Compare findings with known incidents and known-clean changes. Watch for missed bugs and false positives.
4. Limit review loops. After a few rounds, focus review on the new diff or reconsider the approach instead of repeating broad scans.
5. Plan recovery before release. Use flags, staged rollout, monitoring, and a tested rollback path for changes with meaningful user impact.
6. Measure both sides. Track review wait and effort alongside reverts, incidents, and time spent fixing escaped problems.

These practices need to fit the team’s own risk and release process. Anthropic’s tiers are an example, not a template to copy blindly. A small team can begin with strict human review and relax it only when its checks and outcome measures provide evidence that doing so is safe.

For more context, see how Claude Code uses grep and when vector search is still useful, and how to evaluate agents in production by tracing paths and outcomes.

So, who reviews the code?

Machines do more of the repeatable reading. People decide what deserves to be built, where risk is too high to automate approval, whether the evidence supports a merge, and what to do when a change causes trouble. Anthropic’s case is not that code review has become unnecessary. It is that review can be distributed across checks, human judgement, and fast recovery.

The case is promising, but comes from one company describing its own system and results. The transferable lesson is to measure whether automation reduces human effort without increasing the cost of mistakes, then adjust the boundaries as evidence accumulates.

Sources and further reading

• Anthropic: How the Claude Code team does code review
• Anthropic: Redesigning source control at Anthropic
• Claude Code documentation: Best practices
• Related article: Anthropic’s AI coding boom and the Git bottleneck

The post Claude Writes 90% of Claude Code. So Who Reviews the Code? appeared first on Alpesh Kumar.