This is my summary of How the Claude Code team does code review, written by Addy Osmani, Morgan Westlee Lunt, and Qing Wang and published on 15 October 2026. The ideas and numbers are theirs. Read the original for the full detail.
The problem
On the Claude Code team, Claude writes about 90% of the code. Between June and September, merged pull requests more than doubled. The share of PRs that needed a revert fell by over 40%. The team did not drop review. It moved most of the reading to machines, so that human time and attention go where they matter. The goal: merge most PRs with at most one person involved, with no rise in reverts or incidents.
Two jobs of review
The authors say review does two things: it catches problems before they ship, and it spreads understanding of the codebase across the team. Review now runs continuously. Usually Claude has reviewed and fixed a change before a person looks at it.
The layers
Before the PR: Claude runs tests and builds. A subagent with fresh context reviews the diff.
On every PR: required CI, plus an AI reviewer. Parallel agents look for bugs, and verifier agents vote on each finding. A security review can block the merge.
Human approval by risk: a classifier puts each PR in a tier that needs zero, one, or two people. Sensitive paths always need a person.
Merge and release: a merge queue re-runs the checks, changes ship behind flags, and rollback is fast.
Teaching the reviewer, and stopping loops
Reviewer guidance lives in CLAUDE.md and in a REVIEW.md file for each repo. Past incidents form an eval set that runs daily. Review loops needed work too. One PR went through more than fifty rounds, and about 59% of the flagged code was older than the PR. A three-round cap and diff-only re-review cut the share of PRs needing five or more rounds from 8.9% to 1.5%.
What people still do
Humans decide what to build, review risky code and architecture, and own the outcomes. The original ends with an adoption checklist: pre-PR checks, PR templates, risk tiers, and merge safeguards.