Ai Coding 4 min read

Inside the Review Pipeline That Guards Code Claude Mostly Writes

The Claude Code team published its engineering playbook on October 15: Claude writes about 90% of the product's own code, monorepo changes grew from 2,500 to 30,000 per day, and a layered AI review pipeline kept the revert share falling 40% while review rounds converged from 2.08 to 1.32.

Anthropic’s Claude Code team has published the most detailed account yet of what engineering looks like when agents write most of the code. The post, published October 15 by Addy Osmani, Morgan Westlee Lunt, and Qing Wang, states plainly that Claude writes about 90% of Claude Code’s own code, and that Anthropic’s monorepo absorbed 30,000+ changes per day by September, up from roughly 2,500 in May. The team’s core reframe: stop asking “did a human read it?” and start asking “what could go wrong with this change, and which check, automated or human, is the right one to catch it?” The stated optimization target is “the minimum amount of human review time that doesn’t raise reverts or incidents,” and by their numbers it is working: merged PRs more than doubled from June to September while the revert share fell over 40%, and review rounds to convergence dropped from a mean of 2.08 to 1.32.

Six gates, only one of them human

The pipeline layers six checks, and the design principle is that no single gate has to be perfect. Before a PR even opens, Claude must run tests, builds, and linters and paste the output, while a fresh-context subagent reviews the diff; project-level CLAUDE.md describes the codebase and a code-owner-written REVIEW.md tells reviewers what actually matters in this repo. On the PR itself: required CI (lint, types, cross-platform tests, packaging), then AI code review where parallel agents hunt bugs and a separate verifier group votes on findings, with only consensus findings posted, sorted into Important, Nit, and Pre-existing. Every finding must be fixed or resolved with a written reason. A separate security review pass blocks merge on open findings and ships as a GitHub Action.

Only then does a human appear, and the risk tier decides how many. A classifier reads the change itself, not the author’s identity: docs and flagged additive changes need no approval, most changes need one, and high-risk paths like billing, the auto-updater, and CI workflows need two. Three rules keep the human gate honest: agent approvals never count as human, approvals attach to a specific commit and are dismissed when new commits land, and the merge queue re-runs everything against latest main. After merge, feature flags, internal dogfooding, and gradual rollout to stable with weekly on-call and fast rollback close the loop.

The unglamorous fixes that made it work

The most transferable part of the post is what broke and how they fixed it. An agent-written PR once went through 50+ overnight review rounds without converging, so they capped review at three rounds, switched re-reviews to diff-only, taught the reviewer to flag bug classes rather than single lines, and suppressed repeat findings. Git blame analysis showed 59% of repeated reviewer flags pointed at code that had been present since the first pass, noise masquerading as signal. Reviewer quality is now regression-tested like everything else: past incidents and reverts became a curated eval set run daily against every reviewer change, and improvements only ship if scores rise. Noise is measured two ways: tracking how humans respond to comments, and deliberately running the reviewer on known-clean PRs to count false positives.

The cultural changes run deeper than the tooling. Context sharing moved from “everyone reads the diff” to “ask Claude for a just-in-time explainer of the code slice”; nobody maintains a full mental model anymore. Killed work is treated as cheap, because code agents make abandoned wrong-direction PRs feel like no loss. And the team’s defense of speed over ceremony is worth quoting: “Slowing down does lower your error rate, but mostly because you’re doing less of everything.”

What stays human, and how this connects to Postgres

Five decisions remain permanently human: whether to build something at all, risky code, pattern-setting architecture, reading the evidence (test output and screenshots rather than rubber-stamping), and owning the outcome, enforced by “you land it, you own it.” Boris Cherny’s summary of the whole system: giving Claude verification makes results “two to three times better.”

Read together with this week’s Postgres 19 delay, where AI-assisted review found more bugs than humans could fix in time, a pattern emerges. Anthropic built triage capacity (severity sorting, consensus voting, risk tiers, convergence caps) into the review pipeline before the finding volume arrived; Postgres hit the same flood with a human-sized fix queue and had to revert features instead. The lesson for any team adopting AI coding agents in 2026: the review system, not the code generator, is the thing to engineer first. If you want the mechanism in reverse, the failure mode without this design is exactly what the Postgres 19 delay showed, and Anthropic’s own earlier move to auto mode for Claude Code was the first step down this road.

Get Insanely Good at AI

Get Insanely Good at AI

The book for developers who want to understand how AI actually works. LLMs, prompt engineering, RAG, AI agents, and production systems.

Keep Reading