Claude Code team doubled merged pull requests as AI review cut reverts by 40%

What Anthropic published on 15 October

Anthropic has described, in unusual detail, how the team behind its Claude Code coding agent reviews software that is mostly written by Claude. The engineering post How the Claude Code team does code review, published on 15 October 2026 by Addy Osmani, Morgan Westlee Lunt and Qing Wang, opens with a figure the company has used before: Claude writes about 90 percent of Claude Code's own code.

The headline result is Anthropic's own. From June to September, the post says, merged pull requests to the Claude Code codebase more than doubled, while the share of merged changes that later had to be reverted fell by more than 40 percent. The authors are explicit that they did not remove review. They moved most of the reading to machines, saved people for the decisions only people can make, and invested in making mistakes fast and cheap to undo.

The post landed the same week the company made its commercial reviewer generally available, which we covered in Anthropic makes Claude Code Review generally available for Team and Enterprise. That article is about the product. This one is about the process around it: who approves what, how the reviewer is tested, and where Anthropic still insists on a human.

Why line-by-line review stopped scaling

Volume is the reason. In Anthropic's main monorepo, the post says, changes landing per day rose from about 2,500 in May to more than 30,000 in September, the same surge that pushed the company to replace git with its own Scion version control system. Claude Code lives in a separate repository but faces the same pressure. At that pace, the authors write, manual line-by-line review is incredibly difficult if not impossible.

Their reframing is that "did a human read the code?" is an imprecise proxy for a better question: what could go wrong with this change, and which check, automated or human, is best placed to catch it. Review stops being a gate at the end and becomes something that runs continuously, like a spellchecker, so most changes have been reviewed and fixed by Claude at least once before a person is asked to look.

The team set a measurable target. Most pull requests in the Claude Code repositories, which cover the command line tool, the desktop and web apps and the mobile apps, should merge with at most one human in the loop, and that human can be the author. To check it is working, the team tracks human approvals per pull request at the median and 95th percentile, human comments, and time spent waiting on a person. Revert and incident rates are the guardrail: if they rise, human time has not been saved, only moved to cleaning up.

The checks every change passes through

Anthropic describes six layers of checks with fast rollback underneath, on the principle that each layer catches some problems and misses others, and few get through all of them.

• Verification before a pull request exists. Claude is given something it can run, such as tests, a build or a screenshot to compare against the design, and asked to show the output rather than claim it is done. A subagent then reviews the diff with fresh context, and many engineers run internal skills that hunt for bugs, simplify the diff and check behaviour end to end.
• An AI review on every pull request, reading the diff against the whole repository and the stated intent. Several agents look for bugs in parallel, a separate group votes on each finding, and only findings enough of them agree on are posted, tagged Important, Nit or Pre-existing.
• A security review that blocks: no pull request merges while any bug or security finding is still open, though an author can close a false positive with a short reason.
• Blocking automated checks, including lint, type checks, tests on every platform and a build, plus a template asking how the change was tested and how to undo it.
• Human approval scaled by risk, described in the next section.
• A merge queue that re-runs every check against main, feature flags, release to Anthropic employees first, then a latest channel ahead of stable, with a weekly on-call rotation and flags that can be switched off without a deploy.

How human approval is set by risk

The most consequential part of the post is how it decides when a person must sign off. A classifier reads each change and assigns a risk tier; a second classifier asks whether this particular change needs another person even if its tier says it does not. The change sets the tier, not the author.

Several rules stop the system from being gamed. Only authors on a repository's trusted list, mostly the owning team, get the lighter paths. An agent's approval never counts as a person's. On an agent-written pull request, the person directing the agent counts as one of the required reviewers, as if they had typed the code. Approval covers one specific commit, so an agent's later push or a hand-resolved merge requires approval again. Paths that owners list as sensitive, and any CI workflow file, always need a person.

Teaching the AI reviewer to stop

An AI author and an AI reviewer can keep each other busy indefinitely, and the post admits this happened. One command line pull request went through more than fifty rounds of review and fixes overnight before its author stopped it. When the team ran git blame on what the reviewer kept flagging, about 59 percent was code that had been there since the reviewer's first pass: it was finding a few more old bugs each round rather than new ones.

The fixes were simple. After three rounds, the reviewer now asks the author to step back and reconsider the approach. After the first few passes it re-reviews only the new diff, it flags a class of bug so every instance gets fixed at once, and it does not repeat findings already posted. Separate review agents run nightly over existing code to find old bugs.

The reviewer itself is tested against Anthropic's past failures. The team collected pull requests that caused incidents or reverts, had engineers who know the code confirm each bug, and runs the reviewer against that set daily; a change to the reviewer's prompts, tools or model that lowers the score is dropped. Noise is measured by what people do with each comment, and by running the reviewer on pull requests known to be clean.

What still needs a person

Anthropic lists five decisions it keeps with people: whether something should be built at all, risky code such as billing, the auto-updater and CI workflows, architecture that sets a pattern others will copy, reading the evidence a change comes with, and owning the outcome. A person is accountable for every change that ships, whoever typed it.

The post is candid about gaps. Noticing a bad merge still depends on the author, on-call staff and dashboards. The team does not yet have circuit breakers that tighten approval rules automatically when revert or incident numbers move, and engineers want them before more code moves to merges with no human approval. Code review's second job, spreading knowledge of the codebase, has no formal replacement either: people ask Claude to write an explainer for the part of the code they are about to change.

What other teams can copy

The post ends with a checklist that does not depend on Anthropic's internal tools. Give the coding agent checks it can run and list them in a short CLAUDE.md file. Add a REVIEW.md in which code owners describe what failure looks like in their part of the code. Require CI, and add Testing, Risk and How to revert fields to the pull request template. Put an AI reviewer on one repository, tune it for a few weeks, then widen it. Require every review thread to be resolved before merge, cap review rounds, write down risk tiers that start strict, and never let a bot's approval stand in for a required human's.

The surrounding evidence is a reason for caution as well as interest. A Harvard study of 718 firms found that coding agents added 30 percent more code but no more finished work, with review a likely bottleneck, and the PostgreSQL project recently delayed its 19 release partly because AI-assisted review surfaced bugs faster than people could fix them. Anthropic's answer is to measure human time and treat reverts and incidents as the limit.

Limits of the evidence

Every number in the post is Anthropic's internal data, and none has been independently verified. The revert and pull-request figures cover one team over four months, with no absolute counts, no incident rate and no breakdown of how much of the improvement came from review rather than from smaller changes, flags or a growing test suite. Anthropic also sells the reviewer it describes, so the post doubles as a showcase.

The setting is hard to copy. The Claude Code team builds the tool it uses, ships new behaviour to Anthropic employees before customers, and can afford many parallel review agents on every change. Smaller teams can adopt the checklist, but the round caps and incident-based evals suggest that an AI reviewer left untuned can generate work as easily as it saves it.