How the Claude Code Team Reviews Code When Claude Writes 90% of It
Anthropic's Claude Code team moved most code review to machines, scaled human review by risk, and doubled merged PRs while reverts fell by 40%.
Today I learned how the Claude Code team at Anthropic reviews code, from their post How the Claude Code team does code review. Claude writes about 90% of Claude Code’s own code, so humans can’t read every line. From June to September, merged PRs more than doubled, and the share that got reverted fell by more than 40%.
They didn’t drop review. They changed the question from “did a human read this?” to “what could go wrong, and which check, automated or human, should catch it?”
No single gate. Each layer catches some bugs, and rollback handles what gets through:
- Verify before the PR. Claude runs tests, build and lint and shows the output. A second agent reviews the diff in a fresh context.
- AI review on every PR. Several agents hunt for bugs in parallel. Other agents vote on each finding, and only the ones they agree on get posted. Style nits are dropped.
- Security review that blocks. Every open finding must be fixed or closed with a reason before merge.
- Required CI. Lint, types, tests on every platform, build.
- Human approval scaled by risk. A classifier reads the change and picks the tier.
- Merge queue, flags, internal use first, staged release.
- Fast rollback. Flags turn off without a deploy.
| Risk | Examples | Human approvals |
|---|---|---|
| Low | Docs, copy, additive changes behind a flag | 0 |
| Medium | Normal product changes, caching, auto-updater | 1 |
| High | The riskiest code and a few always-guarded paths | 2 |
The change sets the tier, not the author. A bot’s approval never counts as a human’s. The person who prompted the agent counts as a reviewer and owns the result.
An agent author and an agent reviewer can keep each other busy forever. One PR went through more than 50 review rounds overnight. About 59% of what the reviewer kept flagging was old code it had already seen.
Their fixes:
- Cap at three rounds, then ask the author to rethink the approach.
- Re-review only the new diff after the first few passes.
- Flag the bug class, so the author fixes every instance at once.
- Never repeat a finding.
The mean number of reviews to pass dropped from 2.08 to 1.32.
They also turned past incidents into an eval set. Every change to the reviewer’s prompts, tools or model is scored against it daily.
- Decide if something should be built at all
- Review risky code (billing, auto-updater, CI workflows)
- Review architecture that others will copy
- Read the evidence: test output, screenshots, findings
- Own the outcome
And to understand a part of the codebase, they don’t read diffs. They ask Claude to write an explainer for exactly that slice.
Takeaway for my own repos: add a short REVIEW.md, run /code-review before opening a PR, and turn repeated review comments into lint rules.
- How the Claude Code team does code review by Addy Osmani, Morgan Westlee Lunt and Qing Wang