How the Claude Code Team Does Code Review: Risk Tiers and Round Caps

Anthropic's Claude Code team has published how it reviews code when Claude writes about 90 percent of it: most of the reading moved to machines, human approval is scaled to risk, and the goal is the minimum human review time that does not raise reverts or incidents. The post is How the Claude Code team does code review (October 15, 2026), and the query "how the Claude Code team does code review" is one of the fastest-rising related searches for "claude code" on Google Trends this week (+130% over seven days).

Last updated: November 1, 2026

Our earlier post on Claude Code Review levels covered the product setting. This one covers the process around it, which is the part you can copy even if you never buy the product.

What the post says#

All numbers below are Anthropic-reported, from the post itself.

• Volume is the problem. Changes landing per day in Anthropic's monorepo went from about 2,500 in May to more than 30,000 in September. Claude Code lives in its own repository but sees similar pressure.
• Outcome. From June to September, merged pull requests to Claude Code's codebase more than doubled while the share that had to be reverted fell by more than 40 percent.
• The reframe. "Did a human read the code?" is treated as an imprecise proxy for "what could go wrong with this change, and which check is the right one to catch it?"
• The target. Most PRs merge with at most one human in the loop, who can be the author, with no rise in reverts or incidents. Anthropic tracks human approvals per PR, human comments and wait time, and uses revert and incident rates as the guardrail.

The layers#

The post describes six layers with rollback underneath. In order:

1. Verification before the PR. Claude runs tests, the build and the linter and shows the output, then a subagent reviews the diff in fresh context.
2. AI review on every PR. Several agents hunt for bugs in parallel, a separate group votes on each finding, and only findings enough of them agree on are posted. Style-only findings are dropped. Comments are tagged Important, Nit or Pre-existing.
3. A security review that can block. A PR cannot merge while a finding from the bug review or security review is open. You fix it or close the thread with a reason.
4. Required CI. Lint, types, tests on every platform and a build.
5. Human approval scaled by risk. Low risk (docs, copy, additive changes behind a flag) needs no human once automated checks are green. Medium risk needs one person. High risk and a small set of always-sensitive paths need two.
6. Merge queue, flags and gradual release. Every check re-runs against main with the change applied.

The detail worth stealing is in layer five. The change sets the tier, not the author. A classifier reads the diff and picks the tier, and a second classifier asks whether this specific change needs another person even if its tier says otherwise. An agent's approval never counts as a person's. Whoever prompted an agent-written PR counts as one of the required reviewers. An approval covers one specific commit, so an agent push or a hand-resolved merge resets it.

The part that is not in the product: convergence#

An agent author and an agent reviewer can keep each other busy indefinitely. Anthropic says one CLI PR went through more than fifty 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 percent was code that had been there since the reviewer's first pass: it was finding a few more old bugs each round, not new ones.

The fix is four rules: cap review at three rounds, then ask the author to reconsider the approach; review only the new diff after the first few passes; flag the class of bug so the author fixes every instance; and never repeat a finding already posted. Anthropic reports that after these changes, PRs passing after one round rose from 65 to 78 percent, PRs needing five or more rounds fell from 8.9 to 1.5 percent, and mean reviews to pass fell from 2.08 to 1.32.

The other loop is the eval: the team collected past PRs that caused incidents, had engineers confirm each bug, and runs the reviewer against that set daily. Every incident adds a case. Every change to the reviewer's prompts, tools or model is scored against all of it.

What to do Monday#

The post ends with an adoption list. Three items you can do without any Anthropic product, using only files the post names:

1. Write a REVIEW.md for one directory. The post says good ones are short, say what failure looks like in that repo, cap the nits, list paths to skip, and ask for a file and line as evidence. A starting point in that spirit (our example, not an official template):

# REVIEW.md - billing/

- Failure here means a customer is charged wrongly. Report only that class of bug.
- At most 3 nits. Skip generated files under billing/gen/.
- Every finding must cite a file and line. No guesses from names.
- Start the summary with a count of findings. Say plainly when there is nothing to fix.

2. Add "Testing", "Risk" and "How to revert" to your PR template. The post says Claude can fill it in, but the person who asked for the change signs off.
3. Require CODEOWNERS approval on auth, billing, CI workflows and installers, and dismiss approvals on new commits. That gives you layer five's "some paths always need a person" with settings you already have in GitHub.

If you run reviews through a coding agent, the same ideas apply to how you structure subagents, agent teams and workflows, and to the harness around long-running agents.

What people are actually saying#

The post drew a large Hacker News thread (488 points when we checked). Paraphrasing a few of the comments:

• Review at scale needs a different statistics argument. fipar liked the manufacturing-QA analogy for spot checks but argued it breaks for software: a factory makes many copies of few designs, while code outputs are all different from each other, so spot checks do not carry over cleanly.
• Clean AI code can hide reinvention. bpeng2000 reported that AI tends to add new helpers rather than generalize existing code in a large codebase, and that human reviewers who are not familiar with the codebase like the result because it is easy to review. The duplicates accumulate.
• Guardrails over reading. vb-8448 said the scale of changes requires new approaches, and that the better repos use guardrails to keep PRs small.
• The skeptic's case. troupo asked how anyone knows output is "just good enough" to ship, and argued that nobody has yet shown a significant amount of good software coming out of high-volume AI merging.

The counter-case is also in the post's own text: Anthropic says it does not yet have circuit breakers that tighten approval when revert or incident numbers move, and that engineers want them before more code moves to zero-human merges.

Our read#

The strategic point is that review is turning from a gate into a budget. Once the cheap layers are automated, the scarce resource is a named human's attention, and the design question becomes where to spend it. That favors teams that already write down risk tiers and own their rollback story, and it squeezes tools that sell only "more comments per PR". It also matches the argument in AI code review is the new bottleneck, and shifts the comparison in best AI code review tools from comment volume to noise, convergence and what the tool is allowed to block.

The limit: every figure above is Anthropic reporting on its own repositories, with its own models and a trusted-author list. Treat the numbers as a target to measure against, not a benchmark you will reproduce.

FAQ#

How does the Claude Code team review code?#

In layers: Claude verifies its work before a PR, then required CI, AI review and a blocking security review, then human approval scaled by a risk tier, then a merge queue, flags and fast rollback. Anthropic says most PRs merge with at most one human in the loop.

What is REVIEW.md?#

A file code owners write to tell the AI reviewer what matters in their part of the code. Anthropic says good ones are short, describe what failure looks like, cap nits, list paths to skip and demand a file and line as evidence.

Can an AI approval replace a human approval?#

Not in Anthropic's setup. An agent's approval never counts as a person's, and automated review can clear a low-risk change but cannot fill a slot that calls for a human.

How many review rounds is too many?#

Anthropic capped it at three, then the reviewer asks the author to reconsider the approach, and later passes review only the new diff.

Continue Reading#

• Claude Code Review Levels: Quick, Standard and Deep Explained - the product setting behind layer two
• AI Code Review Is the New Bottleneck - why review capacity is now the constraint
• Best AI Code Review Tools in 2026: CodeRabbit vs DeepSource vs Greptile Compared - how the rest of the field compares
• GitHub Copilot Code Review Effort Levels Are GA: Lite vs Balanced - the same depth-for-cost tradeoff on GitHub
• Long-Running Agents Need Harnesses, Not Hope - the guardrails around unattended agents
• Claude Code - plans, install routes, and alternatives on one page
• Claude Code Mastery course - core workflows, step by step

Sources#

• How the Claude Code team does code review (Anthropic, October 15, 2026) - all process descriptions and figures, Anthropic-reported
• Hacker News discussion, 488 points - the community comments paraphrased above
• Google Trends related queries for "claude code", past 7 days - the +130% rising query