Evidence at a glance
Review No Longer Happens Only Before Merge
In “How the Claude Code Team Does Code Review,” Addy Osmani, Morgan Westlee Lunt, and Qing Wang describe how the Claude Code team at Anthropic is adapting its review process to a rise in agent-produced changes. The problem is not how to give every pull request one more reader. It is how to catch defects as change volume grows while reserving human review for decisions that need judgment.
That distinction changes where review sits in development. In the familiar workflow, review comes at the end: code is written, a pull request is opened, and a colleague is asked to inspect it. Anthropic describes Claude checking and fixing changes throughout development, so that most changes have had at least one agent review before a human is asked to look. Review becomes a continuous check rather than a gate immediately before merge.
Start with the Risk, Then Choose the Check
The guiding question is not “Did anyone read the code?” but “What could go wrong with this change, and which check is best suited to catch it?” Developers first give Claude executable ways to verify the work, such as tests, builds, or interface screenshots. Subagents with different contexts then inspect the diff. The team also uses internal skills for bug finding, trimming changes, and end-to-end checks, and turns recurring review feedback into project guidance or rules.
The pull-request stage is not simply a single agent inspecting a diff and having its output accepted at face value. Claude checks the change against the wider codebase and the pull request's intent; multiple agents search for problems, and another set assesses whether those findings hold up. Style preferences and routine cleanup suggestions are filtered out, while retained findings are presented by severity. Findings must be fixed or answered with a rationale before they can be closed, making review a control point that requires a response rather than just a list of comments.
Higher Throughput Does Not Prove Causation
Anthropic's figures show the scale its process is meant to handle. The team says its monorepo went from about 2,500 landed changes per day in May 2026 to more than 30,000 in September. From June to September, the number of merged pull requests in the Claude Code repository more than doubled, while the share of pull requests that had to be rolled back fell by more than 40%. The team also reports that the proportion of internal pull requests receiving “substantive review comments” rose from 16% to 54% after a feature research preview was introduced.
These figures are signals worth examining, not a complete causal demonstration. The article does not specify the sample size or calculation method for “substantive” comments, nor does it provide the risk mix of the pull requests, absolute rollback counts, or an independent audit. The decline in the rollback share therefore cannot be attributed to the review process alone. The article also says most pull requests above 1,000 lines receive findings while most small ones do not, without giving exact proportions. And about 59% of review comments concern code that was already present at the first check, a reminder that a finding is not necessarily a defect introduced by the current change.
Filtering Defects Is Not the Same as Taking Responsibility
Automating routine review does not mean removing human approval. Anthropic describes a risk-tiered process: low-risk changes may need no human approval once automated checks pass, medium-risk changes usually need one approver, and high-risk changes usually need two. Independent security review, along with linting, type checks, tests, and builds, remains part of the process. An agent's approval cannot replace a required human approval.
Human responsibility is also more than signing off on a machine's conclusion. The authors reserve decisions about direction and scope, sensitive code, architectural patterns, verification evidence, and responsibility for the final release for people. Code review also helps a team build shared understanding of its codebase, a function that does not automatically survive when routine defects are caught by automation. Asking Claude to explain a module can help, but the material does not establish that this replaces the shared understanding built through peer review.
Treat the Review Agent as a Control Plane, Not a Judge
Anthropic also puts the review process itself into an improvement loop. The team turns pull requests associated with past incidents, their subsequent fixes, and rollbacks into an evaluation set, tests the reviewer periodically, and tracks whether findings are fixed, judged invalid, or considered irrelevant. Recurring problems can become rules. The reviewer's comments must themselves be assessed rather than treated as authoritative simply because an agent produced them.
The team once saw a CLI pull request go through more than 50 rounds of review and fixes overnight. It responded by setting a three-round limit, after which the author is asked to reconsider the approach. That episode exposes another cost of automation: reviewers and authors can get stuck in a loop, and more rounds do not necessarily mean a more reliable result. High-volume teams can borrow the principle of providing executable evidence first, assigning human approval by risk, and building regression evaluations from incident cases. They should not assume Anthropic's reported results or approval thresholds will transfer directly. The practical test is whether a team's checks are demonstrably useful, its findings traceable, and its accountability still clear when someone says an agent has already reviewed the change.