How the Claude Code Team Does Code Review: Seven Steps and No Circuit Breakers

On 15 October 2026 the Claude Code team published its own account of how it reviews code, a fourteen-minute engineering post credited to Addy Osmani, Morgan Westlee Lunt and Qing Wang. The sentence that explains why anyone is searching for this arrives early: Claude writes about 90 percent of Claude Code's own code. The post is not a defence of that number but a description of the machinery that had to exist underneath it before it was survivable, and the parts worth reading closely are the ones still missing.

Most summaries stop at the two headline numbers: merged pull requests to Claude Code's codebase more than doubled between June and September 2026, while the share that had to be reverted fell by more than 40 percent. Both come from the team itself, and both can be produced by several different arrangements, including the one people assume, which is that review was quietly removed. The post says it was not. They moved most of the reading to machines, optimised for human time and attention, and invested in making mistakes fast and easy to undo. Everything else is the detail of how.

Why review became the bottleneck in the first place

The pressure did not come from a policy decision. It came from volume. In Anthropic's monorepo, the post reports, changes landing per day went from about 2,500 in May to more than 30,000 in September 2026. Claude Code lives in its own repository, separate from that monorepo, but it is under the same pressure at a smaller scale.

At that rate, the post concedes, manual line-by-line review is incredibly difficult if not impossible. Nobody there is claiming that a human reading every diff is unnecessary. They are claiming that reading every diff no longer scales, and that "did a human read the code" was always an imprecise proxy for the question that matters: what could go wrong with this change, and which check, automated or human, is the right one to catch it.

Once phrased that way, the gate moves. Review stops being a door at the end of the road and becomes continuous, closer to spellcheck while you write. Most changes have been read and fixed by Claude before a person looks.

What they optimised for, and what counts as failure

The stated goal is that most pull requests in the Claude Code repositories, which the post describes as the CLI, the desktop and web apps and the mobile apps, merge with at most one human in the loop, who can be the author, with no increase in reverts or incidents. The third clause is what makes it a real target rather than a cost-cutting exercise.

They measure human time on both sides of the ledger: the time people spend reviewing, and the time they spend fixing what bad code breaks. Cutting the first does not help if the cost reappears on the second, and the team says so directly. So the tracked numbers are human approvals per pull request, reported as a median and a 95th percentile, human comments, and how long a pull request waits on a person. Revert and incident rates sit underneath all of it as the guardrail: if those rise, human time was not saved, only moved.

Review-cost metrics are easy to game in isolation; a reviewer that approves everything produces beautiful approval-time charts. The guardrail is what stops the chart from lying.

Seven steps, not one gate

The post lays the path of a typical change out as seven numbered steps. Each layer catches some problems and misses others, and cheaper checks run before more expensive ones.

• Verification before the pull request exists. Claude runs the tests, the build and the linter, and a second agent reviews the diff in a fresh context. Many engineers also run internal skills: one hunts for bugs, one simplifies the diff, one checks behaviour end to end. Boris Cherny, who created Claude Code, has called giving Claude a way to verify its own work probably the most important thing for good results, and estimates it makes the final result two to three times better.

• AI review on every pull request. A Claude review reads the diff against the whole repository and the pull request's stated intent. Several agents hunt for bugs in parallel, then a separate group votes on each finding and it is only posted if enough agree it is real. Findings about style, diagnostics or cleanup are dropped. What survives appears as inline comments tagged Important, Nit or Pre-existing. When the research preview launched, the share of internal pull requests getting substantive review comments went from 16 percent to 54 percent. Admins set each repository to Quick, Standard or Deep.

• Security review. A separate automated pass. A pull request cannot merge while a finding from either review is open; you fix it or close the thread with a short reason. The same check is public as the open-source security review GitHub Action or the /security-review command.

• Automated checks that block. Lint, type checks, tests on every platform, and a build.

• Human approval, scaled by risk. A classifier reads the change and sets the tier rather than the author setting it. This step gets its own section below, because it is where most of the interesting design is.

• Merge queue, flags and gradual release. The queue re-runs every check against main with the change applied, so two pull requests that each pass cannot combine into a broken main. New behaviour ships behind a flag to Anthropic employees first, then to the latest channel, with stable trailing.

• Fast detection and rollback. Flags turn off without a deploy, there is a weekly on-call rotation, and incident reviews ask which layer should have caught the issue. Some mistakes will still get through, so the last layer is about noticing them quickly rather than preventing them.

The change sets the tier, not the author

A docs fix and an auto-updater change do not carry the same risk, so they do not get the same review. The post's table has three tiers and each one answers a single question: how many people, if any, have to approve this before it merges.

Low covers documentation, copy, internal-only features and additive changes behind a flag; once automated review and security are green, no person is required. Medium covers ordinary product changes plus sensitive areas such as caching, the auto-updater and system prompts, and needs one person. High covers the highest-risk code and a small set of paths that always need two people.

The classifier is only half the design. A second classifier asks whether this particular change needs another person even when its tier says it does not. Some paths always need a person regardless of tier: anything owners have listed as sensitive, and any CI workflow file. Only authors on the repository's trusted list, mostly the owning team, get the lighter paths; everyone else needs a second person. An agent's approval never counts as a person's, so automated review can clear a low-risk change but cannot fill a slot that calls for a human. Whoever prompted the change is on the hook for it. And an approval covers one specific commit, so a new commit, including an agent's push or a hand-resolved merge, needs the approval again.

Two details are worth stealing even if you never build a classifier. The tier comes from the change, not the author, and trust is a separate, narrower gate on top of it. And an approval is bound to a commit rather than to a pull request, which closes the most common hole in review systems: a green tick earned early in a branch spent on code nobody has looked at.

The reviewer is trained against their own incidents

This is the part most write-ups skip, and it explains why the arrangement keeps working rather than drifting.

The team collected past pull requests that caused incidents, along with their fix-forwards and reverts, and had engineers who know that code confirm each bug and where it lived. That collection is now an eval. The reviewer runs against it daily. When its prompts, tools or model change, the change has to survive the whole set: keep it if the score goes up, drop it if not. Their failures became the test suite for the thing supposed to catch their failures.

That is a different posture from tuning a linter, which is judged against a fixed rule set. This reviewer is judged against the specific ways this codebase has already broken, so the eval grows every time something goes wrong. No score for it appears in anything Anthropic has published that we read, and the post does not claim the reviewer is finished.

The layer that is not built yet

Here is the admission that makes the post credible. Everything above describes a system that catches and reverses mistakes, not one that notices its own error rate changing. The team does not yet have circuit breakers that tighten approval automatically when revert or incident numbers move, and engineers there want them before more code moves to zero-human merges.

What exists instead is human noticing. Flags turn off without a deploy, the weekly on-call rotation watches, and incident reviews ask which layer should have caught the issue. One colleague's line is the most useful sentence for anyone planning a similar rollout: slowing down does lower your error rate, but mostly because you are doing less of everything. The team would rather get faster at noticing and fixing problems than slower at producing them.

Read the seven steps again with that in mind. Six decide whether a change proceeds. The seventh is a set of habits for noticing afterwards. There is no feedback loop wired from the outcome back into the gate, and the people who built the system say so.

Review's second job, which the post mostly sets aside

The post is explicit that code review does two jobs: find and fix issues before they ship, and build shared context across the team. It focuses on the first, then comes back to the second with an unusually honest answer: there is no formal process for it, nobody keeps a complete mental model of Claude Code in their head, and they do not think anyone needs to. Want to understand part of the codebase? Ask Claude for an explainer of exactly that slice.

Two instruction files carry the context that used to live in reviewers' heads. CLAUDE.md tells Claude what the project is, the stack, conventions, goals and non-goals, kept short on purpose. REVIEW.md is written by code owners and says what failure looks like in their part of the code, which paths to skip, and asks for a file and line rather than a guess.

Accountability gets a line of its own: you land it, you own it. Merge a small or medium change and something goes wrong, and the norm is that you fix it. That works because changes are small, because flags and reverts undo most mistakes in minutes, and because blast radius sets the bar for how many checks a change gets. It is a norm layered on top of the approval rule, not a replacement for it.

Where a router fits, and where it does not

The pipeline above is a pipeline of model calls: a review agent reading a diff against a whole repository, several bug-hunting agents in parallel, a group voting on each finding, a security pass, and the reviewer re-run daily against a growing eval. That is a routing problem before it is a review problem, because one provider having a bad afternoon should not stop a merge queue.

OrcaRouter is one OpenAI-compatible endpoint for more than 200 models on one key, with automatic failover across providers and zero markup, meaning provider list price passed through. Teams running their own version of this pipeline get one billing relationship and one place to switch a model when a reviewer's quality changes, which is exactly what the daily eval is designed to detect.

The boundary matters. We host models. We do not host Claude Code, we do not run Code Review for Claude Code, and we have no access to the pipeline this article is about. Code Review for Claude Code is Anthropic's product, generally available on Team and Enterprise plans, with a lighter version available locally as /code-review. If what you want is that pipeline, that is where it lives; on your own team's version of it, a router is a plumbing decision rather than a review decision.

What a smaller team can actually copy

Write the review rules down where the reviewer can read them: a short CLAUDE.md for the project and a REVIEW.md per area that names what failure looks like and demands a file and line instead of a guess. Put the risk tiers in writing, make them a property of the change rather than the author, start strict and loosen only with evidence. Cap what automated review can approve and never let an agent's approval count as a person's. Bind approvals to commits. Run the merge queue. Turn incidents and reverts into test cases and re-score the reviewer whenever you change it, because an unmeasured reviewer is a linter with better marketing.

Then watch the guardrail, not the approval time. The team's own framing gives you the test for any review change you are considering: did revert and incident rates hold, or did the time simply move from the reviewer to the person cleaning up afterwards? That question is answerable with data most teams already have, and it separates a process that got faster from one that only looks faster for a quarter.