Here is a sentence that would have sounded like a stunt a few years ago. According to Anthropic, Claude now writes about 90 percent of the code for Claude Code, the company’s own coding tool. The figure comes from an account published on October 16, 2026 by members of the Claude Code team – Osmani, Lunt and Wang – describing how they build the product day to day. Simon Willison highlighted the post the same day. The tool is, in large part, building itself.
The headline number gets the attention. The quieter change underneath it matters more. Code review, the team says, no longer sits at the end of the process like a teacher grading homework after class. It runs continuously, while the code is being written, closer to spellcheck than to a formal inspection. Most changes, the team reports, are reviewed and fixed by Claude before a human ever looks at them. Read that again. The human is not the first reader anymore. The human is the second one.
The numbers behind the claim
Anthropic’s team account gives two figures that put shape around the story. Merged pull requests – the chunks of code that actually land in the product – more than doubled between June and September 2026. At the same time, the share of changes that needed a revert, meaning work undone after it shipped, fell by more than 40 percent.
Those two numbers belong together. More code landing is not impressive on its own; anyone can ship faster by lowering the bar. What the team is claiming is speed and a lower error rate at once, which is the harder trick. If twice as many changes merge and a smaller share bounce back, something in the process itself has changed, not just the pace.
It helps to place this next to other recent lab work on reliability. When researchers reported that Google’s Willow chip cut quantum errors sharply in a Science study, the real story was not raw power. It was error control. Coding is heading through the same door. The question is no longer who or what wrote the line. It is how quickly a mistake gets caught, and how close to the moment of writing that catch happens.
Review moved inside the writing
Traditional code review has a rhythm most programmers know by heart. You write for hours, sometimes days. You open a pull request. A colleague reads it later – tired, busy, context-switching from their own work – and leaves comments. You fix, you wait, you fix again. The loop can stretch across a week, and by the time a real problem surfaces, the author has half forgotten why they made the choice being questioned.
Continuous review breaks that rhythm up. If Claude reads each change as it appears, flags a shaky assumption on the spot and suggests a fix while the reasoning is still fresh, review stops being a gate and becomes part of the act of writing itself. The spellcheck comparison in the team’s account is apt. Nobody mails a letter and then asks a friend to check the spelling. The red underline shows up while your hands are still on the keyboard. That is the model now being applied to software, except the underline can also explain itself and propose the correction.
What the human still does
None of this removes people from the loop, and the team’s account does not claim it does. A human still decides what the product should do, still looks after Claude has done its pass, and still carries responsibility for what ships. Taste, judgment, product sense – call it what you like, it has not been automated away. What has changed is the order of operations. The first, tireless, line-by-line pass belongs to the machine. The human pass becomes about intent. Does this do the right thing, not just a correct thing?
That distinction matters. Checking syntax and spotting a missed edge case is work a patient reviewer does well on a good day and badly on a bad one. Deciding whether a feature should exist at all needs context no model holds on its own: the roadmap, the customer complaint from last spring, the promise made to a partner.
Why this matters beyond Anthropic
Anthropic has an obvious advantage here. It builds the model and the coding tool under one roof, so Claude gets tested on a real, demanding codebase every day. Most teams do not have that luxury.
Still, the pattern travels. Any team can ask the question this account raises: where in our process does checking happen, and how late is too late? The same shift is showing up in consumer software too, as assistants move closer to the moment of action – think of the way ChatGPT now works inside Chrome tabs to help while you browse, rather than waiting in a separate window for you to come and ask. Help that arrives during the task beats help that arrives after it. Coding is where the evidence is clearest, because code either works or it does not, and the numbers – merged requests up, reverts down – can be counted.
A few honest caveats
These figures come from Anthropic’s own team, writing about its own product. That does not make them wrong, but they should be read as a report from inside the house, not an independent audit. Other teams, on older systems with messier histories, should expect messier results.
There is also a fair skill question. If junior engineers never do the slow, first-pass review work themselves, how do they develop the eye senior engineers rely on? Teams will have that argument, and they should.
The takeaway for working teams
Strip away the headline number and a practical lesson remains. Move checking earlier. Make the first review pass fast, automatic and continuous, so human reviewers spend their attention on design, intent and risk. Measure two things at once – how much ships, and how much comes back – because speed alone is just a faster way to make a mess.
Ninety percent is a striking figure, and it will be quoted all week. But the doubling of merged pull requests alongside a drop of more than 40 percent in reverts is the part to sit with. The story is not that a machine learned to type code. The story is that review – the oldest quality habit in software – moved inside the writing itself, and the work got better while it got faster.
Be First to Comment