Skip to content
intermac
Journal
Engineering

2 min read

When your tool's core assumptions flip: lessons from Anthropic's custom VCS

Anthropic replaced git with an in-house system called Scion after AI agents made git's offline-first design a liability. The real lesson isn't about version control—it's about recognizing when a tool's foundational assumptions have inverted.

By intermac

The threshold for rebuilding foundational tooling is lower than it used to be—but only if your workload has genuinely crossed an assumption boundary, not just hit a performance limit.

Anthropicʼs post on redesigning source control describes how a seven-person team built Scion, a custom version control system, and migrated their monorepo off git in five months. The scale is extreme: from 2,500 merged changes per day in May 2026 to over 30,000 by September, driven almost entirely by Claude writing code autonomously. Git was the bottleneck.

The real insight isn't "build your own VCS"

Anthropicʼs team tried the standard scaling playbook first: shallow clones, sparse checkouts, promisor remotes, several hundred internal git mirrors. These bought time. But they didnʼt solve the underlying problem—git assumes clients work offline and need a complete copy of the repository. When nearly all your clients are agents that are online by definition, that design actively works against you.

That diagnosis matters more than the solution. The team didnʼt rebuild because git was slow. They rebuilt because a core assumption—distributed, offline-capable clients—had inverted. Scion flips it: the server does the heavy lifting (commits, rebases, blame, history), and clients maintain a bounded local cache, fetching what they need on demand. The result is an infrastructure footprint 200x smaller in CPU and memory than the git mirroring setup it replaced, with CI checkouts dropping from minutes to seconds.

What this means for teams that aren't Anthropic

Almost no one is merging 30,000 changes a day. Anthropic is explicit that Scion is not a suitable replacement for git for general use, and that the economics only make sense at the scale of enormous monorepos or swarms of agents writing code prolifically.

But the reasoning generalizes. Every tool you rely on was designed with assumptions about who uses it and how. When AI coding agents enter a workflow—or any non-human, always-on client—those assumptions can flip quietly before anyone notices. The signal isnʼt

Sources

Tags

  • #source-control
  • #developer-tooling
  • #ai-agents
  • #monorepo
  • #scaling