The code-review bottleneck just broke #
Code review, a traditional bottleneck in software development, is experiencing a tectonic shift. Anthropic's main monorepo, for instance, scaled from approximately 2,500 daily changes in May to over 30,000 on its busiest day in September. Concurrently, Claude now writes around 90% of Claude Code’s own code, rendering line-by-line human inspection impractical.
Instead of aiming for human review of every line, Anthropic’s teams now ask: "What could go wrong with this change?" and "What check—automated or human—is best to catch it?" This pragmatic approach ensures most pull requests (PRs) merge with at most one human involved, often just the author. Boris Cherny Cherny, who created Claude Code, ships 20-30 PRs daily, a pace impossible with conventional methods.
This new system has yielded remarkable results. Between June and September, merged PRs more than doubled. Critically, the share of PRs that had to be reverted dropped by 40%, demonstrating that a lower human review burden does not necessarily equate to more defects. This shift highlights a fundamental re-evaluation of how we ensure code quality at scale.
A bug has to survive a gauntlet #
Bugs face a gauntlet of automated checks designed to catch issues before human eyes even see a pull request. Claude first runs tests, builds the application, or compares screenshots within the author’s session to self-verify its work. Then, a sub-agent with a fresh context independently reviews the diff, ensuring no bias from the authoring session contaminates the initial assessment.
Once a pull request is created, a dedicated Claude reviewer product takes over, deploying multiple agents to search for bugs simultaneously. A separate group of agents then votes on these findings, and only if enough agree does a comment get posted, significantly reducing false positives.
System learns from its mistakes, transforming recurring issues into lint rules or specific guidance in CLAUDE.md files. This ensures that common errors are addressed upstream, preventing their reintroduction. Conversely, if the reviewer repeatedly flags acceptable code, review.md files, written by code owners, clarify what constitutes a failure in that specific code area.
Before merging, a separate security review agent scrutinizes the code for vulnerabilities, and standard CI checks—including tests, type checking, and linting—must pass. This layered "Swiss cheese" model ensures that even if one defense has a "hole," subsequent layers are likely to catch the defect, allowing Anthropic to scale merges without sacrificing stability.
The reviewer needs a reviewer, too #
Human review remains a critical, albeit tiered, safeguard. Low-risk changes from trusted authors, like documentation updates or feature-flagged work, often bypass human approval. Ordinary changes or modifications to sensitive areas demand one human sign-off, while high-risk paths require two. Anthropic’s classifier agents determine these tiers, with a second agent validating the human-review requirement.
Evaluation focuses on real-world impact. Bugs linked to incidents convert into daily test cases for the reviewer, ensuring the system learns from past failures. Only prompt, model, or rule changes that demonstrably improve performance without generating excess noise are retained. This iterative feedback loop constantly refines the automated review process. For more details on this intricate system, see How the Claude Code team does code review.
However, agent-to-agent reviews can trap the system in a loop. Excessive nitpicks trigger repeated edits and subsequent reviews, as one PR logged over 50 rounds. To combat this, Anthropic capped review rounds and shifted later reviews to focus solely on new changes. This intervention saw PRs passing after one round jump from 65% to 78%, while those needing five or more rounds plummeted from 9% to 1.5%.
Enjoying this? Get one like it in your inbox each morning.
one email a day · unsubscribe in two clicks · no third-party tracking
What teams can copy—and what they can’t #
Anthropic’s dramatic scaling offers a glimpse into AI-native engineering, but not every team can simply copy-paste their approach. While merged PRs more than doubled and revert share dropped by 40%, the published metrics don't definitively prove fewer total changes broke. If the volume of changes increased enough, the absolute number of reverts could still have risen, even with a lower percentage.
Replicating Anthropic’s multi-agent review system demands significant resources and highly specialized internal tooling. Most organizations lack the token budget, compute capacity, or the sophisticated feedback loops that allow Claude to self-improve its review capabilities. This isn't a quick integration; it's a fundamental architectural shift.
Nevertheless, pragmatic takeaways exist for any team. Guide agents with concise instructions, and automate checks for recurring errors rather than fixing them iteratively. Cap review loops—Anthropic learned the hard way that agents can get stuck in over 50 rounds. Reserve human attention for truly consequential decisions, like architectural choices or high-risk billing code. Ultimately, the "you land it, you own it" rule remains paramount: accountability for outcomes still rests with humans.
Frequently Asked Questions #
Does Anthropic have humans review every Claude Code change?
No. Human review depends on risk: some trusted, low-risk changes can merge without human approval, while sensitive or high-risk changes require one or two people.
How does Anthropic review AI-generated code?
Its process combines local tests, fresh-context agent review, multi-agent bug and security checks, CI, risk-based human review, and production monitoring.
Did Anthropic’s revert rate prove that fewer bugs reached production?
Not by itself. The share of merged PRs that were reverted fell 40%, but merged PR volume more than doubled, and Anthropic did not publish the underlying counts.
What can smaller engineering teams copy from Anthropic?
Use automated checks for repeatable risks, keep agent instructions focused, limit review rounds, match human review to risk, and make the person landing a change own its outcome.