Writing

Why Git infrastructure had to change for agent-scale development

I keep coming back to a bank branch with one teller line handling every deposit. Human customers trickle in one or two at a time, so the fact that the teller serializes each transaction is not a visible problem. The line stays short, and nobody measures the microseconds spent waiting behind someone else. Replace those humans with hundreds of autonomous agents doing small deposits around the clock, and the workload changes shape. Now the teller window—checking IDs, validating balances, updating the ledger in one locked transaction—is the bottleneck. Every deposit must still pass through that single point, no matter how small, and the queue builds far faster than any human teller can clear it.

You don't make that line faster by adding more tellers behind the same glass; you move the deposit intake to an ATM network that accepts cash asynchronously, drops it into a vault, and reconciles later.

That's the shape of GitHub's Git infrastructure rebuild for agent-scale development. The old architecture had too much coordination on every push, making each one wait for a safe moment to proceed. The new design minimizes coordination during pushes, moves heavy maintenance off the serving path, and decouples storage from compute by using Azure Blob Storage for durability. Instead of every push contending for the same lock, writes can land in durable object storage while compute resources handle serving independently.

Decoupling storage from compute is the core shift. In the old model, storage and serving were tied together closely enough that scaling one meant scaling the other, and maintenance work could contend with user traffic. Under the new design, Azure Blob Storage provides durable object storage, while the serving layer can scale independently based on demand. Heavy maintenance no longer shares the request path with user traffic, so a push does not have to wait for housekeeping to finish before it can be acknowledged. Read capacity scales independently from write capacity, because the storage layer is no longer a single coupling point for every operation.

GitHub's internal benchmarks show up to 35x higher write throughput with the new architecture. That number matters less as a precise figure and more as a signal: the bottleneck was coordination, not raw storage or compute. Removing that bottleneck lets throughput climb by an order of magnitude or more. For a platform that hosts many of the world's repositories, that is the difference between tolerating the occasional burst of writes from a few agents and absorbing a steady stream of them without degrading.

For anyone letting coding agents touch real repositories, this change is immediately practical. Agents tend to make many small, frequent pushes rather than a few large ones. The old coordination-heavy path turned that pattern into noisy concurrent writes, where each push competed with the others and sometimes with background maintenance. The new path doesn't punish parallelism. It treats concurrent writes as normal traffic, the way an ATM network treats cash deposits asynchronously instead of forcing everyone into a single teller line. If you are building tools or workflows that assume Git can handle this kind of load, the architecture underneath now gives you room to stop worrying about write contention and start thinking about what agents should do next. The full engineering write-up is on the GitHub blog.

Originally covered at github.blog ↗