Anthropic replaced git. We run 157 repos at a hundred merges a day — here's what transfers

What they built, in one paragraph

The post is worth reading in full; the short version is this. Merges on Anthropic's monorepo grew from about 2,500 a day in May to over 30,000 a day in September, nearly all of them by agents and jobs that are always online. Git's offline-first model — every client holding history, packfiles negotiated on fetch, refs as global state — became the bottleneck, and the usual workarounds (shallow and partial clones, hundreds of mirrors, blob-stored snapshots) got harder to run as the rate climbed. Their answer was to move almost everything to the server: a changeset is an entry in a write-ahead log listing changed files and content-addressed blobs; commits, rebases and merges happen server-side so there is "nothing to push"; refs are discouraged except for main and release branches; CI asks for diffs over an API instead of checking out; and review examines the intent of a change rather than reading every line. They report a 200× smaller footprint than their old mirroring fleet, cache hit rates above 99%, and checkouts that went from minutes to seconds.

Our scale, measured

Before deciding what transfers we counted. On the day of writing our Gitea organization holds 157 repositories. Over the previous seven days it merged 729 pull requests, about 104 a day, with a peak of 252 on one day. 73% of those merges were made by an AI agent account, the rest by four humans. Our build system clones a repository with a depth of fifty commits in about five seconds; a full build is five to eight minutes, almost all of it compiling and scanning, not fetching.

Two things follow. First, we are two to three orders of magnitude below the point where Scion's core moves pay for themselves. A five-second clone is not a bottleneck, and our repositories are small enough that "no full copy anywhere" would be solving a problem we do not have. Second, the ratio that drove their redesign — agents outnumbering humans as clients — is already ours. The pressure they describe is not about size alone; it is about who is doing the merging, and on that axis we look like them.

Five things that transfer

1. Post-merge verification beats a merge queue

The claim in the post that surprised us most is that they refused a global merge-queue lock. Instead of serializing merges through a queue that runs tests before each one lands, they merge lock-free and rely on post-merge and pre-deploy testing, with automated bisect and revert pipelines to clean up after the rare bad change. Their argument is that global state every server must agree on is a scaling risk, and a queue is exactly that.

We had a merge queue on our roadmap. We are taking it off. At a hundred merges a day across independent repositories, a queue buys almost nothing and adds one more component that can wedge — and we have spent enough of this year unwedging components. What we already run is closer to their model than we had noticed: every push to a default branch builds an image, deploying is a separate explicit promote, and rollback is promoting the previous tag again. The piece we are missing is the automated half: a rule that treats a default branch red for more than a few minutes as an incident, opens the revert, and re-promotes the last green build without waiting for a human to notice. That is now a design item, not a someday.

2. Review the intent, and let the tool know which changes are sensitive

Anthropic's engineers still review every change, but they "examine the intent of the change" rather than reading every line, and their review tool can express semantic approval constraints — separating, for example, a comment-only change from a change to sensitive logic. They also note that adversarial AI review can be too defensive, adding complexity for hypothetical concerns, and that engineers' job increasingly became saying no.

This maps almost exactly onto the review gate we are building. Our design already puts a per-repository policy file in each repo that names sensitive paths and requires a human owner's approval when they change. What the post adds is the idea of change classes: a docs-only or comment-only or tests-only change should not need the same scrutiny as a change to authentication, and the reviewer should classify first and review second. We are adding that classification as the first step of our reviewer, recorded in the single status check that gates the merge. The warning about over-defensive review we will take as given; we have already watched an agent reviewer propose a defence against a threat that could not occur.

3. Source control is an API, not a checkout

Many of Anthropic's CI jobs never clone anything: they ask the server for a diff against a merge base and get on with it. Scion's server exposes history, blame and diffs as RPCs, and their automated bisect and revert pipelines are built on those calls.

We found two live bugs in our own platform that are this gap in disguise. Our pull-request check could not run on two of our manifest repositories because the build system could not check them out — so merges there carried no check at all, and nobody noticed for weeks because the status simply never appeared. And our builds API returned at most a hundred rows per repository with no paging, so the dashboard reading it showed "lower bound" estimates for busy repositories. Neither needs a new source-control system; both need the forge treated as the source of truth and queried through its API. Gitea already exposes contents, diffs and server-side commits; our fix is to make the pull-request check for manifest repositories checkout-free, and to finish the paging.

4. Attribution — the thing the post does not mention

Nowhere in the post do they discuss who made a change: attribution and provenance are not covered. For us it is the first problem, not the last. When 73% of merges come from one shared agent account, the audit trail says "the agent did it" and nothing more — not which person's session, not which host, not which model. This month we moved to per-developer agent identities: each person's agents push and merge as their own restricted accounts, with credentials in the person's own vault path, and the shared account is being retired as hosts switch over. If agents are going to be most of your clients, the forge needs to know which human stands behind each one. We would gently suggest this belongs in the next version of their post.

5. One watcher per component

Their operations model gives each component its own always-on Claude instance watching telemetry and logs, alongside conventional alerts. We arrived at something similar from the other direction: a ranked "things need someone" feed that every agent session subscribes to, plus agent sessions that message each other when one finds a problem in another's area. On the day we wrote this, that is how a wedged build pool and a degraded deployment were both caught and attributed within minutes. The post makes the case for formalizing it — a standing watcher per plane rather than whichever session happens to be online.

Three things we will not do

What we are changing

Three changes, each small enough to ship this month:

1. The merge queue comes off the roadmap; an automated red-branch revert goes on.
2. The reviewer gains change classes — trivial changes pass fast, sensitive paths wait for a human owner.
3. Pull-request checks on manifest repositories run against the forge API with no checkout.

The post's deepest lesson is not architectural. A seven-person team rebuilt source control in five months while throughput grew tenfold, and the engineers' main value became setting constraints and saying no. That is the shape of platform work now: the agents will write the code; the humans decide what must never be allowed to happen. We are a much smaller shop, and that is exactly the part that transfers.