Anthropic Built Its Own Version Control Because AI Outgrew Git

When the tool meant for human pace meets machine pace

Anthropic has built its own replacement for Git, according to reporting traced back to Simon Willison's writeup of the change. The trigger was not a bug or a security incident. It was volume. The rate of changes landing in the company's codebase climbed sharply, and by May 2026 it was averaging around 2,500 requests per period, a load that conventional version control was not designed to carry.

It is easy to file this under internal tooling and move on. That would be a mistake. Git is one of the most consequential pieces of software ever written, and it is built on a set of assumptions about how code changes that are now being violated in practice.

The assumptions Git was built on

Git's design encodes a belief about human behavior. Changes arrive at a pace a person can look at. A branch represents an intention that lasts long enough to be named. History is precious, so nothing is thrown away. A maintainer can read a diff and form an opinion before merging it.

Every one of those assumptions softens when agents write code.

Agents do not get tired, so they produce changes continuously rather than in workday-sized batches. They do not hold an intention for days, so branches become short-lived enough that naming them is overhead. They generate far more diffs than a human reviewer can meaningfully read, which means the review step that Git's whole workflow is organized around becomes a bottleneck rather than a safeguard.

The result is a system operating well outside its design envelope while everyone insists nothing has changed. The repository still works. The process around it stops meaning what it used to.

What actually breaks first

The naive worry is storage. That turns out to be the least of it. Disk is cheap, and Git compresses well.

The first real casualty is review. A pull request whose diff is 4,000 lines generated by an agent is technically reviewable and practically not. Reviewers do what humans always do under overload: they skim, they trust the summary, they approve. The review survives as a ceremony while losing its function, which is worse than removing it, because the ceremony creates false confidence.

The second casualty is identity. Git history is a record of who decided what and when. When most commits are authored by a model acting on a prompt, the history still has names in it, but the names no longer answer the question history exists to answer. You cannot ask an agent why it chose an approach six weeks ago, because it does not remember, and the commit message was generated by the same system that made the choice.

The third casualty is the branch itself. Branching is cheap in Git and expensive in human attention. If branches multiply faster than anyone can attend to them, you get a backlog of intentions nobody is holding, which is a different failure than a merge conflict and harder to see.

Why a replacement is more than a faster Git

If the problem were throughput, the fix would be a faster server. Anthropic building something new suggests the problem is structural.

A version control system optimized for machine-paced change would look different in specific ways. It would assume that most changes are ephemeral and should be cheap to create and cheap to discard. It would treat the diff as a summary rather than the artifact, and it would attach machine-readable intent to each change so that an agent can find it later without reading the code. It would be built for retrieval, not for archaeology.

It would also need to answer a question Git never had to. Git assumes the interesting artifact is the final state of the code. In an agent-driven workflow, the interesting artifact is often the reasoning that produced a change and the checks that validated it. If those live outside version control, then version control is only recording half the history.

The record-keeping nobody thinks about until they need it

Version control is not only a filing system. It is the substrate for billing, compliance, and incident response. Auditors want to know who changed what and when. Regulated industries want a defensible record that survives a review. Security teams reconstruct timelines from commits.

If the honest answer to those questions becomes "an agent did it, on a branch that no longer exists, and the reasoning lived in a context window that has since been discarded," then the record has a hole in it. Holes in records are precisely what audits are built to find, and a tool that produces them without anyone noticing would be a serious problem long before it became a scandal.

The wider signal

Anthropic is not alone in feeling this pressure, and the smaller versions of the same story are already visible elsewhere. GitHub recently reworked its repo star-history API so that trend data comes back in 24 requests instead of about 2,500, without requiring unbounded database work or exposing individual stargazers. GitHub also shipped a context-aware secret-detection classifier that raised the acceptance rate of real findings by 11.5 percent while cutting median scan time by 86 percent.

Both are responses to the same underlying condition: the volume of code in the world is going up, and the tooling built when humans were the only authors is starting to show its age. Secret detection is a nice illustration. The risk of a leaked credential scales with how much code is being written, so a system that was adequate at human output rates becomes inadequate at agent output rates even if nothing about its design changed.

The part nobody wants to say out loud

There is a version of this story in which AI makes software teams dramatically more productive and the tooling catches up, and everyone is fine.

There is another version in which the volume of generated code outruns the human capacity to understand it, and the industry ends up with repositories that no single person comprehends, held together by tests that nobody wrote and reviews that nobody performed. The tell for that version is not a crash. It is a slow drift where the codebase keeps working and the number of people who understand why keeps falling.

Replacing Git is, in that light, a symptom worth noticing. It means one of the most careful companies in the industry decided that the standard tool had become a liability at exactly the layer where correctness is tracked. That is not a small admission. It is a signal that the infrastructure of software is being asked to change faster than its assumptions can follow.

The practical response for everyone else is unromantic. Measure how much of your code is machine-authored. Watch whether your review step still changes anything. Notice whether your history can still answer why. Those are cheap questions, and the answers will tell you whether you need a new tool or just a new habit.