Claude Code Team's Seven-Layer Review: AI Writes the Code, What Do Humans Handle?

Anthropic's developer blog recently revealed how the Claude Code team tackles the review challenges brought by AI-generated code. The core shift: when 90% of the code is written by Claude, traditional line-by-line human review is no longer feasible. The team broke review down into a seven-layer defense combining automation and human judgment, reserving human attention for the hard problems that genuinely require it.

Review Volume Doubles, Rollback Rate Drops 40%

From June to September, the number of PRs merged into the Claude Code codebase more than doubled, yet the proportion requiring rollback fell by over 40%. These figures come from Anthropic's official developer blog, where Eddie Osmani and two co-authors broke down the mechanisms behind them.

The broader context: changes landing in Anthropic's main codebase grew from roughly 2,500 per day in May to over 30,000 per day in September. The article states plainly: line-by-line human review on the main branch is simply no longer possible. The team didn't abolish review—it redefined its goal. Not "has someone read this code," but "what could go wrong with this change, and which check is best positioned to catch it."

Review shifted from a gate at the end to a spell-checker running continuously while code is written. Most changes have already been reviewed and fixed at least once by Claude before a human ever looks. The team's goal is for most PRs to require at most one person—who may be the author themselves—while rollbacks and incidents don't increase.

Seven Layers: What Each Catches and What It Misses

A change travels from an engineer's machine through seven layers of review. Each layer catches some problems and misses others; few changes make it through all of them, and the rest fall to rollback.

Layer 1: Before the PR Exists, Let Claude Prove Itself

The team gives Claude a runnable means of verification—tests, a build, or screenshots compared against design mockups—and requires it to produce the results. A sub-agent then reviews the diff in a fresh context. Boris Cherney, creator of Claude Code, estimates this makes the final result two to three times better. Issues repeatedly flagged by automated review get fixed at the source by revising Skills, adding lint rules, or writing them into CLAUDE.md and REVIEW.md.

Layer 2: Every PR Goes Through Claude Review First

Before a human sees it, a PR goes through a Claude review that reads the diff against the entire repository and the PR's intent. When this capability's research preview launched, the share of internal PRs receiving substantive review comments rose from 16% to 54%. Comments are verified before reaching humans: several agents hunt for bugs simultaneously, then another set of agents votes on each finding. Only those with enough votes are posted, ranked by severity and labeled Important, Nit, or Pre-Existing. Every comment must be addressed—either fixed or closed with a written justification.

CLAUDE.md and REVIEW.md are project-level instruction files that Claude Code reads. CLAUDE.md lives in the repository and tells Claude how the project builds, its test commands, code style, and prohibitions; REVIEW.md specifically encodes review preferences—which patterns must be blocked, how comments are graded. Both are versioned alongside the code. Whenever the team finds automated review repeatedly missing or falsely flagging something, they add the rule, effectively distilling human experience into reusable review context.

Layers 3 and 4: Security Review and Automated Checks

Layer 3 is security review—if any comments remain unresolved, the PR cannot merge. Layer 4 is lint, type checking, and per-platform tests and build checks. An ordinary command-line PR may have run dozens of checks before anyone looks at it.

Lint and type checking are static analysis: lint scans for style issues and common defect patterns without running the code, while type checking verifies consistency of types across variables and function signatures. They catch entire classes of low-level errors in seconds, at far lower cost than human reading. Build checks verify the code compiles and packages successfully on each target platform, and cross-platform tests execute test cases across multiple operating systems and runtime environments, preventing "works on my machine" issues from reaching the main branch. All automated and repeatable, these are the cheapest and most stable layer of the seven.

Layer 5: Human Approval Tiered by Risk

Docs, copy, and new changes behind a feature flag are low risk—no human approval needed once automated checks pass. Ordinary product changes, plus sensitive areas like caching, auto-update, and system prompts, need one person. The highest-risk code needs two. The tier is determined by the change itself, not by who the author is, and is decided by a classifier. Agent approval can never substitute for human approval. For PRs written by an agent, the person who issued the instruction counts as one of the required reviewers. Approval applies to one specific commit; if new commits appear that the system cannot vouch for, re-approval is required.

Feature flags are a mechanism for controlling whether a feature is visible to users without large-scale code changes. New code can be merged and deployed but stays inactive while the flag is off, then gradually enabled once verified. This decouples "merge" from "launch" and keeps the blast radius of high-risk changes bounded. Combined with a merge queue—lining up pending PRs and re-running checks on the latest main branch one by one before merging—it prevents the situation where multiple PRs each pass checks but conflict once combined.

Layers 6 and 7: Merge Queue and Fast Rollback

Checks run once more on the latest main branch before merging; new features go first to Anthropic employees, then roll out gradually. The final layer is the fast-rollback switch, which shuts down an incident without a deployment. Postmortems ask: which layer should have caught this?

The Reviewer Itself Improves: From 65% to 78%

The team turned PRs that previously caused incidents into an eval set, run daily by the reviewer. Each time prompts, tools, or models change, the new version is kept only if the score improves.

When the author is an agent, noise costs more—a human skips a minor comment in seconds, while an agent will go fix it, adding another review round. Review must also converge. One command-line PR was reviewed back and forth over 50 rounds in a single night until the author called a stop. A Git Blame check showed about 59% of what the reviewer kept flagging was code that already existed in the first round; it rarely found new bugs, just surfaced a few more old ones each round. The team changed the rules: after at most three rounds, ask the author to reconsider the approach; in later rounds, review only the new diff; when flagging a class of bug, have the author fix all instances at once; and don't repeat comments already posted.

After the changes, internal PRs passing in a single round rose from 65% to 78%, and those needing five or more rounds fell from 8.9% to 1.5%.

Git Blame shows, line by line, which commit and which change last introduced a piece of code. The team used it to determine whether a review comment really targets the current diff: if the flagged line comes from an old commit, it's a legacy issue rather than a newly introduced bug. This revealed the phenomenon of reviewers rehashing old code and creating wasted rounds, and became the data basis for the later rules of "review only the new diff" and "fix a class of issues in one pass."

Where Human Work Shifts

Human work moves from reading every diff to the decisions machines are bad at: whether this thing should be built at all; the architecture for high-risk code like billing, auto-update, and CI that will be written under someone else's protection; reading evidence like test output and screenshots; and being accountable for the result. Every change that ships has one person accountable for it.

With machines reading most of the code, how do humans understand the codebase? No one on the team holds a complete model of Claude Code in their head. When they need to understand an area, they ask Claude to write an explanation of it—a few minutes, and the content matches the current code. The team's norms: whoever merges owns it, changes stay small, everything is revertible, and the larger the blast radius, the more checks. Regressions surface quickly, and postmortems examine the system, not individuals. Agents make starting something cheap, so closing a PR headed the wrong way costs little—the key is raising it in discussion early.

A Checklist for Teams

The article closes with a directly usable checklist: give the agent runnable checks; write good CLAUDE.md and REVIEW.md; put every PR through CI, AI review, and security review; match review depth to risk; cap review rounds; write down risk tiers; start strict; use merge queues, feature flags, and one-step rollback; turn incidents into eval sets.

Worth noting: the Code Review product only posts comments, not approvals—approving a PR remains a human decision. The team's own repository goes further, allowing low-risk changes to merge on automated checks alone. The goal never changed: less human time per change, and no more rollbacks than before.

One-line Summary

Claude Code team uses a seven-layer review defense for AI-generated code—PRs double while rollback rate drops 40%.

Paragraph Summary

Anthropic's developer blog reveals that 90% of Claude Code's code is written by Claude, making line-by-line human review infeasible. The team split review into seven layers: before a PR exists, Claude proves itself with runnable evidence like tests and builds, and a sub-agent reviews the diff; every PR first gets Claude review verified by multi-agent voting; then security review, lint, and cross-platform test/build checks; human approval tiered by risk—low risk passes automatically, highest risk needs two people, and agent approval never substitutes for human; finally a merge queue and fast rollback. From June to September, PR volume doubled while rollback rate fell over 40%. After review rounds converged, single-round internal PRs rose from 65% to 78%. Human work shifted to whether to build, architecture judgment, reading evidence, and accountability.