TL;DR

Git won because humans were offline: laptops, forks, flaky networks. Agents are never offline. Anthropic’s new Scion system, which replaced git for its monorepo after merges jumped from ~2,500 to 30,000+ a day, is a centralized, server-authoritative, virtualized-checkout VCS. If you ran ClearCase or Perforce, you’ve seen this movie. The design is sound. The bill that came with it last time — a server you can’t live without and a team to run it — is coming back too.

Originally published at portfolio.hagzag.com.

I Used to Mount My Source Code

My first serious source control job wasn’t git clone. It was writing a ClearCase config spec, starting a dynamic view, and watching files appear in an MVFS mount as I opened them. Nothing lived on my disk until I read it. The VOB server knew everything; my workstation knew almost nothing.

Then came Perforce, with its server-tracked “have list” and numbered atomic changelists. Then SVN, which made centralized cheap. Then, for the last decade, git — and I spent a good part of those years migrating teams away from everything above.

So when Anthropic published how it redesigned source control this week, my first reaction wasn’t “new”. It was déjà vu.

What Anthropic Actually Built

The numbers first, because they’re the reason any of this exists (all of them Anthropic’s own, unverified externally):

  • Merges went from ~2,500/day in May 2026 to 30,000+/day by September.
  • Main branch history is ~100 GB; CI does ~25 million checkouts a day.
  • A naive git fetch at that rate would be, by their estimate, 600+ PB of traffic daily.

Shallow clones, sparse checkout, and several hundred internal mirrors bought time, then became the problem. So seven people built Scion and migrated in five months. Its design principles read like a list of things git chose not to do:

  • Clients are always online. Data is fetched on demand; there is no full copy anywhere, not even on the server.
  • The server does the work. History, blame, merges, and rebases are server-side. The client holds a bounded cache.
  • Source control is an API. Many CI jobs never check out at all; they query.
  • Commits cost what the change costs, not what the repo costs.

Their key line: git is decentralized, but nearly everyone used it as a centralized system. With agents, the offline-first design became a scaling liability.

I’ve Seen This Architecture Before

Put the old tools side by side with the new one and the shape is familiar:

ClearCasePerforceScion
Source of truthCentral VOBsCentral serverCentral, Spanner-backed
Working copyMVFS dynamic views, materialized on readServer-tracked workspaceVirtualized / sparse / none
Unit of changePer-file versionsAtomic changelistChangeset in a write-ahead log
Scale-outMultiSite replicasProxy / edge serversRegional caches (99%+ hit rate)
Access controlVOB / element ACLsPath-based p4 protectDirectory-level IAM
Build reuseclearmake winkin—API-driven CI, no checkout

Dynamic views were virtualized checkouts twenty-five years early. Winkin — reusing a build artifact someone else already produced from identical inputs — was content-addressed build caching before we called it that. Perforce protections gave us path-level permissions inside one huge depot.

What Scion keeps from git matters just as much: content-addressed storage, cheap commits, and no global locks. It’s not ClearCase reborn. It’s the centralized model rebuilt on what git taught us about data structures.

Why Distributed Won — and Why That Reason Is Gone

We left centralized systems for real reasons. The server was a single point of failure. Branching was expensive and political. You couldn’t work on a plane. Open source needed forks that didn’t ask anyone’s permission.

Every one of those reasons is about humans: people disconnected, people distributed across organizations, people waiting on a slow server.

An agent fleet has none of those properties. It runs in a datacenter next to the server. It is never on a plane. It doesn’t fork your company’s monorepo to start a rival project. What it does is check out, change, test, and merge — tens of thousands of times a day. For that workload, carrying a full copy of history on every client is pure cost.

That’s the core of this post: the assumption that justified git was about who the developer is. Change the developer, and the assumption goes with it.

What Comes Back With It

Here’s the part the hype skips. Centralization brought specific pain, and I remember all of it:

  • The server becomes the company. When the VOB server was sick, nobody worked. Scion’s tiered caches are designed to limit this, but “no full copy anywhere” also means no full copy to fall back on.
  • You need a team for it. We had VOB admins; Anthropic needed seven engineers and a five-month migration. For a company with Anthropic’s budget, fine. For a 60-person ISV, that’s the entire platform group.
  • Lock-in moves from vendor to architecture. Scion won’t be open-sourced. Anthropic says it wants git hosts to adopt server-side RPCs, and that’s the hopeful path. Until then, “centralized and API-first” means your forge’s API.
  • Testing moves after the merge. Anthropic dropped a global merge queue: hundreds of changes land while tests run, so they test after merge and gate before deploy. That’s a reasonable engineering call — and a governance conversation I’ll come back to in Part 2.

Is This Your Problem Yet?

Probably not at 30,000 merges a day. Anthropic itself says git remains right for most repositories, and it expects these scaling problems to become common within six to twelve months — a prediction worth watching, not assuming.

But the direction is your problem now. If your agents spend more time cloning than thinking, if CI checkouts dominate your bill, if a policy change means a hundred merge requests — you’re already on the curve. The question isn’t whether to build your own Scion. It’s how your repository layout should change when the main reader of your code is an agent.

That’s where my long-held poly-repo convictions start to crack. Part 2: Mono for Context, Poly for Boundaries.