My take on Anthropic's Scion: git has to adapt, but not like this

Anthropic has built a good answer to a problem very few of us have. The problem is real, though, and I think git does have to change. I just don't think Scion's answer is the one to copy.

Their write-up on redesigning source control is worth reading in full. Merges to their monorepo went from about 2,500 a day in May to over 30,000 a day by September, because Claude was writing most of the code. Git assumes every clone is a complete copy that might be offline, and at that volume it became the bottleneck. A small team built Scion, a centralised system with always-online clients, and moved the repo across in about five months.

#Where I agree

I work with a very large repo most days, so the diagnosis is familiar. Agents and CI jobs are always online and don't need full history. At size, cloning and checkouts become a daily cost, and the usual fixes (shallow and sparse clones, mirrors) add their own operational weight.

The article's own conclusion is modest. Its authors say the more useful takeaway is bringing these ideas back to git, with server-side operations and better sparse and shallow clones. I'd put my money there too.

#Where I don't

Scion is bespoke, built by a company that makes the models and doesn't have to watch token costs. Seven people and a lot of Claude built it. Most teams can't follow that, and I'd be wary of anyone treating it as a template.

The bigger issue for me is the workflow change. The article says merge queues with global locks don't suit agent-scale development, so they rely on testing after merge and before deploy. They do have automated bisect and revert on top, which is a serious answer. But a trunk that stays green and is always safe to release from is something the industry worked decades for. It gives you release confidence, easy rollbacks and a straight answer to "what's in production?". A team giving that up needs something equally strong in its place.

The hard part underneath is semantic conflicts: two changes that merge cleanly as text and break each other in behaviour. A diff can't see those. You find them by testing the combined result.

#Agents fixing merges won't scale

The tempting answer is to let the AI resolve conflicts as they come. On a small repo that's fine. On a very large, busy one it becomes a treadmill, agents fixing what other agents just broke, with each retry costing time and tokens. I don't think it works as the main strategy, and I haven't seen anything that changes my mind.

What would: evidence that post-merge testing plus automated revert keeps releases boringly safe at that volume, for a team without Anthropic's resources.

I also don't think there's one fix. What a big repo needs depends on how its teams work: how often they merge, how they test, how they ship. My bet is on cheaper checkouts and server-side queries, with the protected, deployable trunk kept exactly where it is.