Anthropic's engineers did not set out to kill Git. They set out to keep shipping, and Git became the thing that would not keep up — that is why "Why Anthropic ditched Git?" sits at #2 on daily.dev Popular this morning (tags #ai-agents #cicd #git, a 15-minute video), and why it matters to anyone running agents against a real repository. In an engineering post published on 13 October 2026, "Redesigning source control at Anthropic", the company describes replacing Git with an in-house system called Scion across its monorepo. The numbers in that post are the reason the story travelled: this is not a complaint about Git being awkward. It is a report about a tool hitting a scaling wall, measured in merges per day.
We run automation for a living — agents and unattended pipelines that touch other people's systems — and our rule, stated on our how we work page, is to automate aggressively while keeping the blast radius small. Source control is where that rule gets tested first, because every agent you add multiplies checkout, merge, and review work. This piece is our reading of the Scion migration: what actually broke, what Scion changed, what it did not change, and — most usefully for teams that will never have Anthropic's scale — what to do instead of building your own version control system.
1. The numbers that forced the move
All figures in this section are Anthropic's own, as reported in its engineering post. Treat them as vendor-reported measurements of one extreme workload, not as benchmarks you should expect on your own repository.
In May 2026, Anthropic reports, its monorepo averaged around 2,500 merged code changes per day. By September 2026, that figure had passed 30,000 per day — roughly a twelvefold increase in four months, or about one merge every three seconds around the clock. The company attributes the jump largely to Claude-written code landing through its agent workflows. Coding, in its framing, stopped being the bottleneck; the developer infrastructure built for human-scale work became the bottleneck instead.
The repository itself compounded the problem. Anthropic puts the main branch's history alone at almost 100 GB, and a compressed working copy at over 25 GB. Continuous integration alone performed on the order of 25 million checkouts per day. Fetched the naive Git way — a full clone per client — that volume would mean hundreds of petabytes of transfer daily. The team's first response was the standard playbook: shallow clones, sparse checkouts, promisor remotes, snapshots in blob storage, and internal Git mirrors. At peak it ran several hundred mirrors. That bought time, in the company's own words, but the mirror fleet got harder to operate as the merge rate climbed, and mirrors kept falling behind the tip of main.
The migration that followed took five months and a team of seven engineers, who built Scion plus a new code review tool called Antique and supporting systems. Anthropic reports the result as a 200-fold smaller infrastructure footprint in CPU and memory than the Git mirror fleet it replaced, and a 25 percent CPU capacity win for CI alone. Those are the kinds of numbers that make a story go viral. They are also numbers that should make a small team suspicious of the obvious conclusion, because they describe the far end of a curve, not the curve itself.
2. What actually broke: three Git assumptions, not Git itself
It is tempting to read this story as "Git is dead for agents". That reading is wrong, and Anthropic's own account does not support it. What broke was a set of assumptions Git was designed around, each of which inverts when most of your committers are machines.
Assumption 1: every client holds the whole repository. Git's great strength is that a clone is a complete, offline-capable repository: it can compute diffs, read history, and check out any revision without a server. That strength is priced per client. When your clients are a handful of humans, the price is trivial. When your clients are thousands of agent sandboxes and CI jobs spinning up every minute, you pay the price thousands of times a day — in disk, in transfer, and in time spent waiting for a checkout before any useful work starts. A 25 GB working copy is an annoyance for one developer. Multiplied by 25 million checkouts a day, it is an infrastructure budget line.
Assumption 2: clients are mostly offline, or at least intermittently connected. Git's distributed design exists so a developer on a plane can commit, branch, and read history. Anthropic's clients were the opposite: agents and automated jobs that are always online, working against one source of truth, in a company that — like most companies — already used Git as a centralized system in practice, with one canonical remote. Paying the full-clone price to preserve offline capability that nobody used was, for them, pure overhead. This is the key inversion in the story: the feature that made Git win for humans was the feature that cost the most for agents.
Assumption 3: merges are rare enough that conflicts are exceptional. Human teams merge a few times a day per developer, and a conflict is an event a person resolves by reading a diff. Agent fleets merge continuously, often to the same files, and a conflict that a human resolves in ten minutes is a conflict that blocks an agent that has no judgement to apply and no patience to wait. At 30,000 merges a day, "exceptional" stops being a meaningful category. Merge throughput, not merge correctness in the individual case, becomes the system property you have to design for. Our earlier piece on Git for AI agent teams made the same point from the other side: when most commits are not human, branching, review, and provenance have to be designed as a system, not left as habits.
Notice what did not break. Git's data model — content-addressed objects, immutable history, cryptographic integrity of the object graph — did not fail. Its distribution model and its client-side cost model failed, at a specific scale, for a specific client mix. That distinction decides everything that follows.
3. What Scion actually is
Scion is server-centric where Git is client-centric. Commits, rebases, merges, blame, and history queries happen on the server; clients keep a bounded local cache and track local edits. The unit of work is a "changeset" stored in a write-ahead log, with file contents in immutable, content-addressed blob storage. Refs are discouraged except for main and release branches. CI jobs that only need to answer a question about the code — what changed, who touched this line, what does this revision contain — can often do it through an API without a local clone at all, and checkouts are sparse and virtualized, fetching files as they are read rather than up front.
Two facts about Scion matter more than its architecture, and both are routinely dropped from summaries. First, it is not open source and not available to anyone outside Anthropic. The company says plainly that it is tuned to its own monorepo and workflow and is, in its words, by no means a suitable replacement for Git for general use. If a summary tells you to "switch to Scion", it has not read the post. Second, Anthropic did not only replace version control. It rebuilt the review surface alongside it, with Antique, a code review tool that supports semantic constraints on approvals — treating, for example, comment-only changes differently from sensitive logic changes — so reviewers examine the intent of a change rather than reading every line. Humans still review every change, on the company's account; what changed is what the review is for.
That second point is the one most worth stealing. The bottleneck at agent scale is rarely just the version control system. It is the whole landing path: checkout, merge, test, review, land. Speeding up checkouts while leaving review as a line-by-line human gate just moves the queue. Anthropic rebuilt the gate too, and any team copying only the version control half of the story will be disappointed by the result.
4. The honest translation: what this means at your scale
Here is the part of the story that applies to a team of five, or fifty, or a solo operator running a fleet of agents against a handful of repositories. You almost certainly do not need a new version control system. You need to stop paying Git's full price per client, and you need a landing path that does not require a human to be the merge queue.
Work through this ladder in order, and stop at the first rung that removes the pain. Each rung is cheaper than the next, and most teams never need to pass rung three.
Rung 1: measure the checkout, not the commit. Before changing any tooling, measure what your agents actually spend time on. Time a fresh clone, a checkout in CI, and a rebase onto a moving main, and log how many of those happen per day. If a checkout takes 40 seconds and you do 200 a day, that is two hours of wall-clock agent time — annoying, but not a reason to redesign anything. If it takes 10 minutes and you do 2,000 a day, you have a real budget line and a case for rung 2. Teams that skip measurement tend to rebuild their toolchain to fix a problem they have not quantified, which is how a week disappears.
Rung 2: pay for only the files you need. Git already ships the tools Anthropic's mirror fleet was approximating, and they are one command each. A partial clone with a blob filter plus sparse checkout is the single highest-value change for agent sandboxes and CI:
# Clone history and trees, but fetch file contents on demand.
git clone --filter=blob:none --no-checkout https://example.com/org/repo.git
cd repo
git sparse-checkout set src/ pipelines/
git checkout main
This keeps the repository metadata local — so history, blame, and diffs still work — while file contents arrive only for the directories the job touches. For agents that work in one service of a monorepo, that is usually a 10x or better reduction in checkout cost, with zero change to the hosting, the protocol, or the review flow. The trade-off is real and worth naming: commands that need a file outside the sparse set will fetch it on demand, so a job that wanders across the whole tree will pay fetch latency repeatedly. Scope the sparse set to the job, not to the repository, and measure again.
Rung 3: give each agent its own worktree and a small changeset. The other half of agent-scale Git pain is contention: several agents on one checkout, or one agent rebasing a day-old branch onto a main that moved a hundred times. The fix is boring and it works: one worktree per agent task, short-lived branches, small changesets, and a rebase onto main immediately before landing, not hours before. In practice:
# One isolated checkout per agent task, sharing one object store.
git worktree add ../task-1423 -b task/1423 main
cd ../task-1423
# ... agent works, commits, pushes ...
git worktree remove --force ../task-1423
Worktrees share the object database, so the tenth agent's checkout costs almost nothing in disk. Combined with a rule that a changeset lands or is rebased within the hour — never left to rot for a day — this removes most of the conflict herd without any new software. This is also where our event-driven pipelines lesson applies: retries and replays need idempotency and a dead-letter path. An agent whose rebase fails three times should land in a queue a human looks at, not loop forever burning CI.
Rung 4: change the client or the server, not the protocol. If rungs 1–3 are not enough — your repository is genuinely huge, or your merge rate is genuinely in the thousands per day — the next step is still not building a VCS. It is swapping one layer while keeping Git in the path. Sapling and Jujutsu replace the client with a model designed for stacked changes and fast operations on large repositories, while still speaking Git underneath. Mononoke replaces the server with a scalable backend, again while speaking Git to clients. Each changes one layer and keeps the ecosystem — hosting, CI, review tooling, deploy pipelines — intact. That layer-by-layer property is exactly what Scion gave up, and it is why Scion only made sense inside one company that could rebuild every layer at once.
Rung 5: build your own system. This rung exists for completeness. It is justified when your merge rate, repository size, and client mix are all simultaneously off the charts, you can staff a dedicated team for years, and you accept that you will also rebuild review, search, access control, and CI integration. Anthropic's five-month, seven-engineer build — with Claude itself doing much of the implementation work — is the optimistic version of this rung. For everyone else, it is a warning, not a template.
| Symptom you actually see | Cheapest fix that usually works | Escalate when |
|---|---|---|
| CI checkout takes minutes, agents idle waiting | Partial clone + sparse checkout scoped to the job | Checkout still dominates after scoping, or jobs touch the whole tree |
| Agents conflict on the same files daily | One worktree per task, small changesets, rebase just before landing | Conflicts persist with small changesets — the contention is in the code layout, not the tooling |
| Main goes red after agent merges | Land queue: rebase + test on exact tip before landing, replay on move | Queue wait exceeds your delivery target — then the fix is smaller changes, not a faster queue |
| Review queue is the bottleneck, not merges | Semantic review rules: auto-approve comment-only and generated-code churn, human review for logic | Reviewers still read every line — that is a policy problem, not a tooling problem |
| Mirror or cache fleet costs more than the CI it serves | Stop mirroring; sparse checkouts against one canonical remote | Single remote cannot serve peak checkout rate — measure this before assuming it |
5. The review lesson, restated
If there is one idea from the Scion story worth carrying into a small team's Monday meeting, it is not server-centric version control. It is that review must change when authorship changes. A human author writes a change and a human reviewer reads it; the unit of review is the diff. An agent fleet writes hundreds of changes and a human reviewer cannot read them all, so the unit of review has to become the intent: what was this change for, what did the tests prove, what class of change is it, and what would have to be true for it to be wrong? That is what Antique's semantic constraints are for, and it is a design a small team can approximate today without any new software: label changes by class (generated, mechanical, logic), set approval rules per class, require the test evidence in the change description, and let humans spend their attention where the class says the risk is. The teams that do this find their review queue shrinks. The teams that do not find that their agents simply learn to wait.
6. What not to do
Three failure modes show up every time a story like this goes viral, and all three are worth naming because they cost real weeks. First, do not announce a migration off Git. You do not have Anthropic's problem, and a migration announcement is a promise to rebuild your review, CI, and deploy tooling for a benefit you have not measured. Second, do not confuse a vendor's benchmark with your bottleneck. A 200-fold footprint reduction on a several-hundred-mirror fleet says nothing about a repository with three mirrors or none. Third, do not let agents pick the tooling. An agent fleet that chooses its own version control will choose whatever minimizes its own checkout time in the moment, which is how you end up with five partial solutions and no canonical history. Tooling choices stay human decisions, for the same reason deploy decisions do: the blast radius is the whole team's history.
FAQ
Should my team switch off Git because Anthropic did?
No. Anthropic replaced Git for one monorepo at 30,000 merges a day with a 100 GB history, and says Scion is not a general replacement for Git. If your merge rate and repository size are orders of magnitude smaller — and they almost certainly are — the Git-side fixes in section 4 will remove the pain at a fraction of the cost.
Is Scion open source? Can I try it?
No. It is an internal Anthropic system and has not been released. The usable output of the story is the design: server-side operations, changesets in a write-ahead log, sparse and virtualized checkouts, and semantic review rules.
What is the single highest-value change for agent checkouts?
Partial clone with --filter=blob:none plus a sparse checkout scoped to the directories the job touches. It keeps history and blame working while fetching file contents on demand, and it requires no change to hosting or review tooling.
What if agents keep conflicting on the same files?
That is usually a work-splitting problem, not a version control problem. Give each agent its own worktree, keep changesets small, rebase just before landing, and put repeatedly failing rebases in a human-reviewed queue instead of letting them loop. If conflicts persist with small changesets, the code layout itself needs splitting.
Does faster version control fix slow review?
No — it moves the queue. If humans still read every line of agent-written code, review becomes the bottleneck the moment checkouts get fast. Change the unit of review to intent and change class, with approval rules per class, and require test evidence in the change description.
References
- Anthropic Engineering, "Redesigning source control at Anthropic" (13 October 2026): https://www.anthropic.com/engineering/redesigning-source-control
- Git documentation, Partial clone and sparse checkout: https://git-scm.com/docs/partial-clone and https://git-scm.com/docs/git-sparse-checkout
- Sapling (open-source scalable version control client): https://sapling-scm.com/
- Jujutsu (open-source version control system with a Git backend): https://jj-vcs.github.io/jj/
- Meta, Mononoke (scalable Git server): https://github.com/facebookincubator/mononoke
- Botslave, "Git for AI Agent Teams: Branching, Review and Provenance When Most Commits Aren't Human": https://botslave.com/blog/git-for-ai-agent-teams
- Botslave, "Event-Driven Pipelines Fail in Five Predictable Ways — and How to Design Against Them": https://botslave.com/blog/event-driven-pipeline-failure-modes
- Botslave, "How we work": https://botslave.com/how-we-work
Originally published on botslave.com. Botslave is an automation studio — see what we build and how we work.
Top comments (0)