How Anthropic does code review on Claude Code: the automated layers, the risk-based human approvals, and what a small team can copy.
From June to September, merged pull requests to the Claude Code codebase more than doubled while the share that had to be reverted fell by more than 40 percent, and humans no longer read every line of the roughly 90 percent of the code that Claude writes. Anthropic's code review process stacks automated layers (self-verification, an AI bug review with voting verifiers, a blocking security review, required CI), then asks for zero, one or two human approvals by risk, with revert and incident rates as the guardrail.
Sources: How the Claude Code team does code review (claude.dev, Oct 15, 2026)
A small team can copy most of it with GitHub settings and a few Claude Code commands. A few pieces depend on Anthropic's scale, internal tooling and tolerance for risk, and those deserve a harder look. The most transferable lesson is also the cheapest: one pull request went through more than fifty rounds of review and fixes overnight, and part of the fix was a plain rule, after three rounds, rethink the approach.
Sources: How the Claude Code team does code review
The post, published on October 15, 2026 by Addy Osmani, Morgan Westlee Lunt and Qing Wang, describes in detail how an AI-coding vendor reviews its own AI-written code. It landed the same day Anthropic made its hosted Code Review product generally available, and the Hacker News thread passed 400 comments. Below: each layer, what a team without Anthropic's infrastructure can run instead, and the objections worth taking seriously.
Sources: Code Review is now generally available (Claude, Oct 15, 2026), Hacker News discussion
Disclosure: we build TLM Forge, a process layer for Claude Code that runs reviews before code ships, so weigh the product section near the end accordingly.
What Anthropic says changed, in numbers
Merges more than doubled and the revert share fell by more than 40 percent between June and September, and the team says it got there without removing review. It moved most of the reading to machines and invested in making mistakes fast to undo.
Sources: How the Claude Code team does code review
The volume pressure behind it is real. Anthropic's source control team reports that the company averaged around 2,500 merged code changes per day in May 2026 and more than 30,000 per day by September. Members of that team still review every change, but now "examine the intent of the change as opposed to reading every line of code." Very often, the post says, the engineers' role was to tell Claude "no."
Sources: Redesigning source control at Anthropic (Anthropic Engineering)
Read the 30,000 figure carefully: it describes Anthropic's monorepo. Claude Code lives in its own repository, so the figure is context, not Claude Code's own merge rate. CI strain from that volume is a separate story, covered in how Anthropic rebuilt its CI for agent-scale volume.
The goal is stated precisely: most pull requests in the Claude Code repos should merge with at most one human in the loop, who can be the author, with no increase in reverts or incidents. The team tracks human approvals per PR at the median and the 95th percentile, human comments, and how long a PR waits on a person. In the authors' words, "Revert and incident rates are the guardrail."
Sources: How the Claude Code team does code review
How Anthropic does code review, layer by layer
The process is a set of layers, each built to catch what the others miss, with fast rollback underneath. In order:
- Verification before the PR: Claude gets something it can run (tests, a build, or a screenshot to compare against the design) and shows the output, then a subagent reviews the diff in a fresh context. CLAUDE.md holds conventions; REVIEW.md, written by code owners, says what matters in each part of the code.
- 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 get posted. Style-only findings are dropped. Survivors are tagged Important, Nit or Pre-existing.
- A security review that can block: a PR cannot merge while any finding from the bug review or the security review is still open. Each one is fixed or closed with a short reason.
- Required CI: lint, type checks, tests on every platform, and a build. The PR template asks how the change was tested and how to undo it.
- Risk-based human approval: a classifier picks the tier from the change, and a second classifier asks whether this particular change needs another person anyway.
- Merge queue, flags and staged release: checks rerun against the latest main, new behavior ships behind a flag to employees first, and the latest channel goes out before stable.
- Fast detection and rollback: flags turn off without a deploy, a weekly on-call rotation watches, and incident reviews ask which layer should have caught the problem.
The approval rules are the part most teams will argue about. Low-risk changes (docs, copy, internal-only features, additive changes behind a flag) need no human approval once automated review and security checks are green. Medium-risk changes, which include ordinary product work and sensitive areas such as caching, the auto-updater and system prompts, need one person. High-risk code, plus a small set of paths, needs two. Four rules hold the tiers together. First, "The change sets the tier, not the author." Second, only authors on the repo's trusted list get the lighter paths. Third, "An agent's approval never counts as a person's." Fourth, an approval covers one specific commit, so an agent's later push means approving again. On an agent-written PR, the person directing the agent counts as one of the required reviewers.
Sources: How the Claude Code team does code review
How to copy Anthropic's code review process on a small team
Anthropic's post ends with its own adoption checklist. The table below maps those practices to a concrete setting or command, and flags one trap: local /code-review does not read REVIEW.md, so review rules for local runs belong in CLAUDE.md.
Nearly every layer has a cheaper equivalent. The table below pairs each Anthropic practice with what it does and the closest version a small team can set up today without internal classifiers or an eval pipeline. For deciding which changes need a person in the first place, our guide to approval gates for high-risk AI changes goes deeper than this summary.
| Anthropic practice | What it does | Small-team approximation |
|---|---|---|
| Claude verifies its work, then a fresh-context subagent reviews the diff | Catches routine mistakes before anyone else spends time | Ask for test and build output, not "done". Run /code-review locally; it works on any plan |
| REVIEW.md written by code owners | Tells the reviewer what failure means in each area, caps nits, lists paths to skip | Hosted Code Review reads REVIEW.md. Local /code-review does not, so put review rules in CLAUDE.md |
| Parallel bug hunters plus voting verifiers | Posts only findings several agents agree are real | Hosted Code Review on Team or Enterprise, or two independent reviewer subagents whose findings you cross-check |
| Open findings block the merge | Every finding is fixed or closed with a reason | GitHub branch protection: require conversation resolution before merging |
| Separate blocking security review | A second pass focused on vulnerabilities | /security-review, or the open-source claude-code-security-review GitHub Action on trusted PRs |
| Risk tiers set by a classifier | Zero, one or two human approvals by blast radius | Write the tiers down; use CODEOWNERS and required reviews so auth, billing, CI and release paths always need a person |
| Approval covers one commit | An agent push after approval needs a fresh approval | GitHub branch protection: dismiss stale approvals when new commits are pushed |
| Review rounds capped at three | Stops agent author and agent reviewer looping | A written rule: after three rounds, rethink the approach; re-review only the new diff |
| Incidents and reverts become reviewer evals | Every reviewer change is scored against past real bugs | Keep a folder of past bad PRs and rerun your reviewer prompt on them whenever you change it |
The GitHub rows are standard branch protection, and together they approximate "approval covers one commit" and "every finding has to be answered" without custom tooling.
Sources: GitHub Docs: About protected branches
Three changes to make this week: require conversation resolution before merging, dismiss stale approvals when new commits are pushed, and cap AI review rounds at three.
Fifty review rounds overnight, and the three-round fix
An agent author and an agent reviewer can keep each other busy indefinitely. One Claude Code CLI pull request 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% was code that had been there since the reviewer's first pass: it was rarely finding new bugs, just a few more old ones each round. The fixes were a cap (after three rounds, the reviewer asks the author to reconsider the approach), diff-only re-review after the first few passes, flagging the whole class of bug so every instance gets fixed, and no repeated findings.
Sources: How the Claude Code team does code review
The results on internal pull requests: the share passing after one review-and-fix round rose from 65% to 78%, the share needing five or more rounds fell from 8.9% to 1.5%, and mean reviews to pass dropped from 2.08 to 1.32. This is the cheapest part to copy. It is a rule, not a system: after three rounds, stop and rethink the approach. For why several independent reviewers still beat one, see multi-agent code review.
Sources: How the Claude Code team does code review
Where humans stay in the loop
The post lists five jobs that stay with people: deciding whether to build something at all, risky code such as billing, the auto-updater and CI workflows, architecture that sets a pattern others will copy, reading the evidence (test output, the command that ran, screenshots, the reviewer's findings), and owning the outcome. Its line on accountability is blunt: "A person is accountable for every change that ships, whoever typed it." A small team can adopt that list as-is.
Sources: How the Claude Code team does code review
Where approaches differ: the open questions
The process is coherent, but several parts of it rest on conditions most teams do not share. The Hacker News thread surfaced the objections clearly, and the post itself concedes some of them.
Low-risk changes merging with zero human approvals
This is the sharpest difference from conventional practice. One commenter wrote that their SOC 2 reviewer had said all code must be reviewed by at least one other human before production, and asked how "at most one human in the loop, who can be the author" squares with that, and with insider threats. The post does not address compliance. It does admit a gap of its own: "We don't yet have circuit breakers that tighten approval when those numbers move," and says engineers want them before more code moves to zero-human merges. If you operate under audit requirements, our post on AI agents and segregation of duties under SOX and PCI-DSS covers why an AI second pass is not a second accountable party.
Sources: Hacker News: compliance question (gaal_dornick), How the Claude Code team does code review
Clearing a security finding with a short reason
Under the process, you clear a false positive by closing the thread with a short reason. One commenter pushed back: "Dismissing a critical finding as a false positive should still involve AppSec." The same commenter pointed to the README of the open-source security review action the post links to, which states that it "is not hardened against prompt injection attacks and should only be used to review trusted PRs." A sensible small-team rule: anyone can close a low-severity finding with a reason, but closing a critical or high security finding needs a second named person.
Sources: Hacker News: security findings (vavkamil), anthropics/claude-code-security-review README
Test quality at this volume
Several layers lean on tests, and the post says little about how test quality is kept up. One commenter asked directly how the team maintains "the quality of tests for such a massive codebase and frequent commits," and the post does not answer it. A related critique: if the only outcome metrics are revert and incident rates, another commenter argued, they miss "the long-term, cumulative impact of compounding complexity due to poor architectural decisions." Reverts measure what breaks quickly. They do not measure a test suite that passes because it checks too little; for the agent side of that problem, see how to stop Claude Code changing tests to pass.
Sources: Hacker News: test quality (nakul_), Hacker News: compounding complexity (senderista)
Not every stack is this easy to verify
The process depends on Claude being able to run tests and builds quickly, and on feature flags and staged releases that undo most mistakes in minutes. A commenter working on a compiled project noted that slow compiles and integration test runs that take hours make tight agent feedback loops much harder than they are for Claude Code. If your rollback takes hours, the "you land it, you own it" model carries more risk, and the approval bar should rise to match.
Sources: Hacker News: compiled projects (chris_money202), How the Claude Code team does code review
What the hosted Code Review product does, and does not
Code Review for Claude Code left research preview and became generally available on October 15, 2026, for Claude Team and Enterprise organizations. Admins choose Quick, Standard (the default) or Deep for each repository, and Anthropic says most reviews now finish about three times faster than during the preview, roughly 6 to 10 minutes instead of about 20. There is no flat per-review price: reviews are billed on token usage through usage credits, separately from your plan's included usage.
Sources: Code Review is now generally available, Claude Code docs: Code Review costs and usage
The documented limits matter, because the product is narrower than the internal process. Findings arrive as inline comments with a summary and a check run, and per the docs, "A review never approves or blocks the pull request, so the decision to merge stays with your team." The check run does not conclude as a failure. A review works from the diff and surrounding code "without building or running your code," with read-only access to the repository. It reads REVIEW.md from the base or default branch, never from the pull request's own changes, so a PR cannot rewrite its own review rules. It is not available to organizations with Zero Data Retention enabled.
Sources: Claude Code docs: Code Review, Claude Code docs: Customize Code Review
| Capability | Anthropic's internal process | Hosted Code Review (GA) |
|---|---|---|
| Blocks a merge on open findings | Yes, bug and security findings | No; it never approves or blocks. Add GitHub branch protection yourself |
| Builds or runs your code | Yes, Claude runs tests and build before the PR, plus required CI | No; it reads the diff and surrounding code |
| Human approval tiers | Zero, one or two people by risk | Not included; merging stays with your team |
| Security review | A separate blocking pass | Looks for security vulnerabilities alongside bugs, but focuses on correctness by default and never blocks; tune it with REVIEW.md |
| Review depth | Matched to risk | Quick, Standard or Deep per repository |
One dating note. The most quoted Code Review statistic, that the share of internal PRs getting substantive review comments went from 16% to 54%, comes from the research preview launch on March 9, 2026, not from the GA release. The same preview post reported that 84% of PRs over 1,000 lines got findings, averaging 7.5 issues, and that less than 1% of findings were marked incorrect. Treat those as March 2026 internal preview figures.
Sources: Bringing Code Review to Claude Code (Mar 9, 2026)
Where TLM Forge fits
The pain this post keeps returning to is matching review effort to risk, and making sure a review still applies to the code that actually ships. TLM Forge works on that problem inside the Claude Code session. It sizes each task Light, Medium or Deep. Unlike Anthropic's lowest tier, which still gets automated bug and security review, Light work gets no review agents at all.
On Medium and Deep, a final review wave by independent reviewer agents reads the change: code-reviewer and phase-auditor on Medium, plus tester, red-team-reviewer and architect-reviewer on Deep, plus ux-reviewer when UI changes. CRITICAL and HIGH findings are fixed test-first or brought to you; MEDIUM and LOW go on a written list. Its reviewers are agents, so by Anthropic's own rule their sign-off does not count as a person's. A commit hook blocks git commit, git push and gh pr merge when the code has changed since the final review, the same idea as an approval that covers one commit. It is on for everyone, and TLMFORGE_HOOKS=0 turns hooks off. None of this makes code secure or bug-free, and it does not replace human approval on risky paths.
Frequently asked questions
01How does Anthropic do code review on Claude Code?
Claude verifies its own work, then parallel AI reviewers with voting verifiers and a separate security review check every PR. Open findings block the merge. A classifier then requires zero, one or two human approvals by risk, and an agent approval never counts as a human one.
02Does Claude write 90% of Claude Code?
Anthropic says Claude writes about 90 percent of Claude Code's own code. The 30,000 merged changes per day often quoted alongside it refers to Anthropic's whole monorepo as of September 2026, not the separate Claude Code repository.
03Does Claude Code Review approve or block pull requests?
No. Per the docs, a review never approves or blocks the pull request. It posts inline comments, a summary and a check run that does not conclude as a failure. To block merges on findings, add GitHub branch protection such as required conversation resolution.
04Can I copy Anthropic's review process without Team or Enterprise?
Mostly. Run /code-review locally (it works on any plan) plus /security-review, put review rules in CLAUDE.md (local /code-review does not read REVIEW.md), require resolved conversations and code owner reviews in branch protection, and cap review rounds at three.
05How much does Claude Code Review cost?
There is no flat per-review price. Code Review is billed on token usage through usage credits, separately from your plan's included usage. Cost scales with the review level, the size of the change and how often reviews run. A repository added from the admin page starts at After every push, which runs the most reviews.