How the Claude Code team does code review

Addy Osmani, Morgan Westlee Lunt and Qing Wang, Claude blog · read 1 Nov 2026 · Original

• dev-workflow
• ai-agents
• engineering-leadership

When change volume outgrew human review, the Claude Code team moved to layered machine review with risk-based human approval, and reverts fell while output doubled.

Learnings

• Volume broke human review. Changes landing per day in Anthropic’s monorepo went from about 2,500 in May to more than 30,000 in September.
• The result. From June to September, merged pull requests more than doubled while the share that had to be reverted fell by more than 40 percent.
• Review has two jobs, and they split them. Catching issues before shipping is handled by layered machine review. Building shared context is replaced by asking Claude for on-demand explainers of a slice of the codebase.
• Layers, not one gate. Pre-PR verification, required CI, AI review on every PR, a separate security pass, risk-based human approval, a merge queue, flags with staged release, and fast rollback through on-call.
• Risk tier comes from what changed, not who changed it. A classifier sets zero, one or two human approvers. Billing, the auto-updater and CI workflows always need a human.
• Agents reviewing agents can loop. One CLI PR went through more than fifty rounds of review and fixes overnight. Fixes: cap rounds at three, re-review only the new diff, and flag a bug class once instead of every instance.
• Measure the reviewer. They track how authors respond to each comment: fixed, rejected, intentional or irrelevant. Findings are cross-checked by several agents before posting. Pass after one review-and-fix round rose from 65% to 78%. Mean reviews to pass fell from 2.08 to 1.32. In the research preview, internal PRs getting substantive comments went from 16% to 54%.

From first principles

Strip the label “code review” and ask what it is for. A second source, Ruben Dominguez’s write-up in The AI Corner, adds outside data.

What is review actually doing? Two verbs hide inside the word. Catching what would break before it ships, and spreading knowledge of the code between people. The Claude Code team split them. Machines now do most of the catching. Spreading happens on demand, by asking Claude to explain the slice of code you need.

What fights it? Volume. A person reads at a fixed speed, and AI output does not. Daily changes in Anthropic’s monorepo went from about 2,500 in May to more than 30,000 in September. Outside Anthropic, Faros AI found high AI adoption brought 98% more merged PRs and 91% more time in review.

Where is the bottleneck? Human attention. Not the model’s ability to write code, and not CI time.

Is the constraint real or believed? The belief is “a person must read every line.” The real requirement is “broken code must not reach users, and when it does, it must come back fast.” A person reading every diff is only one way to meet that, and at this volume not the best one.

What would perfect look like? Every change gets the scrutiny its risk deserves and no more. The team’s target: most PRs merge with at most one human, with revert and incident rates held flat as the guardrail.

So the design follows from the requirement:

1. Machines do the reading machines are good at: tests, lint, types, a fresh-context agent reviewer, a separate security pass.
2. The change sets how many humans look, not the author. Docs and copy: none. Ordinary product code: one. Billing, the auto-updater and CI workflow files: always a person.
3. Undo is part of review. Flags, staged releases and one-step rollback make a missed bug cheap.
4. The reviewer is measured like any other system: an eval set built from past incidents, and every comment scored by what the author did with it.

What breaks it? Agents reviewing agents with no stop rule. One PR ran more than fifty rounds overnight, and about 59% of what the reviewer kept flagging had been there since its first pass. The fix: cap at three rounds, re-review only the new diff, and flag a class of bug once.

Is this a reading problem or a risk problem? A risk problem. Human reading was always a stand-in for controlling risk.

In one sentence: review exists to stop expensive mistakes, so put human eyes only where a mistake is expensive, let machines check the rest, and make every mistake cheap to undo.

What a solo developer working in the terminal can take from it:

• Give the agent checks it can run: a short CLAUDE.md with the stack, conventions and commands, plus formatter and linter hooks.
• Before every PR, run /code-review and /security-review, or a fresh-context subagent on the diff.
• Keep a REVIEW.md: what failure looks like in this repo, paths to skip, at most three nits, and file-and-line evidence for every finding.
• Add “Testing”, “Risk” and “How to revert” to the PR template.
• Write down the paths that always need a human, such as auth, payments, CI and installers, and enforce them with CODEOWNERS and branch protection.
• Cap AI review at three rounds. After that, rethink the approach.
• When a bug slips through, ask what the model did not have in front of it, and put the fix into CLAUDE.md, a skill or a new check.

What struck me

This is a real problem, so I wanted to understand how big tech companies are solving it and what lessons I can learn.

Will I apply it

Yes. Most of the code I write is through the terminal, so this applies directly to my own workflow.

My take

AI writes code at a speed no human can review. The fix isn’t reading faster: put human eyes only where a mistake is expensive and make every mistake cheap to undo.

Applied at Freshly

In progress.