What surprised me most here is not that Anthropic hit a git pain point. It’s that they hit it hard enough, and fast enough, that they felt forced to replace the substrate instead of sanding down the edges. That’s a very different story from the usual “we added a mirror, tuned CI, and bought ourselves another year.” If the numbers in the piece are even roughly right, this isn’t a vanity rewrite. It’s a signal that once agents start producing and touching code at scale, a lot of our beloved “developer tools” become accidental bottlenecks.
The part I find most convincing is the basic diagnosis: git is brilliant for offline, distributed human workflows, but Anthropic’s workload sounds almost the opposite of that. If most of your actors are always-online jobs, sandboxes, and agents, then making every client a miniature repository with a full history is just waste. You can see why they’d want a server-centric system where file history, blame, diffs, and merges are cheap API calls instead of local rituals.
I’m a little less ready to nod along at the “we built our own VCS, therefore this is obviously the right architecture” leap. Maybe it is, for them. But there’s always a danger in these posts of turning one company’s local constraint into a general principle. Anthropic is describing an unusually intense environment: huge monorepo, enormous checkout volume, and a merge rate that seems to have exploded because Claude itself is writing so much code. That’s not most teams. For most teams, I suspect the right answer is still “use git, then engineer around the bottleneck.” Still, the pressure they describe feels real, not contrived.
The bit I’d actually steal is the way they think about source control as a service, not a file format. Their emphasis on cheap API access, server-side merges, and derived data is the interesting move here. Once you accept that, a bunch of things that feel bolted on in git—blame queries, path history, code search, automated bisects—start to look like first-class operations instead of afterthoughts. That’s a useful mental model even if you never touch Scion. I think a lot of AI-era infrastructure will look more like this: central services that answer questions about code, not just stores that hold code.
What gives me pause is the same thing that always gives me pause with “we rewrote the infrastructure in five months” stories: the hidden cost shows up later. Operating a custom VCS is not just a launch problem. It’s a forever problem. You inherit protocol compatibility, client ergonomics, data corruption edge cases, recovery tooling, and all the boring social contract work that comes from not being git. Anthropic says the system is horizontally scalable and avoids repo maintenance, which is nice, but I’d be very curious what the failure modes look like six months from now, not just what the architecture diagram looks like today. That’s where these projects usually get interesting.
Still, I don’t think this is bluster. It reads like a serious internal adaptation to an AI-heavy workflow, and that’s what makes it worth paying attention to. If Claude keeps shrinking the cost of writing code while leaving source control, CI, and builds mostly untouched, then the bottlenecks really will move downhill. And once enough companies are living in that world, git might not disappear, but it may stop being the thing everyone naturally bends around.
Reference: Redesigning source control at Anthropic
