Rebuild Infra Only After the Bottleneck Moves

As volume grows, the delivery bottleneck shifts from coding to source control, builds, and CI. Measure whether it moved before rebuilding the layer.

Once agents shorten the coding step, the first thing to buckle is usually the engineering infrastructure built for human cadence: source control, builds, CI. Anthropic rebuilt that layer — migrating off git to an in-house system called Scion in five months. The trigger was not that git is bad, but that its design assumptions no longer match the load.

After reading, you should be able to answer:

• How do you tell the bottleneck has moved from coding to infrastructure?
• Which git assumptions invert into liabilities at agent scale?
• What can be ported to existing tools, and what is not worth copying?

Coding is no longer the bottleneck; infrastructure is

Here is a set of Anthropic's self-reported numbers: in May 2026 it merged around 2,500 changes a day; by September, over 30,000 a day. The main branch history alone is almost 100 GB, and a compressed working copy is over 25 GB; CI alone performs about 25 million checkouts a day — naively, over 600 PB of traffic daily. To hold the load they once ran several hundred internal git mirrors at once anthropic-source-control.

Those numbers say one thing: when coding turns from the slow stage into the fast one, the pressure does not disappear, it moves to the next stage. The test-selection service got crushed first (see making verification keep pace), then source control itself. Anthropic's conclusion is that the bottleneck is "all the developer infrastructure built for human scale," not any single tool.

Start with the caveat: this is Anthropic's own internal load, and an outlier in scale. Most teams will not meet this magnitude any time soon — the boundary gets its own section below.

The old assumptions invert into liabilities

Git is decentralized by design: every clone is a complete, self-contained repository that can diff, read history, check blame, and check out any revision offline. For the vast majority of repositories that is right, and it is why git became the standard. But Anthropic found it was in fact using git as a centralized system — one authoritative copy — while nearly all of its clients are agents and CI jobs that are online by definition. So git's best properties start working against it:

• "Clients work offline and need a complete copy": clients are always online and could fetch on demand, instead of each storing a full copy.
• "Every client can be a server" (client-server symmetry): the server is what needs to answer history, blame, merges, and rebases; clients do not need the same capability.
• "Commit locally, then push to share": with agents producing continuously, shared refs and packfile maintenance become a global coordination point whose cost scales with repository size, not change size.

The shape of the judgment is plain: once an assumption runs opposite to actual use, patching on top of it buys less and less time. This is exactly the "the bottleneck moved" point from individual speedup is not organizational speedup — except this time it moved not to a team but to the source-control layer.

Redesign around always-online: sparse checkouts, cheap commits

Scion was designed around the premise that clients are always online, and its principles lock together:

• Client-server asymmetry. The server answers history and blame, creates commits, performs merges and rebases; the client keeps a bounded local object cache, lays out the working copy, and watches the filesystem. It computes very little, and in exchange it stores far less.
• Everything must scale horizontally. Repository data is distributed, and there is no fully materialized copy anywhere, not even on the server; with no packfiles there is no repository maintenance. Caching runs in three tiers — a per-node daemon, a regional cache, and the authoritative server — each with a hit rate above 99% and no long-lived state.
• Commits must be cheap, incremental, and lock-free. The unit is a "changeset," effectively a write-ahead-log entry: it stores only the files changed relative to its first parent, plus content-addressed pointers, so creating a commit costs in proportion to the change size, not the repository size.
• The working copy is optional and sparse by design. When CI needs a diff and its merge base, it just asks the server instead of checking out; when files really must land on disk, the client pays only for what it actually reads.

Most teams need not copy these principles, but one is directly portable: the server does not have to look like the client. A git server can expose richer server-side queries, negotiate per object, and make sparse and shallow compose better. Those are additive improvements that leave the overall model intact.

Cost and boundary: measure before you move

Anthropic drew its own boundary: Scion is not a general git replacement. It only holds for "truly enormous monorepos plus swarms of agents producing continuously"; migrating means replacing the whole development lifecycle (review, search, CI), and those internal components are highly bespoke and hard for others to adopt. Add a token budget that far exceeds any ordinary company's, and the recipe is not very reproducible. Any "someone rebuilt a layer" case has to be read back inside the conditions that made it true.

So the real move is not "rebuild it," but measure first:

1. Where does end-to-end delivery time wait? If the waiting sits in review or integration, rebuilding source control will not make delivery faster; only when source control itself is the explicit limit is rebuilding the layer justified.
2. Can this part stay additive? Start with server-side queries, sparse and virtualized checkouts, and fetch-on-demand; if that is enough, do not tear it down.
3. Once it is done, who proves it was done right? The definition of done has to be checkable, not the sentence "the migration finished."

The human side shifts too. Anthropic's engineers say agents already write code better than they do, but the engineers still supply system-level trade-off judgment — much of the work is saying "no," stopping an agent from violating a core constraint to satisfy some pattern. Review also shifts from "read every line" to "look at the intent of the change." And they admit that at agent scale the industry habit of "a merge queue with a global repository lock" no longer replicates, so they moved focus to post-merge and pre-deploy automated testing.

Whether infrastructure is worth touching does not depend on how old it is; it depends on whether the bottleneck has actually moved here and whether the change can be checked. Measure those two first, then decide whether to touch the layer.