From 2,500 to 30,000 in four months
This is the fourth post in a series. We have written about the loop, about the stopping condition, and about the night watch that lets the loop run without supervision. This post is about what happens afterwards, when it works.
In May, Anthropic merged around 2,500 code changes a day into its main codebase. In September, the figure was over 30,000. That is twelve times as many in four months. Anthropic itself writes that it was Claude's ability to write code that put it in that situation.
On 13 October it explained in an article what that did to the tool every developer uses: Git could no longer keep up. It has built its own system instead, called Scion.
It is easy to read that as news about version control. It is not. It is news about what breaks when output suddenly gets much larger.
What actually broke
Every code change has to be tested before it is released. That is done with automated jobs that build and test the code, and every job needs its own copy of the code to get started. At Anthropic that comes to around 25 million such copies a day, just for testing.
With Git, every copy also fetches the entire history. At Anthropic the history is almost 100 GB, and even a compressed copy of just the latest files is over 25 GB. Fetched the simplest way, that would have been over 600 petabytes of traffic a day. That figure is a calculation, not something that actually happened, but it shows where things were heading.
The reason is that Git is built for people. Every developer has the full history locally, so she can work on a plane without a connection. That is a good idea for a person. For a test machine or an agent that is always online, it is just dead weight.
Anthropic tried to patch it. It fetched only part of the history, only part of the files, and at its peak ran several hundred mirror servers. That bought time. But every workaround still copied the code out to each machine, and none of them kept pace with the growth.
What it built instead
Scion turns the assumption around. There is one central source, and machines are assumed to always be connected to it. Instead of fetching everything, a machine asks only for what it needs: first an overview of the folders, then only the folders the job actually uses. Files are fetched when they are read.
Every file gets an ID calculated from its contents. If the file changes, it gets a new ID, and the old one stays untouched. That means a stored copy can never go out of date. So it can cache in three layers, on the machine, regionally and centrally, and each layer answers over 99 per cent of the requests that reach it.
The result, according to the article: test jobs fetch code roughly a hundred times faster, in seconds rather than minutes. Testing uses 25 per cent less processing power. And the infrastructure is 200 times smaller than the mirroring setup it had before.
Seven people built it in five months, and Claude did much of the work. According to the article, the engineers' most important job was judging the design and saying no to Claude.
Scion will not be open-sourced, and Anthropic itself writes that it is not suitable as a general replacement for Git. The tool is not the point.
The real point
Anthropic's own conclusion is that writing code is no longer what limits it. What limits it is everything around the code that was built for human pace.
Git was not a bad tool. It was a good tool for a world in which people wrote the code. The very thing that made it good for people, that each person has everything locally and can work alone, is what made it expensive once output became twelve times larger.
That is worth pausing on, because the same pattern shows up far outside software.
The same thing happens outside code
Imagine an accounting firm where AI starts drafting quality checks. Or a department where AI writes first drafts of case handling, incident reports or proposals.
The first thing that happens is that the writing gets faster. The next thing that happens is that something else grinds to a halt:
Approval, if every draft still has to be read and signed by one particular person.
Control, if it assumes a person goes through everything, at the same pace as before.
The archive, if it depends on someone manually putting things in the right place.
Access control, if access is handed out by hand, one person at a time.
None of these are bad routines. They are good routines for a world in which people did the work. But they are built for human pace, just as Git was. And when output is multiplied by ten, they are what decides how fast you actually go.
What you can do about it
You do not need to build your own system. You need to know where your own routines assume a person does one thing at a time.
Find the steps. Walk through a process you are considering using AI for, and mark every point where a person has to do something before the work moves on.
Multiply by ten. Ask what happens to each of those steps if the volume becomes ten times larger. The ones that break are the ones that decide whether AI actually saves you time.
Separate what a machine can check from what a person has to judge. Much of the control can be automated if the criteria are written down. That was the point of the post about the stopping condition.
Keep the person where being wrong is expensive. Anthropic's engineers let Claude do most of the work, but they were the ones who said no. It is the same role as in the night watch plans: approving at the gates, not doing everything yourself.
The lesson from Scion is not that Git is outdated. It is that when AI takes over the output, it is the structure around it that has to be rebuilt. Structure first. Technology after.