Is git our bottleneck? Anthropic's source-control post, read from a small agent shop
· Christoph Heuwieser
On 13 October Anthropic's engineering blog published "Redesigning source control at Anthropic". Its premise will sound familiar to anyone who builds software with agents: writing code is no longer the slow part. What slows things down is infrastructure that was designed around people. Anthropic's numbers are extreme. They went from "around 2,500 code changes merged per day" in May to "over 30,000 per day" in September, and they moved their monorepo off git onto an in-house system called Scion.
a4sx is built mostly by Claude Code sessions working in parallel. We are nowhere near Anthropic's scale, and our repository is ordinary git on GitHub. So we asked a narrower question. Is git the bottleneck in our own build and release loop? And would the post change anything for a normal team on a CI system such as Azure DevOps?
My suspicion going in was that git may well be a bottleneck already, but that without an alternative as easy to adopt as GitHub, it is hard to even try one. Here is what our own numbers say.
What the post claims, and what it doesn't
Most of Scion is about scale. The post describes a main-branch history of "almost 100 GB" and, at the peak, "several hundred internal git mirrors". Their answer is a server that does the heavy work (history, blame, merges, rebases), clients that are always online and fetch only what they need, and changesets in a log instead of snapshots. A team of seven built Scion and a review tool called Antique and migrated in five months. They report checkouts "two orders of magnitude faster", an infrastructure footprint "200x smaller" than their old mirroring, and "a 25% CPU capacity win" in CI.
The authors are candid about the limits. "Scion is by no means a suitable replacement for git for general use." The ideas "really only make sense for truly enormous monorepos", and adopting a system like it means companies "would need to migrate every piece of the development lifecycle". They would rather see the ideas land in git and its hosts: "A git server doesn't have to work the same way as a git client does." They credit Google's Piper and Meta's Sapling, and its server Mononoke, as prior art.
Two smaller points matter more to a team like ours. On landing code: "A proper merge queue, for example, doesn't make much sense at agent scale." They could not replicate "the industry standard of a global repository lock on the merge queue" and instead "invested in post-merge and pre-deploy automated testing". On review: reviewers "now examine the intent of the change as opposed to reading every line of code", and their tool "can express complex semantic constraints on approvals".
How we build and release
Several Claude Code sessions write code at the same time, each in its own git worktree. Follow-up work is often a stacked pull request on top of an earlier one. Each PR runs the tests its change affects, plus a fast core. The full suite, about 33,000 tests, runs once per release on the bundle of merged PRs.
A separate session reviews every PR. Its verdict is a single line bound to one exact commit, VERDICT: SHIP head= followed by the full commit hash, and a PR merges only if its head still matches that hash. The release cut builds a manifest that lists every merged PR together with the verdict for the head that was merged. If one is missing, the release is refused.
Releases go out in two scheduled windows a day, at 05:00 and 17:00 UTC. Each release goes to staging first. Production then gets the identical image, checked by a content hash and recorded in an append-only ledger.
Where the time actually goes
From 12 to 17 October we merged 131 pull requests and shipped 17 releases. The median PR was open for about nine hours. Writing the PRs was not the slow part. Landing them was.
- Re-reviews with little new to review. Across one stretch of about 120 PRs, reviewers posted 229 verdicts. 22 of them covered a change whose only new commit was a merge of the target branch. Where the merge was clean, the reviewer's job was to redo it and confirm the tree came out identical; at least 10 of the 22 had conflicts that needed a real second look.
- Deferrals inside a window. In four of five consecutive scheduled windows, between three and eight PRs were held back because an earlier merge in the same window had made them conflict.
- One morning in detail. In the 05:00 UTC window on 16 October, two billing PRs were deferred after the merges ahead of them. Three PRs stacked on them went too. One of the two already contained every commit of a PR merged minutes earlier. Afterwards one of them merged cleanly and the other had three conflict hunks. All five needed new heads, new test runs and new verdicts, and all five waited twelve hours for the next window.
- One shared test lock. Heavy test runs on our build machine queue for a single lock. Across 40 runs in one 25-hour stretch, the tests themselves took a median of 4.5 minutes; the median wall time was 14.
- Hand-numbered versions. Our command-line tool's version number was bumped inside each PR, so four PRs in a row, two of them stacked, each claimed the next number by hand, and another PR conflicted on exactly that line.
What a typical CI team sees
Take a team on Azure DevOps. Its branch policies already offer what we do by hand. A policy can "Reset all approval votes" whenever the source branch changes. A build-validation result can expire "Immediately when" the target branch is updated. Microsoft's own docs warn that "Teams working in busy development branches might find it disruptive to wait for a build every time the branch updates."
For most human teams the branch is not that busy. People write a few PRs a day, so resetting votes and rebuilding costs little. Their constraints are review time, build-agent queues and flaky tests. Git is not one of them, and a Scion would change little for them.
Our profile is the reverse. Authors and reviewers work at machine speed. What is left is serialisation: every move of the target branch produces a new commit hash, and we tied approval to commit hashes.
So, is git the bottleneck?
Partly, and mostly through how we use it.
Git's storage and protocol cost us nothing we can measure. Clone and fetch time never show up in our data. What hurts is git's notion of identity. A change is a snapshot plus its ancestry, so a clean merge of the target branch turns "the same change" into a new commit. We chose to bind review to commits, and every one of the costs above follows from that choice or from others we made on top of git: two windows, deep stacks, one test lock.
That makes the first half of my suspicion only half right. The friction is real, but it sits in the landing model, not in git itself. The second half holds. Anthropic built its own review tool, code search and access controls before its new system was usable, and nothing comparable exists as a hosted service. A small team can't go that way, and fortunately it doesn't need to.
Anthropic's changeset and approval model points at the fix: approve the change, and let a machine decide whether a new base still preserves it. All of it can be done on git and GitHub today:
- Carry a verdict forward. When a merge is clean and the PR's patch-id is unchanged, the old verdict still holds. When there are conflicts, review only the resolution.
- Bind approval to the change, not the commit, the way Gerrit change IDs do. Jujutsu gives every change a stable ID that a review could bind to.
- Land each window as a small queue tested at its tip, instead of deferring PRs that went stale during the window. GitHub's merge queue does this for human-scale teams.
- Assign version numbers at release time, as we already do for the service itself, not in each PR.
- Treat the release cut as the one full test run, with post-merge and pre-deploy checks as the safety net, which is where Anthropic landed too.
One caution. One of our release cuts failed because two PRs that git merged without complaint collided in a shared test fixture. No source-control design prevents that. Only testing after the merge catches it.
What we're doing next
The post is right that agent-scale development moves the bottleneck from writing to landing. For us, the change worth making is the landing model, not the storage engine, and we can start on git this week. We'll report back with the numbers once we have.
a4sx is an exchange for AI coding-agent sessions: publish, share and continue real work, dead ends included.