Claude Code team code review: who stops AI-written code?

Claude writes about 90% of Claude Code’s own code. That is more than people can read line by line. On October 15, the Claude Code team published its review process on the claude.dev blog: who checks the code, where, and who notices when something breaks. On the same day, “Code Review for Claude Code,” which reviews PRs automatically, became generally available.

The goal and how it is measured#

According to the blog, changes landing in Anthropic’s internal monorepo (one large repository that holds many projects) grew from about 2,500 a day in May to more than 30,000 a day in September. Claude Code lives in a separate repository, but there too the volume of changes has become a review burden.

The team’s goal is to land most PRs in the Claude Code repository (CLI, desktop and web, mobile) with at most 1 person involved. That person can be the PR’s author. Human time is measured by approvals per PR (median and 95th percentile), the number of human comments, and how long PRs waited on a person. Revert and incident rates are guardrail metrics that must not go up. If review time drops but time spent fixing broken things rises, the time has only moved.

The blog says merged PRs more than doubled from June to September, and the share of PRs that were reverted fell by more than 40%. As SecondSource points out, though, these are Anthropic’s own numbers with no outside audit. Neither the revert counts nor the baseline values have been published.

The 7 layers a change passes through#

The blog splits the checks a change goes through before it reaches users into 7 layers.

Layer	What it does	Blocks the merge?
1. Pre-PR verification	Claude runs tests, builds, and lint, and shows the results. A separate agent reads the diff in a fresh context	n/a
2. AI review	Several agents hunt for bugs in parallel, and another group of agents votes on each finding	Yes, while findings are unresolved
3. Security	Runs automatically, separate from the bug review	Yes, while findings are unresolved
4. Required CI	Lint, types, tests on every platform, build and packaging	Yes, on failure
5. Human approval	A classifier picks how many approvals are needed: 0, 1, or 2	Yes, until there are enough approvals
6. Merge queue	Applies the change to the latest main and reruns the checks. New behavior ships behind a flag, and employees use it first	Yes, if the rerun fails
7. Rollback	The author and the on-call engineer watch, then turn off the flag or revert the broken build	n/a

In the first layer, the team hands Claude things it can run, such as tests and screenshots, and asks it to show the output instead of saying “done.” Boris Cherny, who created Claude Code, estimates that giving Claude a way to verify its own work makes the final result 2 to 3 times better.

In AI review (the second layer), a finding is posted only if enough agents vote that it is a real bug. Findings that are only about style, diagnostics, or tidying are out of scope. Each surviving finding is labeled Important, Nit (minor), or Pre-existing (a bug that was already there). Pre-existing gets its own label so that a bug the PR did not introduce is not pinned on the author. Every finding must get an answer: either fix it, or close the thread with a reason.

When the same finding keeps coming up, the team fixes the source instead of fixing it in review again and again. They add to a skill, a lint rule, CLAUDE.md (which describes the project), or REVIEW.md (where code owners write what reviews should look for).

The number of approvals depends on the change#

Approval in the fifth layer has 3 tiers.

Risk	Examples	Human approval
Low	Docs, copy, internal features, changes that only add something behind a flag	None, if automated review and security checks pass
Medium	Normal product changes, sensitive areas such as caching, auto-update, and the system prompt	1 person
High	The riskiest code, and a small set of paths that always need 2 people	2 people

A classifier reads the change and picks the tier. Another classifier decides whether this particular change needs one more person even if its tier does not require it. Paths that owners have registered as sensitive, and CI workflow files, always need human approval.

Approval has other conditions too.

• Only trusted authors in the repository (mainly the team itself) can use the lighter tiers. Anyone else needs a second approval
• An agent’s approval does not count as a human approval
• On a PR written by an agent, the person who directed the agent counts as one of the required reviewers
• An approval applies to a specific commit. If a commit the checks cannot vouch for comes in, such as an agent’s push or a merge where a person resolved conflicts by hand, the PR needs approval again

When AI review never ends#

When agents both write and review the code, the exchange can go on forever. One Claude Code CLI PR went through more than 50 rounds of review and fixes in a single night, and kept going until the author stopped it. Agents dutifully fix minor findings that a person would wave off in seconds, and each fix adds one more commit and one more review.

When the team ran git blame on findings that kept coming back, about 59% pointed at code that had been there since the first review. The blog reads this as the review finding almost no new bugs, and instead picking up a few old ones each time. So the team added 4 changes.

• After 3 rounds, the reviewer asks the author to rethink the approach itself
• After the first few rounds, only the new diff is reviewed
• Findings name the class of bug instead of a single line, so the author can fix every instance of that class at once
• Findings that have already been posted are not repeated

On internal PRs, the share that passed in one round rose from 65% to 78%, and the share that took 5 or more rounds fell from 8.9% to 1.5%. The average number of reviews before a PR passed went from 2.08 to 1.32.

Noise in the findings is measured too. Every finding is sorted by whether the author fixed it, said it was wrong, said the behavior was intended, or ignored it. The team also runs reviews on PRs known to be fine and counts how many findings would lead to a wrong fix. PRs that caused incidents or reverts in the past go into an evaluation set, and review performance is scored against it every day.

The decisions left to people#

What the blog leaves to people are the judgments machines are bad at. People decide whether something should be built at all (direction, taste, scope), risky code such as billing, auto-update, and CI workflows, and design patterns that others will copy. Reading evidence such as test output, screenshots, and review findings, and owning the results of a shipped change, are also listed as human work. Approvers who cannot say what the checks might miss are asked not to approve right away, and to request a full review instead.

The blog also lists what is still missing. There is no mechanism yet that automatically tightens approvals when the revert or incident numbers move. Some on the team want that mechanism before expanding merges without human approval.

I collected figures from outside papers and surveys on how the load on reviewers grows as AI writes more code in a post on understanding debt.

How much of this you can do with the public Code Review#

The public Code Review is available on Team and Enterprise plans for GitHub repositories. It is not available to organizations that have zero data retention (ZDR) or a HIPAA configuration enabled, or to organizations that use customer-managed encryption keys (CMEK). Its flow matches the blog’s second layer: multiple agents search, a verification step removes false positives, and findings are posted in order of severity. Review depth can be set to Quick, Standard (the default), or Deep, per organization and per repository.

Pricing is not a flat fee per review. Token usage is drawn from usage credits, separate from the usage included in your plan (see the costs and usage page). When the research preview launched, the official blog put the average at $15 to $25 per review. With the default setting, “review on every push,” cost grows with every push.

The biggest difference from the blog’s process is whether merges get blocked. The documentation states that reviews neither approve nor block a PR, and that the check run never ends in failure. The check run’s result is neutral, or skipped when there were no changes. If you want to block merges on unresolved findings the way Anthropic’s internal repositories do, you have to build it yourself.

• Use GitHub’s branch protection setting “Require conversation resolution before merging.” Findings are posted as line comments on the PR, so the PR cannot merge until they are resolved. However, it also applies to human comments and to threads on minor findings. Findings that GitHub would not accept as line comments appear only as annotations in Files changed and in the check run details, so this setting does not catch them
• Read the line at the end of the check run details that counts findings by severity. If normal (the count of Important findings) is 1 or more, fail the job. When that line is missing, the documentation asks you to treat it as “no verdict,” not as zero findings

For the blog’s “an approval applies to a specific commit,” the closest setting is the same branch protection’s “Dismiss stale pull request approvals when new commits are pushed.”

REVIEW.md is read from the target branch or the default branch, and changes inside the PR are not used. You cannot make a PR’s review more lenient by editing REVIEW.md in that PR. However, instructions that lower severity, exclude paths, or cap the number of minor findings only take effect when the default branch is protected, or when the PR targets another branch that a ruleset protects (see the customization page).

Because the public Code Review does not approve anything, you have to supply the part that changes the number of approvals by risk tier yourself. The blog’s section on adopting the approach recommends writing out the tiers, starting strict, and loosening only once there is evidence. It also asks you to protect the parts that must always go through a person (auth and billing, CI and release workflows, installers) with CODEOWNERS and branch protection, and not to let a bot’s approval stand in for a required human approval.

Even without Team or Enterprise, some of this works locally. The /code-review command runs on any plan, and a subagent in a separate context reviews the diff on your branch (see local review). The cost is included in your session usage (for how to read usage, see “Cutting Claude Code costs: watch /usage, tune effort levels”). It reads CLAUDE.md but not REVIEW.md, so instructions you want applied in both places probably need to go in CLAUDE.md.

The numbers on results come only from the company’s own announcement, so you will probably need to set your own goal and guardrail metrics and measure them in your own repository.