How the big players review code: inside the Claude Code team

Anthropic's monorepo averaged about 2,500 merged changes a day in May and more than 30,000 a day in September. In Claude Code's separate repository, merged pull requests more than doubled from June to September, while the share that had to be reverted fell by more than 40%. Those two figures are relative, with no baseline, and they come from a company that sells a code review product.

Human time is the measure, the revert rate is the guardrail

The team considers "did a human read this code?" a poor stand-in for the real question: what could go wrong with this change, and which check, automated or human, is the right one to catch it? The goal: most pull requests in the Claude Code repos (the CLI, the desktop, web and mobile apps) should merge with at most one person in the loop, even if that is just the author, and with no rise in reverts or incidents.

Human time is measured through approvals per PR (median and 95th percentile), comments from people, and how long a PR waits on a person. Revert and incident rates are the guardrail: if they rise, the time saved on review has simply moved into fixes.

Six layers of checks, and a fast way back

Each layer catches some bugs and lets others through. Few get past all of them, and a fast rollback waits for the ones that do.

• Verification before the PR. The agent gets something it can run, such as tests, a build or a screenshot to compare against the design, and has to show the output instead of announcing it is done. Then a subagent with fresh context reads the diff. Boris Cherny, who created Claude Code, estimates that this feedback loop makes the final result two to three times better.
• AI review on every PR. Several agents hunt for bugs in parallel, a separate group votes on each finding, and only findings that enough of them agree on get posted, minus style-only remarks. Every comment is tagged Important, Nit or Pre-existing, and the last of these keeps a bug the PR did not introduce from looking like the author's fault. Every one must be answered with a fix, or closed with a reason.
• A security review that can block. While any finding from the bug review or the security review is still open, the PR cannot merge.
• Checks in CI: lint, type checks, tests on every platform and a build. The PR template asks how the change was tested and how to revert it. Claude can fill that in, but the person who asked for the change signs off on it.
• Approval scaled by risk. Docs, copy, internal-only features and additive changes behind a flag need no person once automated review and security checks are green. Ordinary product changes and sensitive areas such as caching, the auto-updater or system prompts need one person, and the riskiest code needs two.
• A merge queue, flags and a staged release. The queue re-runs every check against main with the change applied, so two PRs that pass separately cannot combine into a broken main. New behaviour usually goes to Anthropic employees first, and public releases go to the latest channel, with stable trailing behind.

Under all of it sits a fast rollback: a flag switches off without a deploy, and incident reviews ask which layer should have caught the problem.

The change sets the risk, not the author

A classifier reads the change and sets its risk tier, and a second one asks whether this particular change needs another person even when its tier says it does not. Paths that owners have marked as sensitive, and every CI workflow file, always need a person. Only authors on the repo's trusted list get the lighter approval rules, mostly the team that owns the repo.

Three rules are the easiest part to copy. An agent's approval never counts as a human approval. On a PR written by an agent, the person who directed the agent is one of the required reviewers, as if they had typed the code themselves. An approval covers one specific commit: when a commit lands that the system cannot vouch for, such as an agent's push or a merge someone resolved by hand, the PR has to be approved again.

People keep what automation cannot judge: whether to build the thing at all, reviewing billing, auto-updater and CI code and architecture that others will copy, and weighing the evidence, such as test output and screenshots. The team's rule: if you cannot say what the checks would miss, ask for a real review rather than a quick approval.

A reviewer that would not stop

The most instructive part is a mistake the team made itself. An agent author and an agent reviewer can keep each other busy indefinitely: one PR in the CLI project went through more than 50 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% of it was code that had been there since the reviewer's first pass. The reviewer was rarely finding new bugs; it was finding a few more old ones each round.

A person waves off a nit in seconds. An agent fixes it, which means another commit and another round. So the team changed re-review: after three rounds the reviewer asks the author to rethink the approach, after the first few passes it reads only the new diff, it flags the whole class of bug so the author fixes every instance at once, and it never repeats a finding already posted.

The reviewer's progress is measured on a test set of PRs that caused incidents, with each bug and its location confirmed by engineers who know that code. The reviewer runs against the set every day, and every change to the reviewer is scored against all of it. Noise is measured by what people do with the comments: whether they fix the code or call the remark wrong or irrelevant. On PRs known to be clean, the team counts reports that would have led someone to make a harmful change.

What a team of five can take from this

A small company needs neither risk classifiers nor a merge queue. Three things are enough. The first is a PR template with the fields Anthropic recommends: testing, risk and how to revert. GitHub picks it up from .github/pull_request_template.md:

## Testing
<!-- The commands you ran and their output. A screenshot for UI changes. -->

## Risk
<!-- Low, medium or high. What does it touch: payments, customer data, CI? -->

## How to revert
<!-- Revert the commit, switch off the flag, or the manual steps. -->

## Owner
<!-- If an agent wrote the code: the person who directed it. -->

The second is three GitHub branch protection settings close to Anthropic's rules. Dismiss stale pull request approvals when new commits are pushed voids an approval when the diff changes. Require review from Code Owners, together with a CODEOWNERS file, requires a code owner's approval for changes to auth, billing, installers, and CI and release workflows. Require conversation resolution before merging keeps any PR with an unresolved thread from merging, including threads opened by the AI reviewer. In private repositories, branch protection needs GitHub Pro, Team or Enterprise.

The third, for companies on a Claude Team or Enterprise plan that turn on Code Review, is a REVIEW.md file at the repository root. The service reads it from the base or default branch and never from the PR's own changes, and path exclusions, nit caps and lowered severities only apply when the file sits on a protected branch. The local /code-review command reads CLAUDE.md but not REVIEW.md, so keep rules meant for both tools in CLAUDE.md.

# Review instructions

## What Important means here
Reserve Important for findings that change an amount on an invoice or
an order, show one customer's data to another, write personal data to
logs, or block a rollback. Style and naming are Nit at most.

## Cap the nits
Report at most five Nits per review.

## Do not report
- Anything CI already enforces: lint, formatting, type errors
- Generated files under `src/gen/` and any `*.lock` file

## Always check
- Every database query is scoped to the current customer
- Amounts are integer cents, never floating point numbers
- A claim about behaviour cites file:line, not a guess from a name

## Summary
Start with the number of findings. If there is nothing to fix, say so.

There is no flat price: cost grows with the size of the change and the review level. At launch in March, Anthropic said a review averaged 15 to 25 dollars and took around 20 minutes, which at 80 PRs a month and one review per PR comes to 1,200 to 2,000 dollars. A repository added from the admin page starts with a review after every push, though, which multiplies the cost by the number of pushes, so for a pilot switch it to one review when the PR opens and set a monthly spend limit. The Claude Code GitHub Action with your own API key is lighter and, by Anthropic's account, cheaper, and the /code-review command runs in a Claude Code session on any plan. The service is not available to organisations with Zero Data Retention turned on.

First step: a list of reverts

Before you pay for any tool, start a spreadsheet. Log every PR that had to be reverted or caused an incident, with a link to the fix and one sentence on where the bug was. Anthropic turned a list like this into the set it checks its reviewer against every day. After a quarter, yours is the first honest test of any AI reviewer: run it on those PRs and count the bugs it finds, then run it on a few clean ones and count the false alarms.

If a software house writes your code, ask who is accountable for a change an agent wrote, whether a bot's approval counts as an approval, and how many minutes it takes to roll back a bad deploy.