How Anthropic Engineers Review AI-Written Code

The source and the numbers

The primary source is "How the Claude Code team does code review" by Addy Osmani, Morgan Westlee Lunt, and Qing Wang, published October 15, 2026 on Anthropic's claude.dev blog. The video behind this page reacts to that post section by section.

The post says Claude writes about 90 percent of Claude Code's own code. From June to September, merged pull requests more than doubled while the share that had to be reverted fell by more than 40 percent. In Anthropic's monorepo, changes landing per day rose from about 2,500 in May to more than 30,000 in September. Line-by-line human reading could not survive that volume, so the team stopped treating it as the safety mechanism.

Its own summary: review was not removed, most of the reading moved to machines, human time and attention were optimized for, and mistakes were made fast and easy to undo. This page focuses on that review system. For how Anthropic's teams use Claude Code day to day, see how Anthropic's own teams use Claude Code.

The seven layers

1. Verified before the PR. Claude runs tests, builds, or screenshot comparisons and shows the output. A subagent reviews the diff with fresh context. Recurring problems are fixed at the source through skills, lint rules, CLAUDE.md, or REVIEW.md.

2. AI review on every PR. Several agents hunt for bugs in parallel against the whole repository and the PR's stated intent. A separate group votes on each finding, and only survivors are posted, tagged Important, Nit, or Pre-existing. Every finding must be fixed or resolved with a reason.

3. Security review that can block. A separate automated pass. Open findings from either review block the merge.

4. Automated checks that block. Lint, types, tests on every platform, builds. The PR template asks how the change was tested and how to undo it.

5. Human approval scaled by risk. Low-risk changes such as docs, copy, and additive work behind a flag need no human once checks are green. Ordinary product changes and sensitive areas like caching or system prompts need one person. The highest-risk paths need two.

6. Merge queue, flags, gradual release. Checks rerun against main, new behavior ships to employees first, and public releases reach a latest channel before stable.

7. Detection and rollback. Flags turn off without a deploy, and incident reviews ask which layer should have caught the problem. The authors admit they do not yet have circuit breakers that tighten approval when reverts rise.

How the AI reviewer is kept honest

This is the part most teams skip. Anthropic collected past PRs that caused incidents or reverts, along with their fixes, and had engineers who know that code confirm each bug and where it lived. The reviewer runs against the whole set daily. Any change to its prompts, tools, or model is scored against every case, and kept only if the score goes up. Each new incident adds a case.

Noise is measured too. Comments are sorted by how authors responded: fixed, wrong, intentional, or did not matter. The reviewer is also run on known-clean PRs to count false alarms. The stated priority is catching real bugs first and cutting review rounds second.

Convergence needed its own work. One PR went through more than fifty review and fix rounds overnight. The fixes were a three-round cap after which the author reconsiders the approach, diff-only re-review after the first passes, flagging a bug class instead of one line, and never repeating a finding. The post reports PRs passing after one round rose from 65 to 78 percent. The same discipline applies to any agent evaluation: the set comes from real failures, not invented cases.

Where humans stay

The post keeps people on five things: deciding whether something should be built, reviewing risky code such as billing, the auto-updater, and CI workflows, reviewing architecture others will copy, reading the evidence the agent attached, and owning the outcome. A person is accountable for every change that ships, whoever typed it.

"You land it, you own it" makes that concrete. If a small or medium change breaks, the person who landed it usually fixes it. That works only because changes are small, reversible through flags and staged release, and surfaced quickly through telemetry. The post is explicit that this is not blame; incident reviews examine the system. Without reversibility, the same norm would be reckless.

What to copy, and in what order

Most teams cannot copy the whole stack at once, and should not. The order that pays back fastest, drawn from the post's own adoption list:

1. Give the agent runnable checks and list them in a short instruction file, kept short enough that the agent actually follows it.
2. Add a REVIEW.md and move every comment you have typed twice into it.
3. Add Testing, Risk, and How to revert to the PR template.
4. Put an AI reviewer on one repository, tune it for a few weeks, then widen.
5. Write risk tiers down, set by the change rather than the author, and use CODEOWNERS so auth, billing, CI, and release paths always need a person. Never let a bot approval replace a required human.
6. Turn your incidents and reverts into the reviewer's eval set.

The trade-off is explicit. Lighter human review for low-risk changes is safe only if rollback is fast. Teams without flags, staged release, and one-step revert should tighten approval, not loosen it.

One cost note. A multi-agent reviewer reads the repository, REVIEW.md, and past decisions on every PR, and repeats much of that work each round. Serving that reference material through retrieval rather than re-reading it is where token spend can drop; RDK reports 80 to 90 percent reduction on repeated or reference-heavy work.