B EN Anthropic·Practitioner post·

How the Claude Code team does code review

B · Useful, limited Anthropic engineers (Addy Osmani and colleagues) describe their own review process in useful detail, but the outcome numbers are self-reported by the vendor of the review product.

Summary based on the full text·Original: about 14 minutes to read

In short

A claude.dev engineering post (15 October 2026) by Addy Osmani, Morgan Westlee Lunt and Qing Wang on how the Claude Code team reviews code when agents write most of it. Most reading moved to machines; humans review by risk tier; and the team invests in fast rollback. The stated goal is the least human review time that does not raise reverts or incidents.

Key numbers

  • about 90 percentshare of Claude Code's own code written by Claude
  • more than 40 percentfall in the share of merged PRs that had to be reverted, June to September, as merged PRs more than doubled
  • 16% to 54%internal PRs receiving substantive review comments after the AI reviewer launched
  • about 2,500 to more than 30,000changes landing per day in Anthropic's monorepo, May to September 2026
  • about 59%share of repeated reviewer flags that pointed at code present since the first pass

As reported by the source.

Read the original on claude.dev

English·Web page·opens claude.dev

What it reports

  • Merged PRs to Claude Code more than doubled June to September while the revert share fell by more than 40%. Monorepo changes per day rose from about 2,500 to more than 30,000.
  • Layers: self-verification before a PR (tests, builds, screenshots, a fresh-context subagent review), AI review on every PR with multi-agent voting on findings, blocking security review, CI, risk-tiered human approval, merge queue, flags and staged release, fast rollback.
  • Risk tiers: low (docs, flagged additive changes) needs no human once checks pass; medium needs one; high needs two. A classifier sets the tier from the change, not the author. Only trusted authors get lighter paths; an agent's approval never counts as a human's.
  • Every finding must be fixed or closed with a reason. Past incidents form a daily eval set for the reviewer.
  • Convergence problem: one PR went through more than fifty overnight review-fix rounds; about 59% of repeated flags were old code. Fixes: a three-round cap, diff-only re-review, flagging bug classes, no repeated findings.
  • Humans keep: whether to build at all, risky paths such as billing and CI, architecture, reading evidence, and ownership of every change.

How they got it

Internal process description with team metrics (approvals per PR, wait time, reverts, incidents). No method or baseline for the headline numbers is given.

Limits

  • Self-reported by the company selling Code Review for Claude Code.
  • Revert share can fall for reasons other than review quality; no controlled comparison.
  • Applies to a team building the tool, with unusual internal use.

Why it matters for companies

The post is a practical blueprint for review at agent volume: tier by risk, require a named human owner, never let a bot approval replace a person, and measure human time with reverts and incidents as the guardrail. The convergence lesson is general: agent authors and agent reviewers can loop without limit unless someone caps the rounds. Copy the structure, not the numbers.

Summary based on the full text. Read the original for the full argument and data.Read the original on claude.dev

Tags

Same week

All of Week 42