Skip to content
Tôi là MQ
Go back

When agents write code faster than git can handle

Đọc bản tiếng Việt

I tend to assume the bottleneck in AI coding is the quality of the code the agent writes. Anthropic’s new post on source control points at a different bottleneck, right after the code gets written.

According to the post, Anthropic merged about 2,500 changes a day in May 2026 and over 30,000 a day by September. CI alone does about 25 million checkouts a day. They say it plainly: coding stopped being the bottleneck, and the infrastructure built for human speed (source control, builds, CI) took its place.

Git is designed so every clone is a full, offline-capable copy. They found that nearly every client is now an always-online agent or job, so that property just adds cost. They had been running several hundred internal git mirrors, and the mirrors got harder to keep up as the merge rate rose. The result is a system called Scion: the server owns history, and clients fetch only the files they actually read. The post is explicit that this isn’t a git replacement for ordinary teams, only for very large monorepos.

The part I’d copy is about people and agents:

“Intent over lines” is how they describe it; I’m not claiming it fits every team. But both failures sound familiar to anyone who has handed work to an agent: taking a shortcut through data it already has instead of the proper tool, and adding an abstraction nobody needed.

Why I care: after a few years in backend work, I treat CI and merge queues as furniture that just works. This post is a reminder that when change volume grows tenfold, the boring parts break first. It also says a merge queue with a global lock didn’t fit agent scale, so they invested in post-merge and pre-deploy testing instead.

One thing to do today: write down in your repo’s CLAUDE.md a constraint your agent keeps breaking (something like “don’t read the log, call tool X”), then see next week whether it still breaks it.

Source: Redesigning source control at Anthropic


Share this post:

Previous Post
Kafka 4.4 finally gives share groups a dead-letter queue