Anthropic reveals how it reviews code that Claude writes 90% of

Anthropic has shown what code review looks like when a model writes almost all of the code. Claude writes about 90% of the code in Claude Code, and human attention has become the scarcest resource. The team framed its goal this way: minimum human time spent on review, at the same level of reverts and incidents. From June to September, merges more than doubled, while the revert rate fell by more than 40%.

The metrics are chosen with some engineering cunning. The team optimizes for the number of approvals per PR, the number of comments and the time a human spends waiting. Reverts and incidents act as a guardrail: if they rise, the speed gain doesn't count.

A seven-layer pipeline where humans come in late

The system is a chain of sequential filters. Each one takes some of the load off the human reviewer:

• Before the PR. Claude runs tests, the build and the linter itself. Then a subagent with fresh context looks at the diff. There are internal skills for bug hunting, diff simplification and e2e checks.
• AI review on every PR. Several agents search for bugs in parallel, a separate group votes on each finding, and purely stylistic remarks are discarded. Findings are labeled Important, Nit and Pre-existing, so that an old bug isn't pinned on the author. Every finding requires a response. Since the preview launched, the share of PRs with substantive comments has risen from 16% to 54%.
• Security review. It blocks the merge.
• Regular CI. Lint, type checking and tests on all platforms.
• Risk-based approval. A classifier determines how many humans are needed. Docs, texts and feature-flagged changes require zero humans, ordinary changes one, the most critical two. Billing, the auto-updater and CI workflows always require a human.
• Rollout. Merge queue and flags. Internal users see the change first, then the latest channel, then stable.
• Fast rollback.

The logic is simple: cheap automated checks filter out the obvious problems, and expensive human time goes where the cost of a mistake is high.

When the author agent and the reviewer agent chase each other all night

The most telling story in the breakdown concerns endless loops. An author agent and a reviewer agent can trade edits indefinitely. One PR went through more than 50 rounds overnight, until the author stopped the process. Analysis showed that about 59% of the comments concerned old code. In each round, the reviewer found a couple more inherited bugs rather than new errors in the change.

In terms of tokens, this is pure waste: every round is paid for with diff context, a run of several agents and a vote. The team introduced a limit of three rounds, and a repeat review now looks only at the new diff. The Pre-existing label covers the other half of the problem: old debt stays visible, but it doesn't block someone else's PR.

There is also a separate mechanism for controlling the quality of the reviewer itself. Every past incident is turned into an eval, and the reviewer is run against these cases daily. Any prompt or model change that lowers the score is rolled back. The review agent is tested like any ordinary production component.

Four rules that carry over to any team

The breakdown includes a set of principles that aren't tied to Anthropic's infrastructure:

• Risk level is determined by the change, not the author.
• The lightweight path is available only to trusted authors.
• An agent's approval never counts as a human's.
• Whoever assigns a task to an agent is responsible for the code as if they had written it themselves.

For teams where agents already write a noticeable share of the code, this suggests a concrete plan. Start by classifying repository paths by risk: what can be merged without a human, and what always requires review, like billing and CI at Anthropic. Then set up multi-agent review with voting and labeled findings, cap the number of rounds, and build your own evals from real incidents. For those who don't want to assemble everything themselves, Code Review for Claude Code is now GA on the Team and Enterprise plans. The original article was published on claude.dev.