Anthropic's engineering team spent five months migrating its internal monorepo from Git to Scion, a version control system they built in-house.
This also gives AI teams a firsthand experiment report on "software development at the scale of AI agents": once the bottleneck of writing code disappears, the entire development infrastructure has to be re-examined!
Report link:
https://www.anthropic.com/engineering/redesigning-source-control
Why Git no longer fit
Claude-driven coding pushed merges from 2,500 per day in May to over 30,000 per day in September. The main branch history is about 100 GB, and the compressed working copy is 25 GB+. CI alone performs about 25 million checkouts per day; if they pulled everything strictly according to the Git protocol, the theoretical traffic would exceed 600 PB/day. Shallow clones, sparse checkouts, promisor remotes, hundreds of internal mirrors, blob storage seeding... these patches only delayed the collapse: the seeds drifted from the latest commits, and history operations like diff and blame gradually broke down.
Core insight: they never actually needed "distributed"
Anthropic was in fact using Git as a centralized system: clients (agents, CI jobs) are always online. The capabilities Git was designed for offline/distributed scenarios (full local history, complex negotiation protocols, packfiles) are all liabilities here rather than assets. Every part of Scion's design rests on an assumption that inverts Git's default: clients are always online.
From this they derived six principles: clients fetch on demand; the client-server relationship is strictly asymmetric (the server handles history/blame/merge/rebase, while the client only performs bounded caching and file layout); the entire source control system is an API (CI and tools often go directly through RPC, without even creating a local repository); full horizontal scaling (no one materializes a complete repository anywhere); commits are cheap, incremental, and lock-free (in normal flow they don't even touch refs); and working copies are sparse by default and virtualized on demand.
Two pillars of the technical approach
1. Changesets replace commits. A Git commit points to a complete tree; a Scion changeset is a record in a write-ahead log that stores only the list of files changed relative to the first parent plus content-addressed pointers to blob storage. This design makes commit cost scale only with the size of the change, independent of repository size; there are no packfiles, no locks, and no cross-server coordination. Refs still exist but are de-emphasized: moving a ref is just a compare-and-swap on one row in Spanner, fully decoupled from changeset creation. A footnote explains that recording only the first parent is a deliberate trade-off, since under trunk-based development people mainly care about the mainline history.
2. Recursive derived data. Blame, path history, and skip lists over the commit graph are all computed with the same general recursive mechanism: each changeset's value is derived from its parents' values. This brings three benefits: adding a new derived type (such as copy detection or path search) is very cheap; each type can independently choose to compute eagerly or lazily; and the internal structure is completely transparent to clients, so it can be rewritten and optimized at any time.
Layered cache architecture
The client scn negotiation protocol differs entirely from Git's: instead of declaring "what I have," it recursively requests missing trees starting from the root, then requests blobs. Every request is an immutable content-addressed object that any cache layer can serve, which naturally supports resumption and eliminates packfiles. The three tiers are: a per-node scion-daemon, then a regional scion-cache (streaming directly from memory in the client's disk format), then the authoritative scion-servers (reading Spanner/cloud storage). They respond to the same RPCs, but fault domains are strictly isolated between tiers. Results: each cache layer has a hit rate above 99%, infrastructure CPU and memory usage shrank by 200x, checkouts dropped from minutes to seconds (about 100x faster), and CI freed up 25% of its CPU.
The more thought-provoking part: changes in engineering culture
- Seven engineers built Scion, the code review tool Antique, IAM, code search, and about half a dozen other systems in five months, and completed the migration during a 10x growth in merge volume.
- Every engineer on the team admits Claude writes code better than they do, but humans provide system-level judgment. One of the core tasks is saying "no" to Claude, for example stopping an agent from brute-force linearly scanning the commit log for merge-period queries.
- Adversarial review causes agents to over-engineer for hypothetical doubts (in one review, when the reviewer distrusted an internal service, Claude piled on excessive validation), so humans need to pull the direction back. Human review has also shifted from reading line by line to reviewing the intent of the change.
- They abandoned the global repository lock of the merge queue (which cannot be replicated at agent scale) in favor of post-merge and pre-deployment testing, accepting that conflicts will happen, because "Claude resolves conflicts faster than humans can detect them."
- Operations gained "superfans": each component has a Claude agent assigned to a Slack channel that watches telemetry and logs, able to catch subtle new problems that make traditional alerting look one-dimensional.
- There is also a very practical warning: internal token spending "far exceeds the level any other enterprise would realistically be willing to spend."
Positioning and ecosystem implications
Anthropic explicitly says Scion is not a general-purpose Git replacement; it only makes sense for ultra-large monorepos with massive agent throughput, and it must be paired with in-house review, search, and CI. They predict these problems will spread across the industry within 6 to 12 months, so they chose an open-source approach rather than a product. The most compelling line is "a Git server doesn't have to work the way a Git client does": a forge can adopt an entirely new server-side architecture, expose standardized server-side RPCs, improve the negotiation protocol, and make sparse/shallow features composable, all without abandoning the Git model. They say they will work with GitHub, GitLab, and the open-source community.