How Claude Code scales code review without removing human responsibility

Anthropic’s Claude Code team says it more than doubled merged pull requests between June and September while reducing the share that needed reverting by more than 40%. In an engineering article published on 15 October, Addy Osmani, Morgan Westlee Lunt and Qing Wang describe how the team shifted routine code reading to agents while retaining human responsibility for what ships.[1] The result is a company-reported case study, not independent proof that automated review outperforms people.

The team says Claude writes about 90% of Claude Code’s own code. A separate figure in the article, more than 30,000 changes merging daily by September, concerns Anthropic’s wider monorepo. Claude Code lives outside that repository.[1] Keeping those scopes separate matters: the authors report growth in Claude Code pull requests, not 30,000 daily Claude Code merges.

Their target is less human effort per change without higher revert or incident rates. That includes time spent repairing defects, not only time spent reviewing a pull request. They track human approvals, comments and time waiting on people. The ambition is for most changes across the Claude Code repositories to need at most one person in the loop, potentially the author.[1] It is an operating goal, not a claim that every change already follows that path.

Verification starts before a pull request opens. The authoring agent must produce evidence: test output, a completed build or a visual comparison. A separate agent reviews the diff with fresh context. Recurring mistakes become lint rules, reusable skills or concise repository instructions. CLAUDE.md supplies project context; REVIEW.md tells reviewers which failures matter and asks for findings tied to actual files and lines.[1] This makes review part of producing a change rather than a final request for someone else to find its defects.

Once a pull request exists, Claude reviews its intent and surrounding code. Other agents vet candidate findings before comments reach a person. Security gets a separate review, alongside required lint, type, test and build checks. Under the team’s internal policy, open findings prevent merging until they are fixed or resolved with a reason.[1] This is distinct from the hosted Code Review product: its documentation says reviews neither approve nor block pull requests. The service reads code without building or running it, so it does not replace execution-based checks.[2]

Human approval depends on the change’s risk. The published policy permits low-risk changes to proceed without a human approval once automated review and security checks pass; medium-risk changes need one person and high-risk changes need two. Lighter paths are restricted to trusted authors, and sensitive paths have additional requirements. An agent’s approval cannot satisfy a required human slot. The person directing an agent remains responsible, and an approval must be renewed after new commits the system cannot trust.[1]

Passing review is not the end of validation. A merge queue checks a change against main with that change applied. New behavior usually reaches Anthropic employees behind feature flags before a wider rollout; public releases reach the latest channel before stable. Flags can disable behavior without another deployment, while the author and on-call engineer watch for regressions. At publication, the team said it did not yet have automatic circuit breakers that tighten approval requirements when incident or revert metrics worsen.[1]

The reviewer itself needs limits. The authors describe one pull request that went through more than fifty review-and-fix rounds overnight before a person stopped it. Their investigation found that about 59% of the code repeatedly flagged had existed since the first review pass. They now ask authors to reconsider the approach after three rounds, narrow later reviews to the new diff and avoid repeating findings.[1] The lesson is not that three passes guarantee correctness. Review needs a stopping policy, or agents can spend the night generating work for each other.

Past failures also become evaluation cases. Engineers verify bugs from incident-causing pull requests, fixes and reverts, and the review system runs against that collection daily. To measure noise, the team tracks whether people fix, reject or explain away comments, and tests the reviewer on changes known to be clean.[1] More comments alone are not evidence of better review: a false alarm can trigger an unnecessary edit and another review cycle.

The shift leaves a knowledge-sharing problem. The team reports no formal replacement for learning through colleagues’ diffs; engineers instead request explanations of specific parts of the codebase, sometimes with visual artifacts. Humans still decide what belongs in the product, assess architecture and dangerous code, and examine the evidence supporting a change.[1] For another team adopting this approach, checking those explanations against the implementation remains important: an account of the code is not the code itself.

Source note: the workflow and results above come from Anthropic’s engineering account, checked alongside its product documentation. These are two sources from the same vendor, not independent corroboration. A falling revert rate does not establish that the absolute number of reverts fell when merge volume rose. Nor does this before-and-after account isolate which process change caused the improvement, establish the absence of uncaught defects or show that another team will achieve the same result.[1][2]