Claude writes 90% of its own code: who reviews all that?

Claude writes about 90% of Claude Code's code. Not 90% of the drafts, not 90% of the little bits: 90% of the software that hundreds of thousands of developers launch every day. So the question everyone is asking eventually comes up: who reviews all that? Anthropic published its answer on Thursday. And it isn't “no one”.

Not everything goes through the same counter, and that's precisely the idea

The problem, in one number

At Anthropic, the number of changes integrated each day went from around 2,500 in May to more than 30,000 in September. Twelve times more in four months. I told you three days ago how this avalanche pushed them to replace Git, the tool that has kept the code's history for twenty years. But changing the pipeline only solves half the problem. The other half is that someone has to look at what goes through it.

And code review, for those who aren't in the business, is the central ritual of development: before a change enters the software, a colleague reads it and gives their opinion. It catches stupid mistakes, spreads knowledge, and avoids having a single person be the only one who understands a piece of the program. It's slow, it's tedious, and no serious team goes without it.

Except that at 30,000 changes a day, “a colleague reads it” becomes mathematically impossible. They would have to hire half the city.

What they did, and it isn't removing code review

Anthropic's answer can be summed up in one sentence: it's no longer the human who reads everything, it's the human who decides what deserves to be read. The rest drops down a level at each stage.

First, even before proposing its change, Claude runs the tests and has its work reviewed by another instance of itself, which discovers the code without knowing how it was written. Then the usual machinery checks that it compiles and that the tests pass. Then a team of agents reviews it in parallel, each looking for bugs on its own.

And there's a detail here that I find clever: the comments found aren't published as they are. Another group of agents votes on each one, and the comment only appears if enough voters find it justified. Anything related to style or tidying up is thrown out automatically. That's their answer to the worst flaw of an automatic reviewer: the guy who throws forty comments at you, thirty-nine of them about indentation.

Three queues, like at the airport

Then comes the part that spoke to me the most. A classifier, meaning a small program that sorts things, looks at the change and decides its risk level. Three levels, three treatments.

The classifier judges the change, not the face of the person who wrote it

Low risk, like documentation or a function added behind a switch that keeps it turned off: no one reviews it, as long as the automatic checks are green. Medium risk, meaning most product changes: one person. High risk, sensitive areas like billing or the automatic update system: two people, always.

Two safeguards that I note because they say everything about the rest: an agent's approval never counts as a human's, and an approval applies to a specific version, not to “what this developer will do next”.

The three-in-the-morning infinite loop

The funniest part of the post, and the most telling, is the story of a change that made more than fifty review round trips during the night. The agent found a problem, the agent fixed it, the other agent found another problem, and so on until the author, upon waking up, unplugged everything.

Fifty rounds of review while you sleep. The dream, on paper

The cruelest part: 59% of what the reviewer kept flagging concerned code that had already been there on the first pass. He was rereading his own territory on repeat, like a dog chasing its tail.

So they added some common-sense rules. After three rounds, you stop and ask yourself whether the approach isn't bad from the start. The following reviews only look at what has changed since. And a comment that has already been made isn't made again.

The second line is the real victory: all-nighters cut by six

As a result, the changes that pass on the first try rise from 65 to 78%, and those that require five rounds or more fall from 8.9 to 1.5%. Their priority is actually written in black and white: catch the real bugs first, reduce the number of rounds afterwards. In that order.

The two files that run all this

On the practical side, and this can be applied to your setup, everything rests on two text files placed in the project.

The first, CLAUDE.md, describes the project: the technologies used, the conventions, what the project is trying to do and what it won't do. Their advice is to keep it short and point to the rest of the documentation rather than copy everything into it.

The second, REVIEW.md, is written by those who know each part of the code best, and it tells the reviewer what really matters here. The good examples they give are very concrete: say what a failure looks like in this specific corner, limit the number of detail comments, list the folders to ignore, require a file and a line number as proof, and start the report with the number of problems found, even if that means plainly writing that there is nothing to fix.

I have exactly these two files in my projects, and I can confirm that the difference between a useful reviewer and a pain in the ass mostly comes down to what we took the trouble to write in them.

What humans keep

Their list is short, and it's the one I would keep if I could only retain one paragraph. Decide whether the thing should be built. Review the code that touches money and updates. Review the architecture that others will copy for three years. Look at the evidence, meaning the test results and screenshots, rather than the lines one by one. And take the blame when it breaks in production, because no agent will do that in your place on Sunday night.

One sentence from the post sums up the shift well: “has a human read the code?” is a bad question, a convenient approximation. The right one is “what could go wrong here, and which check catches it?”. So human review comes down from its pedestal: it becomes one check among others, placed where it brings the most value.

My opinion

I pretty much agree with the substance, and there is one statistic that makes me smile: when they hooked up their automatic reviewer internally, the share of changes receiving a real substantive comment rose from 16 to 54%. In other words, before AI, five out of six changes went through without anyone saying anything substantial. We've all done that: we look at the title, click “approved”, and go back to our own work. The machine doesn't replace rigorous review, it mostly replaces review that wasn't happening.

What still bothers me is the knowledge. Reviewing a colleague's code, that's how you learn a project. If the machine reads everything and the human only looks at the evidence, who still knows the program five years from now? Anthropic answers this with automatically generated code explanations, and I want to see it. Reading a summary about a house isn't the same as having lived there!

Sources

• Addy Osmani, Morgan Westlee Lunt and Qing Wang, October 15, 2026: how the Claude Code team does its code review
• Hacker News: the developers' discussion around this post

Article written with the help of Claude Code, reviewed and corrected by me.