Code review when agents write the code: what a 10-person team can take from Anthropic

Some code in the Claude Code repositories merges with no human approval. Claude writes about 90% of that code, and the team spends human review by risk: none for docs, copy and additive changes behind a flag from trusted authors, one person for ordinary product changes, two for the riskiest code. Machines do the rest of the reading.

TL;DR

• Seven layers of checks. Machines do most of the reading before a person looks.
• The change sets the risk tier, and only trusted authors get the zero-human path.
• An agent author and an agent reviewer can loop all night. Four changes to re-review, including a three-round cap, lifted one-round passes from 65% to 78%.
• June to September: merged PRs more than doubled, the share reverted fell by more than 40%. Internal numbers, and Anthropic sells the reviewer.
• A 10-person team can copy most checks this month. The zero-human tier needs rollback and a revert baseline first.

01 · Seven layers between a prompt and main

The team published the playbook on October 15, 2026. The pressure behind it is volume. In Anthropic’s monorepo, changes landing per day went from about 2,500 in May to more than 30,000 in September, according to its engineering blog. Claude Code has its own repository, and the authors say it feels the same squeeze. Most studies of AI developer productivity found more output per developer, and all of it lands in review.

The authors call “did a human read the code?” an imprecise proxy. The real question is what could go wrong with this change, and which check, automated or human, should catch it. Their answer is a stack:

1. Verified before the PR. The agent gets something it can run (tests, a build, a screenshot to compare with the design) and has to show the output. A fresh-context subagent reviews the diff.
2. AI review on every PR. Several agents hunt for bugs, a separate group votes on each finding, and only findings enough of them agree on get posted. Style-only comments are dropped. Each finding is tagged Important, Nit or Pre-existing and must be answered: fixed, or closed with a reason.
3. Security review that can block. A PR can’t merge while any bug or security finding is open.
4. Required CI. Lint, types, tests on every platform, a build. The PR template asks how the change was tested and how to undo it.
5. Human approval scaled by risk. Sections 02 and 03.
6. Merge queue, flags, staged release. The queue re-runs every check against main with the change applied. New behaviour goes to employees behind a flag first, then to the latest channel, then stable.
7. Fast detection and rollback. Flags turn off without a deploy. Incident reviews ask which layer should have caught the problem.

Source: Claude Code team, “How the Claude Code team does code review”, Anthropic, October 2026.

A person shows up at layer five of seven. By then Claude has usually reviewed and fixed the change at least once.

One detail is worth stealing on day one: REVIEW.md, where code owners tell the reviewer what matters in their part of the code. Good ones are short. They say what failure looks like there: for docs, “it lies”; for config, “it misroutes”. They cap the nits, list paths to skip and demand a file and line as evidence. Something like this (my illustration, not Anthropic’s file):

# REVIEW.md — billing/
Failure here means a customer gets the wrong invoice.
Flag: money math, rounding, currency, retries that can charge twice.
Skip: generated/, *.snap, fixtures/.
At most 3 nits per review.
Every finding cites file:line. Start the summary with a count; say "nothing to fix" if so.

When the reviewer keeps flagging the same thing, the fix goes to the source: CLAUDE.md, REVIEW.md, a lint rule or a skill.

02 · The risk table

Layer five is where the playbook gets specific. The team wants most PRs to merge with at most one human in the loop, and that human can be the author. Reverts and incidents must not rise. Human approval is spent by tier:

Risk	Examples	Human approvals
Low	Docs, copy, internal-only features, additive changes behind a flag	None once automated review and security checks are green
Medium	Ordinary product changes; sensitive areas such as caching, the auto-updater, system prompts	One person
High	The highest-risk code, plus a small set of paths that always need two people	Two people

Source: Claude Code team, Anthropic, October 2026. Lighter paths apply to trusted authors only.

A classifier reads the change and picks the tier. A second classifier asks whether this particular change needs a person even when its tier says it doesn’t. Some paths always need a person: anything owners have listed as sensitive, and any CI workflow file.

Human time is measured as approvals per PR, human comments and how long a PR waits on a person. Reverts and incidents are the guardrail: if they rise, “we haven’t saved human time, we’ve only moved it.”

03 · Five approval rules

The table alone would be easy to game. Five rules hold it in place:

1. The change sets the tier. A classifier reads the change and picks it, whoever the author is.
2. Only trusted authors get the lighter paths. Mostly the team that owns the repo. Everyone else needs a second person.
3. An agent’s approval never counts as a person’s. Automated review can clear a low-risk change, but it can’t fill a human slot.
4. Whoever prompted the change is on the hook. On an agent-written PR, the person directing the agent is one of the required reviewers. It’s as if they had typed the code.
5. An approval covers one specific commit. If an agent pushes again or someone resolves a merge by hand, the approval has to be given again.

Rules three to five close loopholes that agents make wider. A bot can’t vote for a bot. A person can’t hide behind “the agent wrote it”. An agent can’t slip new code under an old approval.

04 · When the agent reviews the agent: rounds have to converge

The approval rules govern people. Agents reviewing agents needed rules of their own. “Noise costs more when the author is an agent,” the playbook says. A person waves off a nit in seconds. An agent fixes it: another commit, another review round.

One 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. The reviewer was rarely finding new bugs; it found a few more old ones each round. The team admits it made this worse by running several rounds by default.

They now track rounds-to-pass next to recall and made four changes:

• A round cap. After three rounds the reviewer asks the author to step back and reconsider the approach.
• Diff-only re-review after the first few passes.
• Flag the class of bug, so the author fixes every instance in one go.
• No repeats of findings already posted.

Source: Claude Code team, internal pull requests before and after the convergence changes, Anthropic, October 2026.

The round cap is the cheapest rule in the playbook. It stops the loop at round three instead of letting it run all night.

05 · The reviewer learns from incidents

A capped loop still needs a reviewer that finds the right bugs. The team collected past PRs that caused incidents, with their reverts and fix-forwards, and had engineers who know that code confirm each bug. The reviewer runs against this set daily, and a change to its prompts, tools or model is kept only if the score goes up. This is the same discipline as evals for agents, applied to a reviewer.

Recall is easy to inflate by flagging everything, so noise gets its own measure. Every comment is sorted by what the person on the PR did with it. They fixed it, called it wrong, called the behaviour intentional, or decided it didn’t matter. The reviewer also runs on PRs known to be clean, counting how often it would have pushed someone into a harmful change. The written priority: real bugs first, fewer rounds second.

06 · Where people stay

All of this frees people for decisions machines are bad at. The playbook names five:

• Should we build this at all? Direction, taste and scope.
• Risky code: billing, the auto-updater, CI workflows.
• Architecture that sets a pattern others will copy.
• Reading the evidence. If you can’t say what the checks would miss, ask for a real review.
• Owning the outcome. A person is accountable for every change that ships, whoever typed it.

The team norm is “you land it, you own it”. It works because changes are small and flags and reverts undo most mistakes in minutes.

Outside data says the old proxy is weak. “Habituation at the Gate” tracked 11,429 reviews of AI-agent pull requests by 400 repeat reviewers over seven months: the approval rate rose from 30.1% to 36.8%, inline comments fell by 22%. The authors call it “reflexive habituation under growing workload”. A tired human click is a weak check.

07 · What transfers to a 10-person team

Anthropic’s setup assumes volume no small team has (its monorepo merges 30,000+ changes a day), engineers who use the product all day, and its own reviewer. A 10-person team has none of that. My read of what carries over:

Take now	Take after evidence	Doesn’t carry over yet
Agent shows test or build output in the PR	Risk tiers as path rules in CODEOWNERS; a classifier later	Two classifiers setting the tier: you can’t check their accuracy at your volume, and Anthropic doesn’t publish theirs
Short CLAUDE.md or AGENTS.md, plus REVIEW.md	Zero-human merges for docs and copy, once rollback is one step and you have a revert baseline	Employees as first users: it works because Anthropic’s engineers live in Claude Code
One AI reviewer, every finding answered	An incident eval set: start the file now, it fills slowly	”Nobody needs the full mental model”: in a small team, review is still how people learn the code
Round cap of three, diff-only re-review	Noise measured by what authors do with comments	Nightly review agents over the whole codebase: cost not disclosed
Bot approval never counts; approvals reset on new commits	A merge queue, once green PRs start breaking main together

Most of the left column is a settings page. On GitHub, Copilot’s review is a “Comment” by default and doesn’t count toward required approvals. Since September 1, 2026 an admin can let it approve, and that approval counts (public preview). Under Anthropic’s rule three, that switch stays off. Branch protection already has “Dismiss stale pull request approvals when new commits are pushed”, which is rule five as a checkbox.

Path rules start small:

# CODEOWNERS
/billing/            @acme/payments
/.github/workflows/  @acme/platform
/install/            @acme/platform

One caveat: GitHub accepts an approval from any one code owner, so CODEOWNERS alone can’t build the “two people” tier. That tier needs its own rule, such as a CI check that counts approvals on those paths.

My own team is smaller. I build AgenticCRM with a team of six engineers. Coding agents work under repository rules and release gates, every PR gets a preview environment, and the suite has around 800 unit tests. New tests go in only with a person’s approval, through a CI step called the test budget. That is a small-team version of layer one: if an agent can write its own tests, a person decides what counts as passing.

08 · A four-week checklist

Based on the adoption section of the Claude Code team’s playbook, Anthropic, October 2026; split into weeks by the author.

Week 1. Before the PR

• The agent pastes test or build output into the PR.
• A short CLAUDE.md or AGENTS.md, plus formatter and linter hooks.
• PR template: “Testing”, “Risk”, “How to revert”.

Week 2. On every PR

• One AI reviewer on one repository, plus REVIEW.md.
• Every finding fixed or closed with a reason before merge.
• Round cap of three, then diff-only re-review.

Week 3. Approval

• CODEOWNERS: auth, billing, CI and release workflows, installers always need a person.
• Bot approvals don’t count; stale approvals are dismissed on new commits.
• Risk tiers written down, set by the change. Start strict.

Week 4. Measure and roll back

• Baseline: approvals per PR, wait time, revert rate, incidents.
• Rollback drill: turn a flag off or revert and redeploy in one step, and time it. Aim for minutes.
• Start the incident file for the reviewer’s eval set. Loosen one tier only after reverts stay flat.

09 · What we don’t know

The playbook names one gap itself. Noticing a bad merge still depends on the author, on-call and dashboards. “We don’t yet have circuit breakers that tighten approval when those numbers move,” the authors write. Their engineers want them before more code moves to zero-human merges. A team that copies the zero-human tier copies it without that safety net.

Other limits:

• The numbers are internal. No absolute PR counts, no baseline revert rate, no outside check. A lot changed between June and September, so the 40% drop can’t be credited to one layer.
• Key parameters are missing. Classifier accuracy, the size of the trusted list and the compute cost of deep reviews aren’t published.
• The vendor’s interest. Code Review for Claude Code is a paid product on Team and Enterprise plans. The product posts findings and leaves approval to people. Merging on automated checks alone is how Anthropic runs its own repos.
• Outside evidence is thin. The habituation study is a single preprint.

Where is your line: which changes would you let merge with no human approval at all?

FAQ

How does Anthropic review code written by Claude? Every change passes seven layers: verification before the PR, AI review, blocking security review, CI, human approval by risk, a merge queue with flags and staged release, and fast rollback. Machines do most of the reading.

Does any code at Anthropic merge without a human approval? Yes, in the Claude Code repositories: docs, copy, internal-only features and additive changes behind a flag, once automated reviews are green and only from trusted authors. Product changes need one person, the highest-risk code two.

Does an AI reviewer’s approval count as a human approval? Not at Anthropic: an agent’s approval never counts as a person’s. On GitHub, Copilot can be allowed to approve since September 2026; the setting is off by default.

How do you stop an AI reviewer and a coding agent from looping forever? Cap the rounds at three, re-review only the new diff, flag whole classes of bugs and never repeat a finding. After these four changes, one-round passes rose from 65% to 78%.

What can a small team copy from Anthropic’s code review process? Test output in every PR, a short instruction file and REVIEW.md, one AI reviewer whose findings must all be answered, a round cap, and branch protection where a bot never replaces a human. Zero-human merges wait for one-step rollback and a revert baseline.