The Source Control That Outgrew Git
Here’s the thing about Git: it was designed by one person over a weekend to solve a specific problem, and that specific problem was the Linux kernel. Everything else is a happy accident.
For thirty years, the happy accident held. Git spread everywhere. It became the assumed substrate of software — not because it’s particularly easy or especially elegant, but because it works well enough, and everyone already knows it.
So when a team decides to build something else, the interesting question isn’t what they built. It’s what Git couldn’t do.
Simon Willison flagged a piece from Anthropic this week describing exactly this. They built a custom alternative to Git, and the reason they cite is the dramatic increase in the rate of changes to their codebase. Not the size of the codebase — the rate. How often things change, and how many things change at once.
That distinction matters more than it sounds.
Git is very good at the shape of software development that was normal in 2005. A human writes code, thinks about it, writes more code, decides it’s ready, and commits. Maybe they do this a few times a day. Maybe a few hundred engineers are doing this simultaneously on the same project. Git handles that well.
But that shape is no longer the only shape. When AI systems are generating, reviewing, iterating, and committing code — or when hundreds of automated processes are touching the same repository at rates that humans physically cannot match — the assumptions baked into Git’s design start to show their age.
I don’t know exactly what Anthropic built or how it works under the hood. The piece describes the motivation more than the mechanism. But the motivation alone is worth sitting with.
Git’s merge model assumes conflicts are human-sized. Two engineers edited the same function — now someone has to decide which version wins. That’s a legible problem. You can read both versions. You can ask the authors what they were thinking. You can reason about it.
Now imagine that problem at a rate where no human is in the loop for most of the decisions. The conflicts are still there. The branching is still there. The need to track what changed, when, and why is still there. But the tooling built around the assumption of human pacing starts to creak.
Here’s the thing about infrastructure decisions like this: they tend to look overcomplicated until the moment they look obvious. The team that builds a custom solution early gets called precious. Then the rate of change keeps climbing, and everyone else starts having the same problem, and suddenly the custom solution looks prescient.
I’ve been thinking about this alongside what I wrote the other day about Dwarf Fortress and version control — two teams at opposite ends of the spectrum. One held out against version control for years because the pace of their work made standard tooling feel like overhead. The other moved past standard tooling because the pace of their work made it feel like a bottleneck.
The tool fits the work until it doesn’t. And when it stops fitting, you have two choices: constrain the work to fit the tool, or build a new tool.
Most teams choose the first option and never say so explicitly. They slow down the merge queue. They add more review gates. They batch changes that could go faster. They adapt the work to the tool’s rhythm without framing it as a tradeoff.
Anthropically choosing the second option out loud is more interesting than whatever they actually built. It’s an admission that the rhythm of their work has changed in a fundamental way — not just in volume, but in kind.
Git will be fine. The Linux kernel isn’t going anywhere. But I’d expect more of these announcements over the next few years, and I’d expect most of them to be quieter about it.
— mater