Git Isn't Broken—the People Committing Code Have Changed

On November 2, OpenAI published a post introducing Pando, an in-house Git server backend. Last month, on the 13th, Anthropic also published a post introducing its in-house source code management system, Scion.

Both companies ran into the same problem: AI agents write code so fast that the systems managing code became the bottleneck for the entire company's development speed. The two companies' solutions point in opposite directions.

First, some background on Git. It is the tool programmers use to manage code versions. Every change is stored as a 'commit' and pushed to the company server; colleagues then fetch from the server. A 'branch' is a parallel draft of the same codebase, where each person changes their own copy and merges back into the mainline when done. Both companies put all of the company's code in a single large repository, an industry practice called a monorepo.

OpenAI's path was to reengineer Git. Engineers and agents still type git push and git pull; only the server was replaced with Pando. The median wait time for pushing code fell by nearly 80%, and it serves nearly 1 PB of code data per day, about 1 million GB.

Anthropic's path was to replace Git. Scion has its own client and server; commits and merges are completed on the server, and its accompanying code review and code search tools were also written in-house. CI automatically builds and tests after every change; pulling code went from minutes to seconds; server CPU and memory usage is only 1/200 of the previous setup.

Neither system is offered externally. OpenAI says it is studying how to make Pando's technology available to users; the Git problems fixed along the way have been submitted upstream to Git, and several have landed in official releases. Anthropic says Scion is only suitable for gigantic code repositories; using it requires replacing code review, search, and CI entirely, so it is hard for other companies to adopt directly. It is therefore only sharing the design ideas, hoping GitHub, GitLab, and the open-source community will absorb the useful parts.

If your team uses GitHub or GitLab, OpenAI's path is closer to you: the improvements go directly into Git, and the toolchain does not need to change. Both companies believe other companies will eventually hit the same problem; Anthropic expects such problems to become more common in the next 6 to 12 months.

Why Git cannot keep up. Commit volume is growing too fast. Using Q1 2024 as the baseline, the number of commits merged into OpenAI's mainline rose to nearly 15x by Q3 2026 and is projected to reach about 25x in Q4. At Anthropic, daily merged changes were about 2,500 in May and exceeded 30,000 in September—more than 12x in four months.

The pressure compounds. An engineer has several changes waiting for testing at once; every push triggers several test jobs that pull the same code.

At OpenAI, starting late last year, both fetching and pushing code slowed down, merges often failed, and reliability at one point dropped below 90%—equivalent to more than one failure in every 10 operations.

Anthropic's mainline history is nearly 100 GB; the compressed working copy exceeds 25 GB; CI alone pulls code about 25 million times a day; full downloads would exceed 600 PB per day. At its peak, it ran several hundred Git mirror servers to spread the load, and they became increasingly hard to maintain.

Anthropic summarized the root cause: Git was designed on the assumption that everyone works offline, so everyone needs a complete repository locally. Now most code pulls come from agents and automated jobs, which are always online; carrying the whole repository around has instead become a burden.

When writing code, don't make everyone queue in one line. When multiple people push at the same time, the server must ensure that each branch's pointer to 'which commit it currently points to' is not corrupted. In Git this pointer is called a ref; you can think of it as a bookmark.

OpenAI evaluated two common approaches, both requiring changes across the entire repository to be serialized into one queue. One is three-phase commit: several servers each store a complete copy of the repository; every push must be approved by a majority of servers through three rounds of back-and-forth confirmation. Once push volume grows, the disks on each server become the first bottleneck. The other is a write-ahead log: all changes are first recorded in a shared ledger and then executed. No matter which branch is changed, writers compete to write to the same ledger. The ledger records too fast, the servers cannot update from it quickly enough, and others wait longer to fetch new code.

Pando's approach is to let each branch manage itself. Pushing branch A and pushing branch B do not wait for each other; only two people pushing the same branch at the same time will conflict. The cost is that when viewing several branches at once, you may see states from different points in time. OpenAI says humans and agents actually care only about the ordering within a single branch.

Anthropic went further: commits are generated directly on the server, with no push step, and each commit records only which files changed. Scion uses as few branches as possible—basically none beyond mainline and release branches—because all servers must agree on branch state, and at scale that becomes troublesome. In the end, both companies simplified moving a bookmark into a single 'compare-and-swap' operation: Pando changes one key, while Scion changes one row in a database.

Anthropic also eliminated global queuing before merging. Traditionally, merging locks the repository and lets changes through one by one after testing. Anthropic says that before tests have even finished, hundreds or thousands of changes have already merged, so queuing is impossible; it therefore switched to running automated tests after merge and before deployment. Changes merged at the same time may conflict, and Claude often fixes conflicts faster than humans can discover them.

When pulling code, don't package a custom bundle for everyone on the spot. A traditional Git server computes a custom compressed pack on the spot for every client that fetches code. Git packs a batch of files together, stores only differences between similar files, and includes only the parts the client lacks. When many clients arrive, CPU and disk cannot keep up. Both companies bypassed this step, using opposite methods.

Pando is like shipping standardized pre-packed boxes: the compressed pack uploaded by the pusher is stored as-is and sent to whoever needs it, so the server does almost no computation. To make each pack usable by anyone, the client packages only against the mainline when pushing: anything already on the mainline is omitted; the pack contains only the files changed on that branch, the corresponding directory listing, and commit records. After compression, the median size is under 20 KB. In the background, small packs are merged level by level into larger packs, so someone who is a few days behind does not have to download tens of thousands of small files. The cost is that clients occasionally download some content they already have.

Scion is like self-service at a supermarket: no compressed packs at all; the client requests whichever file it lacks. Each file is assigned an identifier based on its content; when the content changes, the identifier changes. A file with the same identifier never changes, so any cache layer can answer directly without checking with other servers. Clients can also fetch only the directories they need, or wait until they actually read a file to download it.

Both companies' cache hit rates exceed 99%.

In terms of results, OpenAI's median push wait time fell by nearly 80%; with a small number of CPU cores, it distributes nearly 1 PB per day, with a peak of 57 TB in one hour. In tests on ordinary cloud servers, fetching code can saturate 10 Gbps of network bandwidth.

Anthropic's server CPU and memory usage is 1/200 of the original Git mirror; CI and research jobs fetch code two orders of magnitude faster, about 100x; CI alone saves 25% of CPU.

Both systems were written by AI. Pando went from project kickoff to launch in 10 weeks; the core design came from one engineer; the code was mainly written by agents driven by Codex; several engineers handled deployment; and it began serving production traffic in April this year.

Scion was completed by 7 people in 5 months; during the same period they also built the code review tool Antique and five or six other systems, and completed the overall migration. Anthropic had originally hand-written a program to import Git data into Scion, then had an internal early version of Claude Mythos Preview rewrite it; memory usage dropped to 1/20 and speed increased 4x.

An Anthropic engineer said Claude is already better than they are at writing code; their value lies in owning system design and trade-offs, and often in saying 'no' to Claude. Agents will violate the system's core constraints in order to apply some pattern, and will pile up too much defensive code for imagined risks.

One commenter noted that Google went down the Scion direction long ago. In the 2016 Piper paper, code lived on Spanner; developers used CitC cloud workspaces, and the workspace stored only changed files. At the time there were about 40,000 commits per workday, 24,000 of them from automated systems—the same order of magnitude as Anthropic's 30,000 in September. His judgment is that what is new this time is only speed: Google accumulated that volume over more than a decade, while Anthropic went from 2,500 to 30,000 in four months.

A reply said that keeping the Git protocol and replacing only the server backend is the least-effort choice: clients, CI, and the entire toolchain need not change a single line, and all the pressure that cannot be handled is absorbed on your own side. Others cautioned that switching systems solves throughput, not review. What really gets stuck is that each commit has no verifiable behavior to correspond to: an agent changes 40 files at once, no one can finish reading the diff, and blame breaks down completely. That warning is harder to get around than system selection.