When AI writes the code, source control becomes the bottleneck

01Beginner

What Anthropic said

In May 2026, Anthropic merged about 2,500 code changes a day. By September it was merging more than 30,000.^[1]

That is at least twelve times as many, and Anthropic says it does not expect the growth to slow. Its explanation is short: “coding is no longer the bottleneck to building systems or doing research.” What is slow now is “all of the developer infrastructure built for human scale: source control, builds, and CI.”^[1] Its post on social media put the same point in one line: it had “become bottlenecked by developer infrastructure built for human (rather than agent) scale.”^[2]

May 2026
about 2,500 a day
September 2026
over 30,000 a day

Code changes merged to Anthropic’s monorepo per day, as the post states them. The post also charts January to September; we show only the two values it gives in words. Anthropic’s own figures, not independently checked.

Fig. 1 — Code changes merged per day to Anthropic’s monorepo. The post also charts January to September; only these two values are stated in its text.

So Anthropic built its own version-control system, called Scion, and moved its main codebase off git in five months. This article walks through what it built, why, and what the post does and does not claim. Anthropic is the company that makes Claude, and this article was itself drafted with help from AI assistants, so read it as a summary of Anthropic’s account, not an independent test.

02Beginner

What source control does

Source control keeps every version of a project’s files, who changed what, and when. It lets many people work on the same code without overwriting each other, and lets you go back if something breaks.

Git, the standard tool, is decentralised. In the post’s words, “every clone is a complete, self-contained repository that can compute diffs, read history and blame, and check out any revision while fully offline.”^[1] That is a strength for most projects: you can work on a plane, and no single server is a point of failure.

A monorepo is one repository holding most or all of a company’s code. Google and Meta famously work this way, and both built their own systems for it. The post names two as prior art: Google’s Piper and Meta’s Sapling.^[1] Google’s engineers have described a “custom-built monolithic source repository” serving tens of thousands of developers,^[5] and Meta describes Sapling as a system it spent ten years building, used for a repository with tens of millions of files.^[6] So big companies leaving stock git for giant code bases is not new. What is new is the reason: agents.

03Intermediate

Where git strained

Anthropic gives its numbers plainly. The history of the main branch alone is almost 100 GB, and a compressed working copy is over 25 GB. It does about 25 million code checkouts a day for continuous integration (CI) alone, before counting developer environments, agent sandboxes and research jobs. Fetched naively, the post says, that would be over 600 petabytes of git traffic a day.^[1]

~100 GB

History of the main branch alone

25 GB+

Compressed working copy

~25 million

Code checkouts a day, for CI alone

Developer environments, agent sandboxes and research jobs are extra

600 PB+

Git traffic a day if fetched naively

Our check: 25 million × 25 GB ≈ 625 PB

All figures are Anthropic’s, from its post. “Naively” means every checkout fetching a full copy.

Fig. 2 — The size of the problem, as Anthropic reports it. The 625 PB check is our own multiplication of the post’s two figures.

Git has answers for big repositories, and Anthropic used them. A partial clone limits how many blobs and trees are downloaded.^[3] A sparse checkout narrows the working tree to a subset of files, chosen by directory or pattern.^[4] Internal mirrors and snapshots go further. At its peak Anthropic ran several hundred mirrors. This “bought us time”, but the setup became harder to run as the merge rate rose.^[1]

1
Shallow clones, sparse checkouts, promisor remotes
Git’s own tools for taking a slice of a repository. Used.
2
Internal git mirrors
Several hundred at the peak. Harder to run as the merge rate rose, and no longer scaled once the repo outgrew a mirror’s disk or memory.
3
Seeds (repository snapshots in blob storage)
Fell further behind the tip of main between refreshes.
4
Partial clones for history queries
Diff and blame took more and more care to keep working.

Anthropic’s account of what it tried before building its own. It says this “bought us time”.

Fig. 3 — What Anthropic says it tried before building something new.

The post’s diagnosis is the interesting part. Anthropic was using git as a centralised system with one authoritative copy, but almost all of its clients were agents and jobs that are online by definition. Git’s offline-first design was working against it.^[1]

What git assumesWhat the workload is

Every clone is a complete repositoryAgents and jobs are online by definition
Works fully offline: diff, history, blame, any revisionNothing ever needs to work offline
Each client can act as a serverOnly one authoritative copy is ever used
Great for most repositoriesStrained at ~100 GB of history and 25M checkouts a day

Paraphrased from the post’s section “Growing our monorepo”.

Fig. 4 — The mismatch, paraphrased from the post.

04Intermediate

Five principles

The post asks a simple question: if source control were designed from the start for clients that are always online, what would it look like? It answers with five principles.^[1]

Principle 1

Clients are always online

Design for a server that is always reachable; clients fetch data when they need it.

Principle 2

Client–server asymmetry

The server answers history, blame, commits, merges and rebases. The client keeps a bounded cache and lays out files.

Principle 3

Everything scales out

Data is distributed; no full copy of the repo exists anywhere, even on the server; no packfiles, no maintenance.

Principle 4

Commits are cheap, incremental, lock-free

Every commit, rebase and merge happens on the server. Cost scales with the change, not the repo. Few refs.

Principle 5

The working copy is optional and sparse

Ask the server for a diff instead of checking out. When files are needed, fetch only what is read.

The post lists these as the principles it set for Scion, and credits Google’s Piper and Meta’s Sapling as prior art.

Fig. 5 — The five design principles of Scion, in short form.

Two have large consequences. First, the server does the thinking. History, blame, merges and rebases are server calls. A CI job that wants the diff against a merge base can ask for it without having a copy of the repository. The post says tools such as its automated bisect and revert pipelines would not be practical at scale without that cheap, programmatic access.^[1]

Second, refs are discouraged. A ref is a pointer to a commit, such as a branch or tag. The post argues that global state every server must agree on is a looming scaling problem, so outside the main ref and release branches, the workflow avoids them.^[1]

05Advanced

How Scion works

In git, a commit points to a tree, a snapshot of the whole directory structure. In Scion, the unit of work is a changeset, an entry in a write-ahead log. It lists the files that changed relative to its first parent, with content-addressed pointers to compressed file contents in blob storage. Changesets are created on the server and are available everywhere immediately.^[1]

Git

Commit

Points to a tree: a snapshot of the whole directory structure
Made locally, then pushed to share
Stored in packfiles that need maintenance

Scion

Changeset

An entry in a write-ahead log
Lists the files changed against the first parent, with content-addressed pointers to compressed contents in blob storage
Created on the server; available everywhere instantly

From the post’s “Data structures” section. The first-parent choice suits trunk-based development in a monorepo, where people mostly care about main-line history.

Fig. 6 — Commit against changeset, per the post’s “Data structures” section.

This structure takes writes at high throughput, the post says, because there are no packfiles to accept, no locking or cross-server coordination, and no refs to move. Scion does support refs, but moving one is a compare-and-swap on a single row in Google’s Spanner database, separate from creating changesets.^[1]

A changeset on its own cannot answer “who last edited this line?” quickly. So Scion builds derived data: dedicated structures for file blame and path history, and skip lists for the commit graph. Each is defined recursively, computed from the same value for the changeset’s parents. That lets Anthropic add new kinds when an operation needs one, choose eager or lazy computation per kind, and change the internals without touching the client.^[1]

Changeset: only what changed

Derived data: built from changesets

File blamePath historySkip lists for the commit graph

Each type is defined recursively: its value for a changeset is computed from its values for that changeset’s parents. It can be computed eagerly or deferred, and the client never sees the internals.

Schematic of the post’s description. Not Anthropic’s own diagram.

Fig. 7 — Changesets and derived data. A schematic of the post’s description, not Anthropic’s diagram.

06Advanced

Checkout as a cache

The part that serves those 25 million daily checkouts is a tiered cache. Each node runs a daemon that stores objects for all the jobs on it. The daemon talks only to cache servers in its region, which stream objects straight from memory in the format the daemon will store. When a cache misses, it asks the authoritative servers, which read from Spanner or cloud storage.^[1]

scn (client)

Asks for trees, then blobs it is missing; talks over a socket to the node’s daemon

scion-daemon

One per node; stores objects for every job on that node; starts from a periodically refreshed snapshot

scion-cache

Regional tree and blob caches; stream objects from memory in the daemon’s on-disk format

scion-server

Authoritative; reads from Spanner or cloud storage; computes derived data on demand

All four tiers answer identical RPCs, so a client does not need to know the cache layout; Anthropic enforces the tiering to keep a failure in one regional cache from reaching the servers. Each tier is reported at over 99% cache hit rate.

Fig. 8 — The checkout tiers, per the post’s “Scaling Scion” section.

The protocol is the other half. Git’s negotiation tells the server what the client already has, so the server works out the difference and sends a pack. Scion’s negotiation “doesn’t tell the server what the client already has”. The client starts from a root tree, requests the trees it is missing, then the blobs. Each request is for one immutable object, so any cache can answer, and there is no single multi-gigabyte response to restart if it fails.^[1]

Git, in the post’s terms

Tell the server what you have

Client and server negotiate what the client already has
Server works out the missing objects and compresses them
One large packfile comes back

Scion

Ask for what you want

Start from a root tree; check the local store
Request missing trees, recursively, then blobs
Every request is for one immutable object, so any cache can answer

Sparse and virtualized checkouts need no special support because the client simply does not ask for trees it does not want. The git side is a simplification of the post’s comparison.

Fig. 9 — Two ways to fetch, simplified from the post.

Sparse and virtualised checkouts, which only materialise files when read, fall out of this design. The client simply does not ask for trees it does not want.^[1]

07Intermediate

What it reports

Anthropic reports that each tier keeps a cache hit rate above 99%, that its Scion infrastructure is “200x smaller” than the git mirror fleet it replaced in CPU and memory, and that CI and research jobs now check out code about two orders of magnitude faster, in seconds rather than minutes. CI alone gained 25% CPU capacity.^[1]

200×

Smaller footprint

CPU and memory, against the git mirror fleet

~100×

Faster checkouts

Seconds rather than minutes, CI and research jobs

25%

CPU capacity won back

In CI alone

99%+

Cache hit rate

At each tier

20×

Less memory

Rewritten ingestion pipeline, same invariants

4×

Faster

Same rewritten ingestion pipeline

All reported by Anthropic. “Two orders of magnitude” is the post’s phrase for the checkout speed-up. The last two figures are for one pipeline, not the whole system.

Fig. 10 — The headline results, all reported by Anthropic and not independently checked.

Two cautions. These are Anthropic’s measurements of its own system against its own earlier setup, so they say little about git in general. And the post gives no raw data, so we can report the claims but not reproduce them.

08Intermediate

Built with Claude

The post is as much about how the system was built. A team of seven people built Scion and Antique, its code-review tool, plus about half a dozen related systems, and fully migrated in five months, while daily merges rose tenfold.^[1] The post says Claude’s coding ability was “both what put us in this situation in the first place and how we were able to quickly build” a way out.

One example: a hand-written first version of the git-to-Scion ingestion pipeline was rewritten by an early internal snapshot of Claude Mythos Preview, and the result used 20 times less memory and ran four times faster while preserving the implicit invariants about ordering and data structures.^[1]

What the model did, per the post

Rewrote the git-to-Scion ingestion prototype
Built simulations of every non-trivial infrastructure interaction, plus fuzzing and rate limiting
Found an ancestry-query optimization that missed one of the indexes
Watched component health in Slack channels (“superfans”)

What the engineers did, per the post

Held the design-level tradeoffs and the scale target
Said “no” when systems brute-forced a lookup by reading the commit log
Steered away from over-engineering driven by adversarial review
Reviewed every change request, for intent rather than every line

A seven-person team built both Scion and the code-review tool Antique, per the post. Its engineers say they now rate Claude as better than themselves at writing code.

Fig. 11 — Who did what, as the post describes the division of labour.

The post is candid about the limits. Its engineers “would now rate Claude as better at writing code than them”, yet “very often, we found that the role of the engineers was to tell Claude ‘no’”. Agents sometimes broke core system constraints to satisfy a pattern that should never have been allowed. Adversarial review was effective but could be myopic and lead to over-engineering. The team reviews every change request for the system, now examining the intent of a change rather than reading every line.^[1]

09Advanced

Is the merge queue dead?

The post questions a standard practice. “A proper merge queue, for example, doesn’t make much sense at agent scale,” it says. If hundreds or thousands of changes can merge while tests run, what does CI mean? Anthropic says it could not replicate the industry-standard global lock on the merge queue, so it invested in post-merge and pre-deploy automated testing. Concurrent changes can conflict, but the post says Claude can typically fix conflicts faster than humans can identify them.^[1]

Human scale

Merge queue with a global lock

Changes line up. Each one is tested against the latest main, then merged. Main stays green, at the cost of waiting.

Agent scale

Test after, fix fast

Hundreds or thousands of changes can merge while tests run. Anthropic says it could not replicate a global-lock queue, so it leans on post-merge and pre-deploy testing and lets agents repair conflicts.

The trade-off the post names: concurrent changes can conflict. Its claim is that Claude can typically fix conflicts faster than humans can identify them. We could not verify that.

Fig. 12 — The trade, in short.

This is the most debatable claim in the post, because it trades a guarantee (main always passes) for speed and relies on repair afterwards. It may suit a company with strong automated testing and pre-deploy checks. It is not a recommendation for a team shipping to customers on every merge.

10Intermediate

What it means for git

The post is explicit that Scion is not for everyone. “Scion is by no means a suitable replacement for git for general use,” it says; the ideas make sense for enormous monorepos with tens of thousands of engineers or swarms of agents. It would also be hard to offer: it diverges from git, so adopters would need their own code review, search and CI.^[1]

Anthropic instead shares ideas it thinks git platforms could adopt, and says it expects the class of problem to become common “over the next six to 12 months”.^[1]

Server-side RPCs for history, blame, merge bases
Git platforms could offer them, perhaps standardized across forges, for the git client to learn to use
Different negotiation protocol
It “doesn’t have to look exactly like it does today”
Novel server architectures
A git server doesn’t have to work the way a git client does
Sparse and shallow features
Can be made to compose well

The post’s suggestions for applying the best parts of Scion to git “without departing from the overall model”. Anthropic says it wants to partner with GitHub, GitLab and the open-source community.

Fig. 13 — Ideas the post suggests for git, without leaving its model.

It also credits the git community with “nearly two decades” of scaling work, and says it wants to partner with GitHub, GitLab and open source.^[1] We saw no statement from those projects at the time of writing, so what, if anything, changes in git itself is open.

11Beginner

What it means for you

Most teams do not have 100 GB of history or 25 million checkouts a day. For them, the practical lesson is smaller and easier to apply.

Stay
A normal-sized repo, a team of people and a few agents
Git as it is. Nothing in the post suggests otherwise.
Tune
A big repo where clones and CI checkouts have become slow
Look at git’s partial clone and sparse checkout first; both are documented and shipped.
Watch
A monorepo with swarms of agents and CI doing tens of millions of checkouts
This is the class the post is about. Expect to need server-side thinking, and watch what git platforms add.
Not available
Anyone wanting Scion itself
The post says it is not a suitable general replacement and is hard to offer in a form others could adopt.

Our reading of the post, not Anthropic’s advice. An illustration.

Fig. 14 — Our reading of where you fall. An illustration, not advice from Anthropic.

Measure before you worry. If CI spends minutes fetching code, find out where. Partial clone and sparse checkout are documented git features and cheap to try.
Ask a server instead of cloning. If a tool only needs “who changed this line?”, a hosting platform’s API can often answer without a local copy.
Review intent, not just lines. As agents write more, reviewers are asked to confirm what a change is for. Better tests and clearer boundaries matter more than reading faster.
Check merge assumptions. A queue that is fine at 10 merges a day may not be at 1,000. Know what you rely on it for.

Needs care
“Anthropic replaced git.”
For its monorepo, yes, in five months. The post says Scion is not a general replacement.
In the post
“Merges went from 2,500 to 30,000 a day.”
Stated in the post: about 2,500 in May, over 30,000 in September 2026.
In the post
“It cut infrastructure 200×.”
Stated, against the git mirror fleet, in CPU and memory. Anthropic’s own measurement.
Partly
“Seven people built it with Claude.”
Stated: seven people built Scion and Antique. The post credits Claude heavily; the exact share of code is not given.
Not in the post
“Others can use Scion.”
Not available. The post explains why and shares ideas instead.

Claims as they circulated on X and in summaries, checked against the post.

Fig. 15 — Claims as they circulated on social media and in summaries, against the post.

The message

Anthropic’s post is a case study from an organisation at the far end of a trend: when AI makes code cheap, the surrounding systems, not the code, set the pace. Its answer, a server-centred system built for always-online agents, suits a very large monorepo and is not on offer. What carries over is the diagnosis. If the tools that surround your code were designed for human speed, expect them to be the next thing that strains.

When code gets cheap, the pipes around it become the product to fix. Anthropic fixed one of them in five months; it says the rest are next.

Quick quiz

Tap a question to check your answer.

Q1What growth in merges did Anthropic report, and over what period?

From about 2,500 code changes a day in May 2026 to over 30,000 a day in September 2026, which is about twelve times, described in the post as more than tenfold.

Q2What assumption of git did Anthropic say worked against it?

That clients work offline and need a complete copy of the repository. Nearly all its clients are agents and jobs that are always online.

Q3What is a changeset in Scion, and how does it differ from a git commit?

An entry in a write-ahead log listing files changed relative to the first parent, with content-addressed pointers to contents. A git commit points to a tree. Changesets are made server-side.

Q4Why can any Scion cache answer a request?

Everything is content-addressed and immutable, and each request is for a specific object, so a cached copy is always correct.

Q5Does Anthropic say other companies should adopt Scion?

No. It says Scion is not a suitable replacement for git for general use and is hard to offer, and shares ideas for git platforms instead.

References

The sources behind this article: original papers, official announcements and documentation. Each link was opened and checked on 14 October 2026; documentation without a fixed date is cited as it read that day.

[1]
Anthropic (Nick G. and the source control team) (13 October 2026). Redesigning source control at Anthropic. Anthropic Engineering.
Announcement · Supports: The primary source: the merge growth, the 100 GB and 25 GB sizes, the principles, Scion’s design, the reported results and what the team learned
[2]
Anthropic (@AnthropicAI) (October 2026). New on our Engineering blog: Creating in-house source control. X.
Announcement · Supports: Anthropic’s own summary post, with the 2,500 and 30,000 figures and the “bottlenecked by developer infrastructure” line
[3]
Git project. partial-clone. Git documentation.
Documentation · Supports: What a partial clone is: limiting the blobs and trees downloaded
[4]
Git project. git-sparse-checkout. Git documentation.
Documentation · Supports: What a sparse checkout is: only a subset of tracked files present in the working tree
[5]
Potvin, R., & Levenberg, J. (2016). Why Google Stores Billions of Lines of Code in a Single Repository. Communications of the ACM, 59, 78–87.
Paper · Supports: Google’s custom-built monolithic repository, the prior art the post names (Piper)
[6]
Goode, D., & Bolin, M. (15 November 2022). Sapling: Source control that’s user-friendly and scalable. Meta Engineering.
Announcement · Supports: Meta’s Sapling: ten years of work, a repository with tens of millions of files

How this article was made

Researched and drafted with the help of AI assistants, checked against the sources above, and published by Mrinal Singh Raja as general information, not professional advice. Facts come from the sources listed and may change, so please check them before relying on them. Spotted a mistake? Tell us and we will correct it. Our editorial standards explain how AI is used here.

Anthropic, Google, Meta, the Git project and X are independent of MSRX; this article is not affiliated with or endorsed by any of them. Anthropic makes Claude, which is among the AI assistants used to draft this article. Quotes are word for word from the linked sources. Facts were checked on 14 October 2026 and may change. All performance figures are Anthropic’s own and were not independently verified.