What Anthropic actually reported
The post describes a goal and a guardrail. The goal is that most PRs merge with at most one human in the loop. The guardrail is that reverts and incidents must not rise. Anthropic reports that from June to September, merged PRs to the Claude Code codebase more than doubled while the share that had to be reverted fell by more than 40 percent[1]. In the wider monorepo, daily landed changes went from about 2,500 in May to more than 30,000 in September.
Those are the company's own numbers. The post gives no sample sizes and nobody outside Anthropic has checked them, so treat them as a direction, not a benchmark. The useful part is the structure, which is seven layers where each one catches what the previous one missed.
The seven layers in Anthropic's words
- Verify before anyone looks. Claude runs tests, builds or screenshot comparisons, and a subagent with fresh context reviews the diff.
- AI review on every PR. Several agents hunt for bugs in parallel, verifiers vote on each finding, and only findings enough verifiers agree on get posted, tagged Important, Nit or Pre-existing.
- Security review that can block. A PR cannot merge while any finding from the bug review or the security review is still open.
- Automated checks that block. Lint, type checks, tests on every platform and a build. A typical CLI PR may run dozens of checks.
- Human approval scaled by risk. More on this below.
- Merge queue, flags and gradual release. The queue re-runs checks against main, new behavior ships behind flags to employees first, and public releases go to the
latest channel before stable.
- Fast detection and rollback. Flags turn off without a deploy, and there is a weekly on-call rotation.
How the human approvals are tiered
A classifier reads the change and picks the risk tier, so the tier follows what the change touches and not who wrote it. Low-risk changes (docs, copy, internal-only features, additive changes behind a flag) need no human once automated review and security checks are green. Medium risk (ordinary product changes plus sensitive areas such as caching, the auto-updater or system prompts) needs one person. High risk needs two. A second classifier can force a person in even when the tier would not[1].
Three rules in the post are worth copying word for word in spirit. An agent's approval never counts as a person's. On agent-written PRs, the person directing the agent counts as one of the required reviewers. And an approval covers one specific commit, so a push after approval should reset it.
Layer-by-layer: what a small team does instead
This table is my recommendation. The first two columns are Anthropic's design as reported[1]; the last three are what I think a one-to-ten person team can do and when to skip it.
If you only do three things, do layers 4, 5 and 7. Required checks, a risk rule and a practiced rollback prevent more damage than any AI reviewer.
The small-team setup, step by step
Step 1: Write a short REVIEW.md
Anthropic says REVIEW.md is written by code owners and tells the reviewer what matters in their part of the code. The post recommends keeping it short, stating what failure looks like in your repo, capping nits, listing paths to skip, and asking for a file and line as evidence instead of a guess from a name[1]. Per the Claude Code docs, the hosted review reads REVIEW.md from the base or default branch, never from the PR's own changes[2]. That matters: a PR cannot rewrite its own reviewer's instructions.
Here is a starter I wrote for a typical web app. Edit the first section to match what breaks in your repo.
# REVIEW.md
## What failure looks like here
- Charging or refunding the wrong amount, or charging twice
- A route that returns data for a user who does not own it
- A migration that locks a large table or cannot be rolled back
- A background job that retries a non-idempotent action
## How to report
- Cite the file and line for every finding. If you cannot, drop it.
- Report at most 3 nits per PR. Prefer zero.
- Label each finding: Important, Nit, or Pre-existing.
- Do not comment on formatting. The linter owns that.
## Skip
- generated/**, **/*.snap, package-lock.json, docs/**
## Always flag
- Any change under auth/, billing/, migrations/ or .github/workflows/
- New environment variables or secrets read at runtime
- Any removed test without a replacement
Pair it with a CLAUDE.md that covers how code should be written. I covered what survives in production in CLAUDE.md rules that survive production. REVIEW.md is the reviewer's brief; CLAUDE.md is the author's.
Step 2: Add a risk-tier rule you can compute
Anthropic uses a classifier. You can get a decent first version from file paths and diff size. This is my recommendation, not Anthropic's rule, and you should tune the numbers after a month of data.
On a team of three, "2 people" may mean the author is one of the two. That is fine if you keep Anthropic's rule that the person directing an agent counts as a required reviewer, and the AI never counts as a person.
If you would rather not hand-build the tier script, the WOWHOW AI Code Review Pipeline Kit packages a REVIEW.md template, a path-and-size risk-tier classifier, a GitHub Actions approval gate and a findings parser. Everything in this post works without it.
Step 3: Set the GitHub branch protection that makes it real
A rule nobody enforces is a suggestion. In GitHub's protected-branch settings, these are the options that map to the layers[3]:
- Require pull request reviews before merging, with the number of required approvals set to 1 on your default branch. GitHub's current UI may label this "Require a pull request before merging"; the page I checked uses the first wording.
- Require status checks before merging, with the checkbox "Require status checks to pass before merging". Add lint, types, tests, build and your security job by name.
- Require branches to be up to date before merging, so checks run against current main.
- Dismiss stale pull request approvals when new commits are pushed. This is the setting that gives you Anthropic's "an approval covers one specific commit".
- Require merge queue, if main breaks often enough to justify it.
- Code owner review through a CODEOWNERS file for your high-risk paths, so those need a named owner.
GitHub treats rulesets as a separate feature from classic branch protection. Either route works; use one, not both, to avoid conflicting rules.
The two-approval rule for high-risk paths does not exist as a single checkbox. Branch protection applies one approval count to the whole branch. To get tiers, use CODEOWNERS for the sensitive paths, or run a small workflow that reads the changed files, computes the tier, and fails a required check until enough approvals exist. That workflow is the only custom code in this whole setup.
Step 4: Decide where the AI review runs
You have four options, and the docs list them side by side[2]:
- The hosted Code Review, for organizations on Team or Enterprise plans with GitHub repositories, turned on by an Owner. Reviews run on Anthropic infrastructure and come in Quick, Standard and Deep levels.
/code-review in your own Claude Code session, on any plan.- Claude in your own CI through GitHub Actions or GitLab CI/CD, using an API key.
- Your own reviewer as a subagent or skill.
One detail trips people up. Anthropic's post says its internal setup blocks merge on open findings. The public docs say the hosted review never approves or blocks a PR, and its check run does not conclude as a failure[2]. So if you want blocking findings, you build it: run a security job in CI that fails on findings, and make it a required status check. The post does not give pricing, and I am not quoting any; check the Code Review costs page before turning it on across many repos.
Step 5: Make rollback boring
Layer 7 is the one small teams skip, and the one that saves a Friday evening. Pick a rollback you can run in one command, run it once against staging this week, and write down who is on call. If you ship behind a flag, test that flipping it off actually removes the behavior. Pair this with a regression check on the model itself; WOWHOW built one for that in the 20-task eval canary, and the Model Regression Canary packages it.
Honest trade-offs
AI review is noisy until you tune it. Anthropic's own fix is verifier voting and a nit cap, which is why the REVIEW.md above caps nits at 3. Without a cap, people learn to ignore the bot within a week.
A clean review is not a safe PR. The Claude Code docs say it directly: Code Review uses AI and may miss bugs and vulnerabilities, and a review with no findings does not mean the code is error-free or secure[2]. The docs also note that a review reads the diff and surrounding code without building or running it. Your tests are still the thing that runs the code.
Zero-human tiers carry real risk. The post itself says Anthropic lacks circuit breakers that tighten approval when its numbers move. If you allow zero-approval merges for low-risk changes, keep the definition narrow and review the list of auto-merged PRs weekly.
Cost scales with PR volume. A deeper review level costs more per PR. Use Quick on routine repos and Deep only where a bug is expensive, as the docs suggest.
Your failure modes are not Anthropic's. Agent-written code fails in recognizable ways. The 14-item failure mode taxonomy is a good source for filling in the "what failure looks like here" section of your REVIEW.md.
Frequently asked questions
Is Code Review for Claude Code available on every plan?
No. The hosted Code Review is generally available on Team and Enterprise plans and works with GitHub repositories[1][2]. The local /code-review command runs in your Claude Code session on any plan.
Does the AI reviewer block merges?
The public docs say the hosted review never approves or blocks a pull request, and its check run does not conclude as a failure[2]. Anthropic's post describes its own internal setup, where open findings do block merge. To get that behavior, make your own CI job a required status check.
Can a solo developer use this?
Yes, with a smaller version. Keep required checks, a REVIEW.md, an AI review pass and a tested rollback. Skip human tiers, since you are the only human. Use the risk tier to decide how long you read the diff yourself.
Where does REVIEW.md go and who can edit it?
It lives in the repository. The hosted review reads it from the base or default branch and never from the PR under review, so a PR cannot loosen its own review rules[2].
What does it cost?
Anthropic's post gives no pricing. The docs have a separate page on Code Review costs and usage, and a deeper review level costs more than a lighter one[2]. Check that page for current numbers before enabling it widely.
Sources
- Anthropic: how the Claude Code team does code review (published 15 October 2026, accessed 18 October 2026)
- Claude Code docs: Code Review (accessed 18 October 2026)
- GitHub docs: about protected branches (accessed 18 October 2026)
Comments · 0
Beta: comments are stored locally on your device and not visible to other readers.
No comments yet. Be the first to share your thoughts.