Anthropic‘s Claude Code team describes how it reviews code when Claude itself writes about 90 percent of it. The post reports that from June to September, merged pull requests to the Claude Code codebase more than doubled while the share that had to be reverted fell by more than 40 percent. The team didn’t remove review; it moved most of the reading to machines and optimized for human time and attention.

The article reframes review: instead of asking “did a human read the code?”, ask what could go wrong and which check—automated or human—should catch it. Review now runs continuously rather than as a gate at the end. Most changes are reviewed and fixed by Claude at least once before a human looks. The team tracks human approvals per PR, human comments, and wait time, with revert and incident rates as guardrails.

The post walks through the layers a change passes through. First, work is verified before anyone else looks: Claude runs tests, builds, or screenshots and must show output; a subagent reviews the diff with fresh context; optional internal skills hunt for bugs, simplify the diff, and check end-to-end behavior. Second, every pull request gets an AI review before a person sees it, using the public Code Review for Claude Code product. When that research preview launched, the share of internal PRs getting substantive review comments went from 16% to 54%. Findings are verified by other agents, tagged Important, Nit, or Pre-existing, and every finding must be answered. Third, a separate security review can block merge. Fourth, standard lint, type checks, tests, and builds block. Fifth, human approval is scaled by risk: low-risk docs and internal-only features need no human approval once automated checks are green, ordinary product changes need one person, and high-risk code needs two. A classifier picks the risk tier, trusted authors get lighter paths, and an agent’s approval never counts as a human’s. Sixth, a merge queue re-runs every check against main, and new behavior ships behind flags to Anthropic employees first. Finally, fast detection and rollback catch what slips through, with on-call rotation and incident reviews that ask which layer should have caught the issue.

The team also works on making the reviewer itself better. Any incident becomes an eval: past incident-causing PRs, fixes, and reverts are collected, confirmed by engineers, and run against the reviewer daily. Noise is measured by watching how people respond to comments, because catching more bugs while flagging many non-bugs isn’t a win. Convergence is a real problem: one CLI PR went through more than fifty rounds of review and fixes overnight, and git blame showed about 59% of what the reviewer kept flagging was code that had existed since its first pass. Changes include a round cap after three rounds, diff-only re-review after the first few passes, flagging the class of bug rather than one line, and not repeating findings already posted.

Humans stay in the loop for decisions machines are bad at: whether to build something at all, risky code like billing, the auto-updater and CI workflows, architecture that sets patterns, reading evidence, and owning the outcome. Context sharing happens through Claude-generated explainers for specific slices of the codebase rather than reading trivial diffs, plus open Slack channels. The norm is “you land it, you own it,” supported by small changes, reversibility, staged releases, and incident reviews that look at the system rather than blame.

The article ends with adoption advice: put verifiable checks in a short CLAUDE.md, add a REVIEW.md, require CI and PR template fields for testing and revert steps, add an AI reviewer to one repo first, require review threads resolved, match review effort to risk, cap rounds, define risk tiers, keep lighter paths for trusted authors, use CODEOWNERS and branch protection, never let a bot approval replace a human one, use merge queues and flags, turn incidents into an eval set, and measure human time with revert and incident rates as the guardrail. The stated goal is unchanged: less human time per change, with no more reverts than before.