How the Claude Code team reviews agent-written code: risk tiers, a three-round cap, and the setup you can copy

Anthropic’s Claude Code team published its code review process on October 15, 2026. The context: Claude writes about 90% of Claude Code’s own code, and in Anthropic’s monorepo the number of changes landing per day went from about 2,500 in May to more than 30,000 in September. Line-by-line human review doesn’t scale to that.

The headline numbers: from June to September, merged pull requests to Claude Code more than doubled, while the share that had to be reverted fell by more than 40%. The question for builders is practical: if agents open most of your PRs, what should humans still review, and what can you set up today?

Layers, not one gate

The team describes a stack of checks, each catching what the others miss:

1. Verification before a PR exists. Claude gets something it can run (tests, a build, a screenshot to compare against a design) and has to show the output. A subagent then reviews the diff with fresh context.
2. AI review on every PR. Several agents look for bugs at once, and a separate group votes on each finding. Only findings enough of them agree on are posted. Style-only findings are dropped. Each comment is tagged Important, Nit or Pre-existing, and every finding must be fixed or resolved with a reason.
3. Security review that blocks. A PR can’t merge while any bug or security finding is open.
4. CI: lint, type checks, tests on every platform, and a build.
5. Human approval scaled by risk. Low-risk changes such as docs or flagged additive work need no human approval once checks are green. Ordinary changes and sensitive areas such as caching, the auto-updater or system prompts need one person. The highest-risk paths need two. A classifier sets the tier from the change, not the author. Only trusted authors get the lighter paths, and an agent’s approval never counts as a human’s.
6. Merge queue, flags, staged release, then fast rollback.

The fix for endless agent-vs-agent review

One CLI PR went through more than fifty overnight rounds of review and fixes. When the team ran git blame on what the reviewer kept flagging, about 59% was code that had been there since the first pass. The changes: a cap of three rounds (after that, the reviewer asks the author to rethink the approach), diff-only re-review after the first few passes, flagging the whole class of bug, and never repeating a posted finding. Past incidents and reverts also became a daily eval for the reviewer.

What you can turn on today

• Code Review for Claude Code is generally available on Team and Enterprise plans for GitHub repos. Per the docs, an org Owner picks a review level (Quick, Standard as the default, or Deep) and can set it per repo. Reviews post findings and a check run but never approve or block a PR.
• /code-review runs a lighter version locally in a Claude Code session, on any plan.
• REVIEW.md tells the reviewer what matters in your repo. Code Review reads it from the base or default branch, never from the PR’s own changes. The team’s advice: keep it short, cap nits, list paths to skip, and require a file and line as evidence.
• /security-review and the security review GitHub Action add automated security checks, per Anthropic’s support guide.

Pair this with a short CLAUDE.md and reusable Claude skills for the pre-PR checks. If you’re still choosing an agent, see our Claude Code vs Codex comparison and our note on Claude Code’s auto mode default.

Bottom line

The team didn’t remove review. It moved most reading to machines, kept humans on direction, risky code and architecture, and made rollback cheap. Start with one repo, tune REVIEW.md for a few weeks, cap review rounds, and track reverts as the guardrail.

Sources: claude.dev blog · Code Review docs · Automated security reviews in Claude Code