How the Claude Code team does code review: automated layers, risk and fast rollback

The article, published on the claude.dev blog on October 15, 2026, and written by Addy Osmani, Morgan Westlee Lunt and Qing Wang, describes how the Claude Code team reviews code when, as they say, Claude writes around 90% of the product's own code. The starting question is what reviewing at that volume means and who catches the bugs. Note: the downloaded text cuts off abruptly in the final section on ownership and team culture. This summary covers only what appears in the content received.

The headline figure they offer is that, from June to September, merged pull requests in the Claude Code codebase more than doubled, while the share that had to be reverted fell by more than 40%. They did not eliminate review. They shifted most of the reading to machines, optimized human time and attention, and invested heavily in making it quick and easy to undo mistakes. For context on scale, they say that in Anthropic's monorepo the number of changes landing per day went from about 2,500 in May to more than 30,000 in September. Claude Code lives in a separate repository, but it faces the same pressure.

The conceptual framing is that code review serves two purposes: finding and fixing problems before they reach production, and building shared context and understanding of the code across the team. The authors propose replacing the question “did a person read it?” with a more precise one: what could go wrong with this change, and what check, automated or human, is the right one to catch it? That also changes when review happens. It is no longer a gate at the end of the road (write, open a PR, wait for a colleague) but something continuous, like a spell checker while you type. Most changes have been reviewed and corrected by Claude at least once before a human looks at them.

The scarce resource is human time and attention, which includes both the time spent reviewing and the time spent fixing what bad code breaks. The goal is for most PRs in the Claude Code repositories (CLI, desktop, web and mobile apps) to merge with at most one person in the loop, who may be the author, without increasing reverts or incidents. To measure this they track human approvals per PR (median and 95th percentile), human comments and how long a PR waits on a person. Revert and incident rates are the safeguard: if they rise, no time has been saved, it has only been moved.

A change's journey has several layers. The first happens before the PR: Claude is given something it can run (tests, a build, a screenshot to compare against the design) and asked to show the output rather than say it is done. Then a subagent reviews the diff with a clean context. Many team members also run internal skills that hunt for bugs, simplify the diff and verify end-to-end behavior, and interface changes are checked against design guidelines. The article quotes Boris Cherny, creator of Claude Code, who considers giving Claude a way to verify its work probably the most important thing for getting good results, and estimates it improves the final result two- to threefold.

When the automated reviewer repeatedly flags the same thing, they fix it at the source: in the skill, with a lint rule or by updating instruction files. CLAUDE.md describes the project (stack, conventions, goals and non-goals) and is loaded on every review, so they keep it short and link to other documents. REVIEW.md is written by the owners of each part of the code and tells the reviewer what matters there. Good ones are brief: they define what failure looks like in that repository (in documentation, “it lies”; in configuration, “it misroutes”), limit nits, list paths to ignore, require file and line as evidence, and ask for a summary that starts with a count and states clearly when there is nothing to fix.

The second layer is AI review on every pull request. Claude reads the diff against the entire repository and the PR's stated intent, and asks whether the change solves its problem, fits the system or breaks something else; for a bug fix it looks for the root cause. The public version, Code Review for Claude Code, is generally available on Team and Enterprise plans, and /code-review runs a lighter version locally. When they launched the research preview, the share of internal PRs with substantive review comments rose from 16% to 54%. Most PRs over 1,000 lines receive findings and most small ones come out clean. Admins configure each repository as Quick, Standard or Deep, with the latter paying off where a missed bug costs more than the extra review time.

Findings are verified before they reach people. Several agents hunt for bugs in parallel and then another group votes on each finding, which is only posted if enough voters agree it is real. Those concerning only style, diagnostics or cleanup are discarded, and these filters were A/B tested on their own PRs. What remains appears as inline comments ordered by severity and labeled Important, Nit or Pre-existing, so that a bug the PR did not introduce does not look like the author's fault. Every finding must be addressed: it is either fixed or the thread is closed with a reason. Often an agent applies the fix overnight.

The third layer is a separate security review that can block. A PR does not merge while any finding from the bug or security review remains open. False positives are closed with a brief reason, and if a later commit fixes the problem, the finding clears itself. They note this can be replicated with the open-source security review GitHub Action or the /security-review command. The fourth layer is the usual automated checks: lint, types, tests across all platforms and build. A typical CLI PR may go through dozens of checks. The PR template asks how the change was tested and how to roll it back; Claude can fill it in, but the person who requested the change signs off on it.

The fifth layer is human approval scaled by risk. Low risk (documentation, copy, internal-only features, additive changes behind a flag): no human approval once automated and security review are green. Medium risk (normal product changes and sensitive areas such as caching, the auto-updater or system prompts): one person. High risk (the most critical code and a small set of paths that always require two people): two people. The level is set by the change, not the author: a classifier reads the change and chooses the level, and a second classifier assesses whether this specific change needs another person even if its level says otherwise. Some paths always require a person, such as anything owners mark as sensitive and any CI workflow file. Only authors on the trusted list, mainly the team that owns the repository, get access to the lighter tracks; everyone else needs a second person.

There are additional rules. An agent's approval never counts as a person's: automated review can sign off on a low-risk change, but it cannot fill a slot that requires a human. Whoever requested the change is accountable for it, and on a PR written by an agent, the person directing it counts as one of the required reviewers. Each approval covers a specific commit, and if commits arrive that the system cannot vouch for, such as an agent's push or a hand-resolved merge, it must be approved again.

The sixth layer is the merge queue, flags and gradual rollout. The merge queue reruns all checks against main with the change applied, so that two PRs that pass separately cannot combine into a broken main. New behavior usually ships first behind a flag for Anthropic employees, whose heavy usage often surfaces regressions before users do. Public releases go first to the latest channel, with the stable channel following after a delay.

The seventh layer is fast detection and rollback. Flags are turned off without a deploy, there is a weekly on-call rotation, and incident reviews ask which layer should have caught the problem. The authors admit they do not yet have automatic circuit breakers that tighten approval when revert and incident metrics move, and that engineers want them before moving more code to human-free merges. They quote a colleague who says slowing down reduces the error rate, but mostly because you do less of everything; they prefer to get faster at detecting and fixing.

The article also explains how they improve the reviewer. Incidents become evals: they collected past PRs that caused incidents, along with their forward fixes and reverts, and engineers who know that code confirmed each bug and where it was. The reviewer runs daily against that set, and every change to prompts, tools or model is scored against all cases: if the score goes up, it stays; if not, it is dropped. Noise is measured by watching what people do with comments (they fixed it, said it was wrong, that the behavior was intended or that it did not matter) and by running the reviewer on PRs known to be clean to count how often it proposes something that would lead to a harmful change. Their written priority is to catch real bugs first and reduce review rounds second.

A key point is convergence. Noise costs more when the author is an agent, because it fixes the nit, which means another commit and another round. An author agent and a reviewer agent can keep each other busy indefinitely: one CLI PR went through more than fifty rounds of review and fixes overnight until its author stopped it. When they used git blame to analyze what the reviewer kept flagging, around 59% was code present since the first pass, meaning it rarely found new bugs and uncovered a few more old ones each round. The authors themselves made it worse by getting into the habit of running several rounds by default. They now track rounds-to-approval alongside recall, and they changed re-review: a cap on rounds (after three, the reviewer asks the author to rethink the approach), re-reviewing only the diff after the first passes, flagging the bug class so the author fixes every instance, and not repeating findings already posted. In addition, review agents sweep the existing codebase every night to hunt down old bugs.

According to the figure accompanying the text, after these changes on internal PRs the percentage passing after one round of review and fixes rose from 65% to 78%, those needing five or more rounds fell from 8.9% to 1.5%, and the average number of reviews to approval went from 2.08 to 1.32.

On the role humans retain, the article notes that pulling a senior engineer out of deep work to catch a routine error costs far more than an automated review. People still decide whether something should be built (direction, judgment and scope; one team that considered its bottleneck solved kept human review for changes from outside the team), review risky code such as billing, the auto-updater and CI workflows, review architecture that sets patterns others will copy, read the evidence (test output, the command run, screenshots, reviewer findings) and take responsibility for the outcome. If you cannot say what the checks would let through, you should ask for a real review rather than a quick approval.

The second purpose of review, spreading understanding of the code, has no formal process. Nobody holds a complete mental model of Claude Code, nor do they think it necessary. Anyone who wants to understand a part asks Claude for an explainer of that specific piece, which takes minutes and reflects the current code; some also ask for a visual artifact tailored to how they learn. They argue that this is a better use of attention than reading trivial diffs, and that the habit of working in open Slack channels helps people see what others are building.

The text received ends with the section “You land it, you own it”: whoever merges a small or medium change and something breaks usually fixes it. This is supported by small changes that are easy to review and revert, reversibility through flags, reverts and staged rollouts, a bar that depends on blast radius, regressions that surface quickly through telemetry and internal use, and blamelessness (incident reviews examine the system). Ownership is also shared, with open channels where anyone can see, pick up or flag gaps. The content breaks off mid-sentence, so the ending is unknown, as are the sections on how to adopt the process and where it is headed, which appear in the table of contents.