The gate became a stack
The question the post sets out to answer is a practical one. If Claude writes about 90 percent of Claude Code's code, and merged pull requests to that codebase more than doubled between June and September, who reads it all? Anthropic's answer is that machines do most of the reading — the team's own summary — and that review stopped being a gate at the end of the process. It now runs continuously, in the team's comparison more like spellcheck while you write, so that most changes have already been reviewed and fixed by Claude at least once before a person is asked to look.
The reframing is explicit. The team argues that "did a human read the code?" is the wrong test, and that the better question is what could go wrong with a change and which check, automated or human, is the right one to catch it. Human time is the resource being rationed, measured in approvals per pull request, comments and waiting time, with revert and incident rates as the guardrail: if those rise, no time was actually saved, it was only moved.
What runs before a human is asked
Most review now happens before a pull request exists. The author gives Claude something it can run, tests, a build, a screenshot to compare against a design, and asks it to show the output rather than claim the work is done. A second agent then reviews the diff with fresh context. Two short files steer all of this: a CLAUDE.md describing the project, and a REVIEW.md written by code owners saying what failure looks like in their part of the codebase, what to skip, and what counts as evidence.
Every pull request then gets an AI review against the whole repo. Several agents independently search for potential bugs at the same time, and a separate group evaluates the candidate findings before selected comments are posted; the vote filters what reaches a person, but agreement among agents is not independent proof that a finding is correct, since their reasoning can be correlated. Findings that are only about style or diagnostics are dropped. What survives arrives as inline comments tagged Important, Nit or Pre-existing, and every one has to be fixed or closed with a written reason. A separate security review runs alongside, and a pull request cannot merge while a finding from either review is still open: it has to be fixed, or the thread closed with a short reason. Behind those sit the conventional checks, lint, types, tests on every platform and a build, and a template that asks how the change was tested and how it would be undone.
Humans, allocated by risk
The part most teams will argue about is the approval table. A classifier reads the change and assigns a tier; a second classifier can pull a particular change back into human review even when its tier says otherwise. Low-risk changes, docs, copy, internal-only features, additions behind a flag, need no human approval once the automated and security checks are green. Medium-risk changes need one person. High-risk code, and a fixed set of sensitive paths, need two. Only authors on a trusted list get the lighter paths, an agent's approval never counts as a person's, and an approval covers one specific commit. New commits that the system cannot vouch for invalidate it, and the change must then meet the applicable checks and approval requirements again.
Two boundaries matter here. The public product, Code Review for Claude Code, now generally available on Team and Enterprise plans, posts findings and does not approve anything; Anthropic says approving a pull request remains a human call for its customers. The zero-human path exists on Anthropic's own repositories, where owners decide which low-risk changes may merge on checks alone. The post also concedes what is missing: there are no circuit breakers yet that tighten approval automatically when revert or incident numbers move, and its engineers want them before more code moves to zero-human merges.
The failure mode is the loop itself
The most useful section is the one about what went wrong. An agent author and an agent reviewer can keep each other busy indefinitely, and one CLI pull request went through more than 50 rounds of review and fixes overnight before its author stopped it. When the team ran git blame on what the reviewer kept flagging, about 59 percent was code that had been there since the reviewer's first pass: each round was finding a few more old bugs rather than new ones in the change. The fixes are unglamorous and copyable. Cap review at three rounds, then make the author reconsider the approach. Re-review only the new diff after the first passes. Flag the class of bug so every instance gets fixed at once. Never post a finding twice.
The team also turned its own history into the reviewer's test set. Past pull requests that caused incidents, with their fixes and reverts, are now an evaluation the reviewer runs against daily, and noise is measured by watching what authors actually do with its comments. That is a more serious discipline than the headline numbers.
How to read the numbers
Those numbers still need reading carefully. Merged pull requests more than doubled, and the share reverted fell by more than 40 percent. A falling share over a doubling volume does not by itself tell you whether the number of reverts fell, rose, or stayed flat, and the post gives no absolute count. Nor does it isolate how much of the change the review system caused, as opposed to everything else that shifted in the same four months. Every figure in the post is Anthropic reporting on Anthropic, about a product it sells, with no independent audit cited. The monorepo figure that travels with this story, about 2,500 changes a day in May to more than 30,000 in September, describes Anthropic's wider monorepo; the post is clear that Claude Code lives in a separate repository, and the two should not be combined into a single volume claim.
None of that makes the document useless. It makes it a design document with self-reported results attached — and as a design document, it shows in unusual detail what a review process looks like after the reviewer stops being the bottleneck and becomes a system that needs its own guardrails.
The practical angle
If your team already lets agents open pull requests, the transferable parts need no new product: give the agent checks it can run before it opens anything, put your review standards in a short file the reviewer actually loads, have findings verified before they reach a person, and cap the rounds. Match approval to the risk of the change rather than the seniority of the author, and keep the lighter paths for people you already trust with production.
What does not transfer automatically is the safety net underneath. Anthropic's system leans on small changes, feature flags, an employee-first release channel and rollback in minutes. If a bad merge on your system takes a day to undo, the correct lesson from this post is not to remove the human. It is to build the reversibility first.
Sources
- [1] Claude Code team (Anthropic), "How the Claude Code team does code review", claude.dev, published October 15, 2026 (primary source for every fact in this article: the ~90 percent authorship claim, June–September PR volume and revert-share figures, the monorepo context figure and its separate-repo caveat, the review layers and rollback, the finding-evaluation and filtering mechanics, the risk-tier approval table with its trusted-author and one-commit rules, the 16 percent to 54 percent preview-era comment-coverage figure and Team/Enterprise general availability, the 50-plus-round incident, the ~59 percent pre-existing figure, the convergence fixes, the incidents-as-eval loop, and the admitted absence of circuit breakers)Read source
- [2] DEV Community, "Claude Code Is 90% AI-Written. Here's the 7-Layer Code Review System That Keeps It From Collapsing", October 2026 (secondary explainer confirming the post's structure and its Hacker News circulation; no fact in this article rests on it alone)Read source