How Claude Code Team Runs Code Review: Pre-PR Checks, 3-Round Limit, Risk-Based Human Approval

Pre-PR Self-Checks

Before opening a PR, authors run tests and builds locally. If UI changes are involved, they compare screenshots against design specs. Claude must return actual run results, not just a "done" message. A fresh sub-agent then reviews the diff without prior context, reading code to find issues. Many engineers also run internal Skills: one for bug hunting, one for diff minimization, one for end-to-end feature walkthroughs. Catching compile failures or UI mismatches locally eliminates a round-trip through CI.

Inside the PR: Automated Review Layers

Once a PR opens, CI runs dozens of checks (lint, types, cross-platform tests, builds). Separately, code review agents read the diff against the whole repository: they verify bug root causes, assess blast radius, and vote on findings. Style nits, diagnostic wording, and opportunistic cleanups are filtered out. Security reviews run on a separate track.

Code owners write REVIEW.md files telling reviewers what to watch for in their area. Good REVIEW.md s are short and specific: for docs, check content accuracy; for config, check routing correctness. Comments must cite file and line number. A CLAUDE.md in the repo captures stack conventions and goals; every review loads it, and violations are flagged. Boris Cherny notes the team maintains a shared checked-in CLAUDE.md, adding corrections whenever Claude errs.

When reviewers repeatedly flag the same issue class, the team fixes it at the source: adjust the Skill, add a lint rule, or update CLAUDE.md / REVIEW.md.

Closing the Review-Fix Loop

Findings are tagged Important, Nit, or Pre-existing (existed before this PR). Every finding must be resolved — fixed or closed with justification — before merge. Agents often handle fixes overnight, so authors return to a new review round.

The team discovered a runaway loop: one PR cycled 50+ times. Using git blame, they found ~59% of flagged lines already existed in the first review round. The reviewer kept surfacing old issues; the fixer agent patched them, triggering another review. Humans skip Nits in seconds; agents treat each as a code change, commit, and re-review.

They changed the re-review policy: after the first few rounds, only new diffs are re-scanned; same-class issues are batched so the author fixes all occurrences at once; duplicate comments are suppressed. A hard cap was added: after three rounds, the reviewer asks the author to step back and rethink the approach. Legacy code scans now run nightly as a separate job, decoupled from PR reviews.

Post-adjustment, single-round pass rate rose from 65% to 78%; PRs needing five or more rounds fell from 8.9% to 1.5%. (These are whole-system before/after numbers, not attributable to any single rule.)

Human Approval by Risk Tier

Anthropic's target: most PRs merge with at most one human involved (the author counts), provided revert and incident rates don't rise. They track human approvals, human comments, and PR wait time; revert/incident rates are guardrails.

A classifier assigns risk level; a second classifier decides if a low-risk change still warrants an extra pair of eyes. Low risk (docs, copy, internal-only features, flag-gated incremental changes) can merge after CI, code review, and security checks pass — no human approval needed. Medium risk (regular product changes, cache, auto-updater, system prompts) requires one human approval. Highest risk (core code, designated sensitive paths) requires two.

Only trusted authors (mainly the repo's owning team) take the lighter path; others need an extra approval. Code-owner-marked sensitive paths and CI workflow files always require human review. An agent's "Approve" button doesn't count. Agent-written code counts as authored by the person directing it, who serves as a required reviewer.

Approval binds to a specific commit. New commits (agent pushes, manual conflict resolution) invalidate prior approvals. PR templates require test plans and rollback steps; Claude can draft them, but the change author must confirm.

At the human approval step, a green CI only means existing checks passed. Reviewers must still judge whether the change is worthwhile, what tests are missing, and whether the pattern will be misused later. A rule of thumb: if you can't articulate what checks might miss, demand a real review — don't fast-approve.

One team found external contributions still needed human eyes even after queue times dropped. Reviewers ask "should we do this?" — sometimes surfacing prior decisions or simpler alternatives early, rewriting or closing PRs before they stall.

Reading diffs used to build cross-team code awareness. Now machines read most diffs. Anthropic has no formal replacement yet; engineers ask Claude for on-demand explanations (e.g., "How does Claude Code fetch tenant settings?") and follow public Slack channels to stay current.

Post-Merge Guardrails

Two passing PRs can still break when combined. A merge queue rebases onto latest main and re-runs checks. New features hide behind feature flags for internal dogfooding; public rollout goes to latest then stable. Flags allow instant kill without redeploy.

Authors and on-call engineers watch metrics and incident dashboards. Weekly on-call rotations conduct retrospectives asking: which layer should have caught this?

Incidents are added to an eval set: related PRs, fixes, and reverts are collected; familiar engineers confirm bug locations; the reviewer agent is tested daily against these cases. Comments are categorized by author response: fixed, disputed, intentional, or dismissed. Known-good PRs are also fed to the reviewer to detect harmful suggestions. The team accepts higher false-positive rates to catch more real issues.

Bad merges are still caught by authors, on-call, and dashboards. An automatic tightening mechanism that raises approval requirements when reverts/incidents spike has not yet been built; engineers want that guardrail before further reducing human approvals.