Anthropic published a frank article about throwing out Git entirely and building a custom version control system called Scion. The reason? Their neural networks write code so fast that classic Git physically choked, shuffling petabytes of data back and forth. From 2,500 to 30,000 merges a day, a team of 7 people writing a new VCS, a review tool, and a search engine in 5 months with Claude.<\/p>\n
<\/p>\n
I have been in IT development and infrastructure management since the early 2000s. I remember the painful transition from Subversion and CVS to Git, the wars over monorepos in big tech, and the hundreds of hours burned on CI\/CD optimization. So when a company publicly announces it replaced Git in five months, my reaction is not enthusiasm. It is a habit of reading between the lines.<\/p>\n
And here is the main reason I am writing this. People are going to drag this into their "me and my hamsters" sized projects. For the next few months, Scion will become the industry flagship. It will be quoted at every other meetup, and under the banner "Anthropic does it this way," uncontrolled technical debt will roll into hundreds of repositories disguised as a revolution. So let us look at this case through the eyes of someone who has seen dozens of "revolutionary" systems burn under the weight of their own tech debt. A few very inconvenient and provocative questions come to mind.<\/p>\n
Anthropic proudly declares: "We realized agents are always online, so we made the server authoritative, dropped full history on the client, and fetch files on demand."<\/p>\n
Great, guys, you literally restated the concept of Perforce from the 1990s or Google Piper from the 2000s.<\/p>\n
Git's defining achievement is its decentralization and developer autonomy. Anthropic claims autonomy is no longer needed because "agents are always online." But turning a VCS into a centralized client-server service with a heavy Spanner backend and cloud caches is not a step into the future. It is a 20-year regression, just buried under an infinite AWS and Google Cloud budget.<\/p>\n
Hard to say.<\/p>\n
The growth chart from 2.5k to 30k merges a day is presented as the main point of pride. But let us ask the core managerial question: does a monorepo even need thirty thousand merges a day?<\/p>\n
When a human codes, every commit is a deliberate unit of meaning. When Claude autonomously iterates and micro-optimizes services, it can generate gigabytes of code noise \u2014 though I believe Anthropic will handle this. Where an experienced engineer makes one elegant commit, AI generates 500 tiny iterations, testing hypotheses directly in the main branch.<\/p>\n
Are we absolutely sure we are creating value, and not just heating Anthropic's servers by generating and refactoring neural slop? Not a given.<\/p>\n
I feel this difference well because I use git history as a dataset myself \u2014 deterministic metrics like churn and co-change, with interpretation built on top. And the first rule there: every claim relies on a SHA or a number, not a pretty growth chart. A bare commit counter says nothing about value or codebase health. It says exactly one thing \u2014 how many times something dropped into main. The chart they are proud of describes an engineering breakthrough and neatly automated neural slop equally well.<\/p>\n
Writing a VCS core, a review system, and a caching layer in 5 months with 7 people sounds like any CTO's dream. But let us read between the lines.<\/p>\n
The code was written by the neural network itself. The article states directly: developers had to work in a "tell the model 'no'" mode, because Claude constantly tried to cut corners, violated basic architectural constraints, or over-engineered protection against hypothetical threats. Suddenly! Just as the luddites said.<\/p>\n
What are we left with?<\/p>\n
And here the luddites can exclaim: what happens when a couple of key architects quit, and Scion hits a complex distributed deadlock in Spanner? Will Claude fix it itself if no one on the team holds the understanding of how this thing works at the line level?<\/p>\n
This, by the way, is the exact fork I talk about everywhere: an agent is a multiplier for an engineering organization. But without an owner who designs the system and holds its integrity in their head, agents turn from a multiplier into an expense item. Seven people checking intentions instead of code \u2014 are they still system owners, or operators of a black box written by a contractor named Mythos?<\/p>\n
The most unexpected part of the article is the approach to merge conflicts. Anthropic honestly admitted: a classic merge queue with global locks simply dies at 30,000 commits.<\/p>\n
What solution did they find? They just dropped the locks.<\/p>\n
Changes are merged in parallel. If a logical conflict arises, they rely on auto-testing after the merge and on Claude "usually fixing such conflicts faster than a human notices them."<\/p>\n
That is, we are consciously allowing incorrect or conflicting code into main, betting that another bot will apply a tourniquet in time. In complex distributed systems with implicit connections, this is a direct path to floating, irreproducible bugs, and a conscious risk that the product will remain in an undefined state for some time. Product managers will have to be trained to accept this for a long time.<\/p>\n
I have lived in the paradigm of explicit state transitions for twenty years: the status lives in an external manifest, in a queue, in a gate \u2014 where it is visible and verifiable, not in the hope that the next run will somehow sort it out. "Merged broken, the bot will fix it later" is the exact opposite philosophy. It is a bet that the system converges on average, and that main being invalid at certain moments is an acceptable price. For a company with infinite tokens, maybe. For everyone else, this is called "our prod is in an undefined state, and we are praying."<\/p>\n
And what I personally did not like is Slack bots instead of real engineering. I cannot skip the charming passage about how they set up AI "superfan" bots in Slack, making them "with the enthusiasm of a devoted fan" constantly update telemetry charts and look for anomalies in Scion's operation.<\/p>\n
Sorry, but when instead of deterministic alerts, normal SLO\/SLA, and competent monitoring, you put a neural network to stare at charts looking for weirdness \u2014 that sounds like replacing systems engineering. Although, strangely enough, we all understand our future will look exactly like this.<\/p>\n
Scion is undoubtedly a grand engineering experiment. Anthropic faced a problem 99% of companies will not face for another ten years. They were solving their narrow task: how to prop up infrastructure with crutches when you have infinite free tokens and a giant monorepo.<\/p>\n
But do not confuse surviving your own AI chaos with industry evolution. Scion is not "the future of version control." It is a demonstration of how AI technologies allow building rather large things that no company without its own supercomputer can apply or maintain. All five "inconvenient questions" converge on one point: this is not a leap forward, it is a centralized 20-year regression, hung with models and paid for by a budget that one company in the world has.<\/p>\n
And here is what is annoying. Delivery speed can indeed be increased several times \u2014 I have done it with my hands, not on slides: in one SaaS, releases went from every few months to every few weeks; a flow of 5\u201310 new bugs a day was brought under control, revenue grew by 50%. But it was not driven by commit count. It was driven by discipline: QA, CI\/CD, proper bug-tracking, engineering culture, and people who own the result. None of these things are measured by a "2.5k \u2192 30k merges a day" chart.<\/p>\n
If you distill it to one point: Scion is a costly crutch a wealthy company used to prop up the chaos created by its own neural networks. Brilliant for their task. A catastrophe for your seven-repository, three-developer project if you drag this in under the banner "Anthropic does it this way."<\/p>\n
Are you ready to take offline access away from developers and hand merge-conflict resolution to an autopilot? Are you ready to throw out Git next quarter?<\/p>\n","protected":false},"excerpt":{"rendered":"
Scion is not the future of version control. It is a 20-year regression to a centralized server, bankrolled by infinite cloud budget to survive AI-generated chaos.<\/p>\n","protected":false},"author":0,"featured_media":211,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-212","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t