Redesigning source control at Anthropic
Philpax
668 points
641 comments
October 13, 2026
Related Discussions
Found 5 related stories in 109.2ms across 9,386 title embeddings via pgvector HNSW
- Show HN: Devthropology – Better Insights for GitHub Repos dpc94 · 32 pts · July 09, 2026 · 55% similar
- Show HN: Twigg – open-source big-tech-like version control and software forge andrebianchessi · 17 pts · July 24, 2026 · 54% similar
- How version control will evolve for the agent boom tapanjk · 46 pts · July 09, 2026 · 53% similar
- Git at Any Scale meetpateltech · 30 pts · August 18, 2026 · 52% similar
- Asked Codex to redesign a page; it pushed my repo to OpenAI infra npmn · 28 pts · July 24, 2026 · 51% similar
Discussion Highlights (20 comments)
amelius
It would be nice if you could just commit the prompts as your "source code", and let the AI-generated code sit in the repo as a kind of expensive-to-generate build output.
willmeyers
Seems similar to how version control works for large game and 3D assets. Neat.
memonkey
> Git offers tools for working with a slice of a repository, such as shallow clones, sparse checkouts, and promisor remotes. I honestly just cannot. Just tell me what the workflow is. Give me a video that is Twilio-level simple explanation.
JohnMakin
> As our monorepo grows, it increasingly doesn’t fit that design space. The history of our main branch alone is almost 100 GB, and a compressed working copy is over 25 GB. This is absurd, and I expect is a cause of the fact that they seem to use git history as a message queue source of truth between agents. They can do whatever works for them, fine, but I've noticed this has leaked into their training somehow, my agent, despite very strict rules on how to use my git workflow, will do absolutely nonsensical and weird (from a human who has used git for a long time perspective) stuff with git that can only be a byproduct of how they use it. Hopefully this fixes that, get your weird workflow out of mine.
jsrozner
Often, I see 50 people all recording the same exact thing on their iphones. Rather than a single 200MB video, we create 10GB of data. Then I think about how many people are paying a subscription to Apple for icloud storage. The amount of photo storage being used is impressive. Automatic backup to icloud and server provisioning to reliably store it all is also impressive. I just wonder if it makes sense.
mijoharas
So... Anthropic reinvents SVN?
trnvll
> Earlier in the year, we had largely handwritten the first version of the git-to-Scion ingestion pipeline as a prototype. We thought it was good—until we got our hands on an early internal snapshot of Claude Mythos Preview. We asked it to rewrite the whole thing, and with no further instructions, it produced a version that consumed 20x less memory and was 4x faster, while preserving all of the implicit invariants around ingestion ordering and data structures. I feel like the advantage of having these models in house can't be understated. Companies with access to inferior models, trying to compete, will be left in the dust when it comes to general development.
steveklabnik
Very excited to see this come out of Anthropic! This[1] is what we believe over at East River Source Control as well, and seeing one of the big labs talk about it really validates our thesis. We are offering a bridge to git via a compatibility layer: https://ersc.io/blog/what-comes-after-git This gives you the ability to ease your transition, as you don't need to swap services and move to something non-git at once. Moving an enterprises' source control is a massive lift, and so building a bridge from here to there is a big focus of what we're doing. 1: That is, if you have a large team + agents working in a monorepo, you will hit git's scaling limits, and need to move to something else. Google and Meta hit this point over a decade ago, but now lots of other companies are too.
jcims
Every now and then I like to browse the claude code release notes just to get a sense of the number of changes in that product over time. There's little choice but to simply count bullet points if you want to try to quantify it, but it's interesting how that count over time compares with the charts in this article: https://imgur.com/a/M30pFLc
bix6
> Fetched naively, that would be over 600 PB of git traffic per day. This seems like an absurd amount of data / traffic per day. Is there really that much to code that needs changing on a daily basis?
atleastoptimal
What seems inevitable is that the frontier labs will be able to recreate every piece of software better than the current offerings, and after that everyone will just be a vendor of the frontier labs
amluto
I though the basic idea was reasonable, until: > So we asked ourselves: if we designed source control with the fact that agents are always online in mind from the start, what would it look like? And > In Scion, every commit, rebase, or merge happens on the server I’ll pass. A big part of the theses of git and, even more so, jujitsu, is that you can build up a history entirely locally, making it reasonable to make tiny commits locally and then rework them, push them, or throw them away. Sure, in Anthropic’s world, it’s completely impossible to do anything without access to the inference API, so why not add another mandatory API? But I think this model sucks even in a pervasive AI world, and I don’t want to dig in deeper. This also sounds like a great way to have yet more security problems where your swarm of agents start cooperating more than you want them to. By all means, built a better system than git. In many respects, git sucks, and git upstream is not solving the major problems. But don’t lose the actual benefits of git! For that matter, I’ve seen the crap that the latest models will commit. Why on Earth should one’s VCS force the per-agent-instance system to upload the crap before even contemplating locally whether it’s a good idea? Maybe this is why Anthropic has so many commits per day. (Am I the only one who feels like most of the big AI labs are rapidly gradient-descending toward something that is nowhere near a globally optimal stack?) P.S. Only 30k commits per day? That’s not actually very many per employee. I’m suspicious that Anthropic’s real issues are that too many of them are giant cross-cutting messes and that git clone is too slow.
smy20011
> as of September, we merged over 30,000 per day. Their Website/CLI seems keeping the same? What did they do?
jareds
Is this really something to be proud of? I make heavy use of AI, but for anything that is eventually going to production there's still a human reviewer. Based on this I assume Anthropic is shipping code with no human review? Is the future of our industry going to be oneshotting prompts with out manual code review and then having AI fix the bugs found in production buy customers? I'm not trying to be a Curmudgeon, but am I missing something?
kburman
Not to downplay Anthropic's engineering work here, but I suspect we'll see a lot more reinvention of the wheel, even at smaller startups, as AI makes writing code significantly cheaper. The tradeoff between building something custom and adapting an existing solution is changing. Whether maintaining all that custom software turns out to be equally cheap is another question.
ivanjermakov
What was the "quiet week"?
preommr
> as of September, we merged over 30,000 per day. There's going to be an ugly phase where everybody FOMOs into thinking they need to do the same, only to realize that they're not Anthropic/Google/etc.
piker
Honest question: at this point, what do people do at Anthropic? It sounds like Claude loops on itself and must be pushing millions of lines of code changes per day. Even the humans can’t type commit fast enough. Are these people soon to be laid off?
esafak
Practically speaking, it’s difficult to offer Scion in a form that would be broadly useful to other organizations. It diverges significantly from git, meaning companies would need to migrate every piece of the development lifecycle, and it requires its own code review, code search, and CI. Our internal versions of these components are highly bespoke, so they would be difficult for other organizations to adopt, and we worry that attempting to build a public version that tries to please everyone wouldn’t actually be very useful. k, thx for sharing. Are you guys sure this isn't a Google blog post? They would be proud!
pbrowne011
For a broader look on scaling other parts of software development outside of source control, Adam Bender's talk from earlier this year ("Software engineering at the tipping point") has some good ideas: https://youtu.be/2n41YjR5QfU