Claude Code's Six-Layer Code Review System Explained: REVIEW.md and AI Review Practices

Anthropic's engineering team is rewriting the collaborative workflow of software development in a radical way. According to a Bilibili creator's analysis synthesizing multiple sources, Claude Code can now write roughly 90% of its own code, the number of merged PRs has more than doubled within a few months, while the proportion of rolled-back or reworked code has actually dropped by 40%. Between "exploding code output" and "no drop in quality," what they rely on is not harder manual review, but an automated review system composed of six layers of checks, along with one key file: REVIEW.md.

This article breaks down the design logic of this system and offers practical recommendations that ordinary teams can adopt immediately.

Why code review must be redesigned

Anthropic's official blog disclosed a number: the daily volume of changes landing in its monorepo has grown from about 2,500 to over 30,000. At this scale, line-by-line human review has become "extremely difficult, if not impossible." In the video, the creator specifically emphasized that this is a common pain point he heard after visiting multiple companies—running 100 agents is not hard; what's hard is how to review and merge code once a massive volume floods in.

Anthropic's approach is to return to first principles and redefine the purpose of review: first, to catch problems before launch; second, to help the team understand the codebase. They replaced a habitual question—"has someone reviewed this code?"—with "what could go wrong with this code, and which kind of check should catch it?" The position of review has also changed—from a one-time gate before merging to a "review while writing" process that runs continuously starting from the first prompt.

Their goal is clear: most PRs should require at most one human involved, and that human can be the author themselves. This breaks the traditional assumption that "review must be done by a second pair of eyes."

Six layers of checks: from validation to the merge queue

This system can be summarized as "six layers of checks + an underlying rollback capability." The core idea is to let agents work freely within bounded scope, and if something goes wrong, roll it back before it affects customers.

Layer 1: Self-validation before humans see it

Most review actually happens before a PR is created. Claude must run tests, build, take screenshots, and perform end-to-end testing, proving with output that "it's actually done" rather than merely claiming completion. A sub-agent then reviews the diff with a fresh context window. Boris Cherny, the creator of Claude Code, estimates that this validation step alone can make the final result two to three times better.

When the same issue keeps recurring, the team chooses to fix it at the source: claude.md or agents.md describes the project's tech stack, conventions, and goals, while CODEOWNERS writes REVIEW.md, telling reviewers what really matters in this code. The creator specifically noted that this step also suppresses "nitpicky" false positives—including comments on historical code outside the current change, noise that is very common in production workflows.

CODEOWNERS is a configuration file supported by code hosting platforms such as GitHub (usually located in the repository root or under .github/), which maps paths in the repository to specific teams or individuals using glob patterns. When a PR modifies a certain path, the platform automatically adds the corresponding owner as a required reviewer, thereby institutionally ensuring that "the people who understand this code will definitely be pulled in." In Anthropic's practice, CODEOWNERS also carries another responsibility: it is not only the declaration of approvers, but also the author and maintainer of REVIEW.md—because only those who truly own the context of that module know which constraints, boundary conditions, and historical baggage are worth writing into the review checklist. This binding of "ownership equals ownership of review knowledge" prevents REVIEW.md from becoming an unmaintained, one-size-fits-all empty document.

Layer 2: AI review on every PR

AI review reads through the diff's relationship to the entire repository, as well as the stated intent of the PR. Multiple agents search for bugs in parallel, and then another group of agents votes on each finding; only issues endorsed by enough agents are published. This is exactly the public version of the Claude Code Review product, which the company says is about 3 times faster, dropping from roughly 20 minutes to 6 to 10 minutes.

"Multiple agents searching for bugs in parallel, then another group voting" is an ensemble review approach, whose value lies in suppressing the random hallucinations of a single model. A single LLM reviewer tends to be oversensitive to certain patterns and systematically blind to others; by having multiple agents with independent contexts scan separately and then filtering with a voting threshold, one can distinguish between "one model thinks there's a problem" and "this problem reliably reproduces." The voting mechanism is also a cheap form of confidence calibration: it requires neither training a reward model nor human labeling, and reduces false positives purely through consistency. The cost is that inference cost rises linearly with the number of agents, so such approaches are usually fully enabled only for high-risk paths or large diffs, while ordinary changes go through a single-agent channel.

Layer 3: Independent security review

In Anthropic's own repository, as long as there are unresolved findings in either bug review or security review, the PR cannot be merged. This is a hard gate.

Layer 4: Boring but essential checks

Lint, type checking, multi-platform testing, build testing, and the mandatory "how to test" and "how to roll back" fields in the PR template.

Layer 5: Risk-tiered approval

Low-risk changes (docs, copy, incremental changes behind flags) require no human approval after automated checks pass; ordinary product changes require one person; high-risk code requires two. There are five rules worth remembering here: the change itself, not the author, determines the risk level; only trusted authors go through the lightweight channel; an agent's approval can never substitute for a human slot; the person who initiated the prompt is responsible for the PR written by the agent; and one approval covers only one specific commit. The creator pointed out that this is consistent with Adi Osmani's views on blast radius and approval tiers.

Layer 6: Merge queue and staged rollout of new behavior

The merge queue reruns all checks against the main branch, preventing two PRs that each pass individually from breaking each other when combined. New behavior is first opened to internal teams behind a flag, then enters the latest channel at a scale of about a thousand people, and finally reaches stable.

Merge queue solves the classic problem of "semantic conflicts": two PRs each pass tests based on an old main branch, but when merged, their combined changes may fail to compile or be logically incompatible. The merge queue approach groups the PRs to be merged into a temporary batch and reruns all CI on the actual merged result; only when the entire batch passes does it actually land. If one PR in the batch fails, it is removed and the remaining part is retried. It changes the definition of "passing checks" from "passing relative to my baseline" to "passing relative to the state that will become the main branch," and is key infrastructure for keeping the main branch green in high-frequency merge scenarios. When daily merge volume reaches tens of thousands, the scheduling strategy of the merge queue itself also becomes a throughput bottleneck.

The trap exposed by 50 rounds of AI review

The creator shared a highly instructive case: a PR for the Claude Code CLI went through more than 50 rounds of AI review and fixes overnight, until the author personally called a halt. Root-cause analysis using git blame found that about 59% of the repeatedly flagged issues actually came from old code that existed in the first round—the reviewer was not discovering new bugs, but digging up a few more old problems each round.

This is a typical trap of the agent era: a human can ignore a nitpick in seconds, but an proactive agent will go "fix" it, generating new commits, new reviews, and new rounds, falling into a loop. Anthropic's fix is: after three rounds, require the author to stop and rethink the approach; in subsequent rounds, only re-review the new diff; report issues by "category" rather than "individual line"; and never repeat already-reported findings.

Blast radius is a common concept in software release and SRE, referring to the scope of users, services, and data that may be affected when a change fails. It determines how much review and validation cost a team should invest in a change: changing an internal document or a gray-release feature behind a flag has a blast radius close to zero and can be fully automated; while changing authentication, billing, or data migration paths may affect all users if it fails and is hard to roll back, so multiple layers of human oversight are required. Tying approval thresholds to blast radius rather than author seniority essentially aligns control intensity with real risk—this also explains why Anthropic allows zero human approval for low-risk changes but sets an unavoidable hard gate on security review.

Five things ordinary teams can copy directly

According to cross-verification between the creator and Anthropic's official blog, even if you don't have massive inference resources, you can immediately implement the following practices:

1. Give agents checks they can run themselves, so they can prove completion with output.
2. Add a REVIEW.md, and let the AI reviewer tune on one repository for a few weeks first.
3. Set approval thresholds by the risk level of the change, not by author identity.
4. Never allow an agent's approval to replace human approval.
5. Make rollback rate and incident rate core metrics, not just merge speed.

In addition, Anthropic also revealed that they replaced Git on the monorepo with their in-house system Cyan (the main branch history is nearly 100GB, and CI checks out 25 million times a day). A team of 7 completed the migration in about 5 months, and the size is about 200 times smaller than the old solution. This approach has not yet been externally validated, but it reveals that once code output increases by an order of magnitude, the infrastructure itself also becomes a bottleneck.

Also noteworthy is the gap Anthropic openly acknowledges: they do not yet have a "circuit breaker," that is, a mechanism to automatically slow down when the rollback rate rises abnormally. They prefer to detect and fix problems faster rather than reduce total volume. Whether this tradeoff suits your team depends on how large your blast radius is.

For developers, the role is shifting from "the person who writes code" to "the person who designs and maintains a continuously running software factory." REVIEW.md is just a tiny component in this factory, but it marks a shift: review knowledge itself also needs to be engineered and explicitly written down.