On 13 October, Anthropic published how it replaced git for its monorepo. The numbers are the headline: around 2,500 code changes merged per day in May 2026, more than 30,000 per day by September. At that rate git itself became the bottleneck, so a team of seven built a new version control system, Scion, plus a code review tool and half a dozen related systems, and migrated everything in five months.
Most of the reactions I saw took the same turn: if agents merge thirty thousand changes a day, what is left for a person to do? It's a fair question. The post answers it, and the answer isn't "nothing".
The bottleneck moved
The post opens with the claim the rest depends on: at Anthropic, writing code is no longer the bottleneck. The infrastructure built for human scale is: source control, builds, CI. Their monorepo's main history is almost 100 GB, they check out code on the order of 25 million times a day for CI, and at their peak they were running several hundred internal git mirrors to keep up.
They're careful to say this is unusual. Scion is "by no means a suitable replacement for git for general use", it only makes sense for enormous monorepos, and Anthropic can spend far more tokens on its own work than any normal company would. Most teams aren't there yet. The authors expect others to start feeling the same pressure within six to twelve months.
So the scale is theirs. The shift underneath it isn't. Producing code got cheap.
What the engineers did
The section I'd read twice is the one about people. Everyone who worked on Scion, the post says, now rates Claude as better at writing code than themselves. And yet the engineers supplied the parts that decided whether the system would work: the understanding of how components fit together, the design trade-offs, the choice of which problems to solve and at what scale.
Then the line that sums it up: very often the engineers' role was to tell Claude "no".
The examples are specific. Agents sometimes broke core system constraints to satisfy a pattern that should never have been allowed: some systems tried to find when a change had merged by reading the commit log line by line, instead of asking the code review tool. Their adversarial review, which they use heavily and call effective, could also be myopic: one review was so defensive about trusting another internal service that Claude added validation and complexity nobody needed, and engineers had to steer it away from the extra complexity.
Neither of those is a bug a test would catch. Both are code that works and shouldn't exist.
Review didn't go away. It changed what it reads.
The sentence I expected to find, and didn't, was "we stopped reviewing". Instead: the team still reviews every change request to the system, but reviewers now look at the intent of the change rather than reading every line of code.
The tooling is built around the same idea. Their code review tool can express rules about which changes need which approvals, so a comment-only change and a sensitive change to the logic aren't treated alike. The point, in their words, is that human reviewers can focus on the most consequential changes.
Put those together and you get a different job description. The human isn't the one producing the code, and isn't a line-by-line proofreader either. The human decides what the change is for, whether it should exist, and which parts of it carry enough risk to look at closely.
Writing is cheap. Keeping is expensive.
That's the answer to "what are the humans for", and I think it holds well below Anthropic's scale.
When an agent can write ten versions of a function in the time it took you to write one, the cost of code isn't in producing it anymore. It's in everything that comes after you keep it: the next person who has to understand it, the constraint it quietly breaks, the complexity it adds that someone will maintain for years. Generating code is cheap. Choosing which code is worth keeping is expensive, because every "yes" is a commitment.
Anthropic's engineers spend their attention on exactly that choice. Not on typing, and not on reading every line, but on saying no to the change that solves the wrong problem, and on finding the few places where a change is consequential enough to look at closely.
Where Reado fits
This is the job I'm building Reado, the IDE for reading the code your AI agent writes, for, at a much smaller scale: one developer, one agent, one repository.
Reado doesn't decide for you which changes matter. It gives that decision a place to live. In a guided review the agent plans a route through the change in the order that makes it make sense, and you leave comments on the exact lines that need a "no" or a question. Each comment is either a task the agent has to resolve or a note for the next reader, and it's stored as Markdown in your repository, so the reason a line looks the way it does outlives the session. When you want the agent to look first, its findings arrive as proposals, and nothing becomes a task until you accept it.
Anthropic built Scion because of the volume. You probably don't have their volume. You do have the same choice to make, every time an agent hands you a diff: is this worth keeping?
The Reado app is free and MIT-licensed if you want to try it: download it here.
Top comments (0)