I know, I know, I’m getting into a habit of posting “Is X dead?” posts but for once, Betteridge’s law doesn’t apply: the answer isn’t “no,” it’s “maybe, for some people.”
A big news story in the last 7 days was that Anthropic replaced Git on its giant monorepo with a brand-new source control system called Scion, built by a small team (and a ton of Claude). It took them about five months to build it and migrate to it. Their stated reason for the move was that Git wasn’t scaling. Their monorepo had gone from 2,500 merges a day in May to over 30,000 in September, and Git wasn’t keeping up.
This caused a big splash in the world of software development, since nearly everybody uses Git for everything, and Anthropic are regarded as being at the forefront of a new world of software development where the work is primarily done by agents. Did they hit a wall the rest of us are about to hit? If so, we’re going to need to build something new, because Scion isn’t open source.
In this post I’m going to dig into what Scion actually is, how and why it’s different from Git, what other people at the bleeding edge are doing, and whether you’re going to need something like Scion yourself.
Build better agents with Arize
Trace, evaluate, and learn. Build agents that work with Arize AX and start tracing your runs today.
Prefer open source? Try Arize Phoenix for self-hosted, open source agent observability.
Scion vs. Git: Why Anthropic changed source control
First a quick recap of how Git works: every time you clone a repo, you are making a complete copy of the repository and all of its history. This allows you to do anything you need with the repo entirely offline. You can commit locally, get everything ship shape, and then push to the server for review. This requires a certain amount of up-front work (downloading a repo can take a long time, as everyone has experienced) in exchange for a very fast local experience thereafter. This works great for human developers working on laptops whose connection might not always be online.
Scion wasn’t built for humans. It was built for a world of agents, working in a different way and importantly at a very different velocity to humans. It was also, crucially, built for the kind of giant monorepo Anthropic uses, which isn’t the way everyone works.
Their monorepo caused the first problem: checking out code had become expensive at CI scale. The main branch’s history was almost 100GB, while a compressed working copy was over 25GB. Anthropic ran roughly 25 million CI checkouts a day, which would have generated more than 600 petabytes of daily Git traffic if every checkout fetched that working copy in full.
They tried shallow clones, they tried sparse checkouts, they tried running hundreds of mirrors of their Git servers, it just couldn’t keep up with them. So Scion does things differently:
- Scion is server side. Questions like who last changed a line, or what the diff between two commits is, get answered by the server instead of by every client computing them from its own copy. Those questions are answerable by making an API call, so the client doesn’t need the tree at all.
- Commits are also made on the server. Every source-history-related change happens server side, so you don’t push anything.
- Checkouts are partial. When a job does need files on disk, it only gets the directories it asks for, and files get fetched as they’re read.
- Branches are discouraged. Every branch is a piece of shared state that all the servers have to agree on, which becomes a scaling problem as volume climbs, so Scion mostly sticks to main and release branches.
Those add up to a dramatic difference from Git. Anthropic says its new setup keeps up with their volume and uses 200x less CPU and memory than the fleet of Git mirrors it replaced. The setup includes Antique, a new system for doing code reviews, which is an interesting point I’ll come back to in a bit.
Anthropic isn’t the first company running into these particular issues, and the ideas in Scion aren’t new. Google’s Piper and Meta’s Sapling have handled huge monorepos with similar tradeoffs for years. But it took Google and Meta tens of thousands of engineers and years to hit this wall; Anthropic is both much smaller and much younger.
So is everybody using lots of agents to write code about to need this?
How Perplexity and GitSwarm use Git to coordinate agents
Anthropic thinks this problem is going to become a generally felt one sometime in the next 6-12 months. But there are other companies in the space who managed to solve similar problems without abandoning Git at all.
Perplexity published the storage design behind its Projects feature the day before Anthropic’s post, and describes it as a Git forge for agents. To be clear, this holds project files for knowledge work, not Perplexity’s own source code, but the problem is the same one: lots of agents, some interactive and some running on schedules, all committing to the same repository at once.
Each agent works in its own short-lived sandbox with a local copy of the files, and submits commits to a service running stock Git on top of S3. If two agents collide, the one that built on an outdated version gets rejected, replays its change on top of the new version, and tries again. Perplexity says fewer than 2% of commits collide like this, though.
This is a solution for lots of agents working at the same time. This doesn’t solve the giant-tree problem: to do that, Perplexity keeps each repo small on purpose and only downloads files if they are needed. They also limit history: once history gets long enough, older commits get squashed into a single snapshot.
GitSwarm, from researchers at Meta and several universities, takes a different approach to coordination. It’s a research system rather than production infrastructure: a swarm of identical agents works on a hard problem by contributing to one shared, branching Git repository. There’s no planner handing out tasks. Each agent looks at what’s already in the repository, decides what to do next, and commits its results, and later agents build on earlier commits. The repository itself is how they coordinate, and it’s ordinary Git.
Which is to say: the problem solved by Scion isn’t the one you get when you have a lot of agents working. It’s the one you get when you have them working on a single giant monorepo. If you don’t have that, Git still works fine.
But is that all Scion is for? No, because Scion wasn’t all that they built.
How AI code review changes source control
I’ve previously written about how agentic coding changes code review and gave a whole talk called The Death of the Code Review: once code is cheap to produce, human review becomes the bottleneck. So another way of looking at Scion is that it’s a solution to the next bottleneck you hit after you solve code review.
Anthropic opened their announcement post about Scion by saying that writing code isn’t their bottleneck any more. Part of how they pulled that off is Scion but another part is Antique, a code review system they built at the same time as they built Scion. Antique can tell a comment only change from a sensitive logic change, so humans only need to review the changes that justify their time. On the Scion codebase itself, engineers now review the intent of each change rather than reading every line. This has significantly displaced traditional code review on Anthropic’s monorepo.
So it seems to me that’s where Anthropic’s scaling problem with Git would have come from anyway, even if they didn’t have a giant tree. With traditional code review gone, merging code became an incredibly frequent operation that would have overwhelmed their infrastructure regardless.
They also had to change how they do merges. At agent scale, hundreds of changes can merge while tests are still running. Anthropic couldn’t make the usual global lock on the merge queue work, so they moved to testing after merge and before deploy, accepting that concurrent changes will sometimes conflict, because Claude can fix those conflicts faster than a human can spot them.
Interestingly, Perplexity ended up in a similar place: they don’t use pull requests at all, because no human reviews each change. They rely on automated checks when a commit is submitted.
Do AI coding agents need a Git replacement?
If you intend to deploy teams of agents to write your code and use automation to review it, which seems to be the way the industry is going, does that mean you’ll need Scion, or only if you have a monorepo? That’s the important question.
Anthropic says Scion isn’t a general replacement for Git. They’re not releasing it as open source, partly for that reason and partly because adopting it would mean replacing your code review, code search, and CI along with it. They say it’s really only necessary if you have a monorepo as big as theirs, which is (thank goodness) not most people.
Instead, Anthropic want to take the ideas back to Git. They’re offering to work with GitHub, GitLab, and the open source community on things like server-side APIs for history and diffs that the Git client could learn to talk to.
How GitHub and Cursor are scaling Git for AI agents
GitHub has already been seeing some of the same problems that Scion solves, and is (somewhat belatedly) acting on them. They published a plan to rebuild their Git infrastructure for agents. Pushes on GitHub grew 4.9x in a year, and GitHub points out that an agent in a tight loop commits after nearly every action, so how fast a single push completes becomes that agent’s speed limit. Their fix keeps Git exactly as it is for users but separates storage from compute on the server: repository data lives in Azure Blob Storage, and lightweight workers answer requests from cache. In internal benchmarks they’re seeing up to 35x higher write throughput. Cursor’s Git host, Origin, made a similar move back in August, storing every push in a log on S3 and treating the repository on disk as a cache.
Notice what GitHub aren’t doing, though: they’re not moving commits to the server or asking clients to give up their full copies. They’re making the server faster at accepting pushes. Whether Git hosts go further and adopt Anthropic’s server-side commits and history queries is still an open question, and it’s not clear whether it’ll be necessary.
Identify your bottleneck before replacing Git
- If you’re still stuck at code review, you need to fix that first. The real vision of the future shown by Scion and Antique isn’t a world of monorepos, but a world where review was solved and a new bottleneck was started.
- If your rate of Git pushes is your bottleneck, you need changes already in flight. This is more people, and likely to grow a lot faster than people who have monorepos. GitHub’s plan may be enough for you, but what you may really need is Antique, not Scion.
- If you have a giant monorepo, god help you. Scion’s not open source and you’re going to need to replicate what it does (Meta’s Sapling is open source, so that might be where to start)
One thing Anthropic built that you can copy today has nothing to do with Git. Their team set up Claude instances that each watch the telemetry and logs of a single Scion component, looking for anything odd, and Anthropic says they catch subtle problems that traditional alerts miss. When changes land at agent speed, you need agents reading what happened, because humans reading dashboards won’t keep up, and that’s what we built Arize AX to do.
So Anthropic has killed Git, but only for the handful of teams with enormous monorepos full of agents. For everyone else, Git is getting rebuilt underneath you. Don’t go rip it out. Put your time into figuring out code review so that you can have the good problem of hitting the next bottleneck.
