HN

Comments (283)

• bob1029
  [delayed]
• Menu

  frangonf
  Excuse me for throwing up this stupid idea, but if code changes per unit of time keep growing at this rate and are not slowing down with infinite merging demand, it seems that this repo will be in a constant state of continuous change and we constantly roll forward with automated code and obviously no direct human supervision, then why even have source control? Why not just let software be fluid and, like Heraclitus river, never step twice in the same repo.
• Menu

  mixedbit
  I don't get one thing, if agents are so great at developing software at massive scale, why wouldn't Anthropic, instead of just selling tokens to other companies to use its agents, let those agents develop highly profitable services for Anthropic to support their IPO valuation or not require raising money at all? For example, a competitor to Google search.
• Menu

  netburst
  What is are the benefits of supporting extremely high churn rate in version control? What is the code doing? What problems are being solved? Are changing requirements the driving factor, and if so, why are requirement changes accelerating?> ..., the latent demand for merging code is practically infinite, and every bottleneck we remove immediately leads to a further increase in the amount of code we produce.If the goal is to write software which solves real problems, how can the demand for code grow infinitely?
• Menu

  tancop
  So it's a SVN/Perforce style server based VCS with a more modern design. Sounds exactly like Lore from Epic Games but with zero production use outside the company and no support for non text assets. And they won't release the code.
• LarsDu88
  Google migrated from Perforce to Piper, and Meta migrated from Mercurial to Sapling.Now Anthropic has migrated from Git to Scion. It's a good sign they are on the right track.
• Menu

  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
• Menu

  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?
• Menu

  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.
• Menu

  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.
• ch_sm
  Slightly OT, but it‘s interesting and nice to see that Anthropic‘s own blog posts don‘t have many AI prose tells (or Claude-isms) in them.
• Scaevolus
  Making scalable source control is much easier when you can rely on a distributed database (Spanner) and object storage (GCS/S3/...)!
• Menu

  apf6
  This is maybe a little less revolutionary than people are treating it? A lot of large tech companies (Google, Facebook, Microsoft) have already built their own homegrown SCM (or have implemented custom extensions to Git), because Git and other SCMs don't handle their scale. Most interesting thing about Scion is how quickly it was deployed.
• Menu

  tetraodonpuffer
  great article. Besides the source control stuff, I found this very interesting (and matches my experience with agentic coding in general, now we'll see until hiring pipelines will take this kind of skillset into account). I am not sure however how easy it is to review 30k PRs/day even if only for intent, and how one can easily notice if the model is taking shortcuts on implementing said intent without reading the code...---Engineers are no less valuable, but their work is changing. All of the engineers who worked on this system would now rate Claude as better at writing code than them. But our engineers still supplied the invaluable understanding of the high-level inter-system components and the design-level tradeoffs, making informed choices around the problems we wanted to solve and the scale we knew we needed to achieve. Very often, we found that the role of the engineers was to tell Claude “no.” Agents will sometimes violate core system constraints to satisfy a pattern that should never have been allowed in the first place. This was particularly common in our migration. For example, there were multiple systems that tried to brute force looking up when a change merged to main by linearly reading the commit log instead of asking our code review tool. Anthropic also makes extensive use of adversarial review, and, while this is incredibly effective in many ways, it can also be myopic, so skilled engineers needed to steer Claude away from over-engineering parts of the system in response to hypothetical concerns. For example, one such review was overly defensive about trusting another internal service, which resulted in Claude adding excessive validation and complexity. Our team members still review every change request for the system, but they now examine the intent of the change as opposed to reading every line of code.
• Menu

  altcognito
  > 30k merges per day> 25 million CI checkouts833 checkouts for every merge? That's quite a few. Even accounting for multiple environments at different stages of production readiness, that's pretty weird.
• Menu

  chris_money202
  Why can't I rack my brain around why this is needed? I have had zero issues using git with agentic coding.
• Menu

  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.
• rao-v
  One of the reasons to move to systems like this (not always spoken to explicitly) is to reduce the risk of accidental or deliberate exfiltration of code (esp when paired with build servers and remote deploy etc.). Basically nobody’s laptop ever holds much of a buildable codebase.
• colek42
  This is the wrong way to look at the problem. Maybe they should have asked, "Why does our process need to do so many git checkouts?" Why can't you just run the tests where you already checked out the code?
• abroszka33
  Where does all of this end? If they keep this growth up, or even if they slow to a linear growth, they will produce more code than humanity combined pre-AI. That's scary.
• Menu

  nixpulvis
  > In Scion, every commit, rebase, or merge happens on the server, so there’s nothing to push...I think this is the wrong way to solve problems and goes the wrong way toward solving real problems.
• paaloeye
  Hmm, so Anthropic also in a monorepo club. Didn't know.
• Menu

  mey
  Did they reinvent subversion?
• Menu

  mijoharas
  So... Anthropic reinvents SVN?
• Menu

  aogaili
  This is a nice thoughtful article.If Anthropic has the best coding model, harness and the best software development methodologies and systems. And then, they scale all that up, with no constrains on their tokens. On top of that, they have access to all kind of ideas their models getting trained on when millions are chatting with it - then in theory they can build any software better than anyone out there. And same goes to science and math..
• anon
  undefined
• Menu

  simonw
  > In May 2026, Anthropic averaged around 2,500 code changes merged per day; as of September, we merged over 30,000 per day.Here are the public model releases from Anthropic this year:5th Feb 2026: Claude Opus 4.617th Feb 2026: Claude Sonnet 4.67th Apr 2026: Claude Mythos Preview16th Apr 2026: Claude Opus 4.728th May 2026: Claude Opus 4.89th Jun 2026: Claude Fable 59th Jun 2026: Claude Mythos 530th Jun 2026: Claude Sonnet 524th Jul 2026: Claude Opus 51st Sep 2026: Claude Fable 5.11st Sep 2026: Claude Mythos 5.122nd Sep 2026: Claude Opus 5.528th Sep 2026: Claude Sonnet 5.57th Oct 2026: Claude Haiku 5.5I would guess that any public model has been available internally for at least a month before that date, maybe longer.My best guess is that the uptick in code changes corresponds to the availability of Mythos/Fable-class models inside of Anthropic.
• Menu

  smy20011
  > as of September, we merged over 30,000 per day.Their Website/CLI seems keeping the same? What did they do?
• 2001zhaozhao
  This is interesting to me, as I was thinking of adding a Git server to my AI orchestrator when I eventually need to split agent containers off of the main machine (to make agent CPU horizontally scalable).Maybe I should just bite the bullet and use a different VCS system entirely once I get there, which has most of the Anthropic system's properties (including being much faster) but doesn't need to be horizontally scalable.
• Menu

  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.
• InvisibleUp
  I'm curious what this "Antropic Antique" is. As I understand code review the tightest bottleneck for a lot of Claude Code users, and I'm curious how this would help with that.
• vb-8448
  > as of September, we merged over 30,000 per day.I just wonder what is the churn rate (and the cost per LOC) here.
• zactato
  How does this compare to Google's in-house source control?Most companies don't use mono-repos like this. While there are some really compelling advantages, the downsides tend to stack up as a company's codevbase grows.It's mainly just startups and huge companies. For small companies git works fine for mono-repos and large companies can build their own complex code management pipelines for mono-repos.I have been questioning whether agentic development changes the mono-repo vs multi-repo question.
• comboy
  Git subversion you say.. Well that would be a nice name for a centralized version control
• boredumb
  maybe next month the agents will learn the 'commit locally' and 'git squash' skills
• Menu

  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
• Menu

  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?
• Menu

  ivanjermakov
  What was the "quiet week"?
• Goto80
  So, where's the source code for Scion?Oh, it's not available, what a pity. Why write a whole article about a thing no one can have? Maybe the code isn't so great after all? Or it's all just made up and doesn't even exist?Anyway, this is yet another pointless ad from Anthropic trying to shill their AI on us.
• Menu

  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?
• Menu

  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-gitThis 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.
• 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
• tasuki
  Oh wow. There is nothing I'd rather use less than version control vibe coded by Anthropic.
• Menu

  nico
  Has anyone made a “generative git”? Where running git checkout would generate the files and git commit would just train/finetune on the code? (might need to keep a deterministic list of files at least maybe)
• alanwreath
  why does it feel like they are creating something so its more difficult to use a competitor?
• gritzko
  E = mc²E energy necessary to integrate changesm mass of the monorepoc rate of commits
• Menu

  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.
• jabedude
  What is the purpose of this article besides "we can use ludicrous numbers of tokens to reinvent any software we want, and no we're not sharing the code"?
• Menu

  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 serverI’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.
• znpy
  Did they just reinvent cvs/svn?
• ChrisLTD
  I’m personally more interested in their Antique review tool. Does anyone have any details on how it works and what it does?
• status_quo69
  No mention of lines of code changed or total LOC, what percentage of this is bugfixes vs features?
• rpowers
  I honestly think that these AI companies really messed up their futures by adopting a token model. They should have gone the route of IBM and offered consultant services.
• Jagerbizzle
  As someone that has revived and started maintaining an internal code review tool, I'm very interested in reading more about Antique.
• Menu

  herpdyderp
  I want this so badly. If Anthropic released this I would start using it on day one. If they launched a GitHub competitor built around it I would pay for it on day one.
• mqus
  They should concentrate on their models instead. If claude code is any measure, their software engineering is atrocious. I would only use something like source control from them if they force me to, at which point I would rather do something else.
• nozzlegear
  Honey, it's time for your daily Anthropic PR piece!
• Menu

  wclausen
  This feels like a really nice design for the data system given the goals. Things that I noted while reading:* This system leverages a metadata log pointing to immutable blobs in object storage. The metadata log can give high write throughput and keeps the control plane consistent. Object storage supports high throughput of the heavier data objects. Overall, it's an excellent choice given VCS systems can typically tolerate the latencies associated with object storage, as is the case with many operations-focused systems for businesses.* The server/upstream gains scalability by reducing the amount of data it processes when accepting a commit/performing standard VCS operations. No packfile, no file i/o to construct a consistent copy of the repo, just a (usually) small metadata record that can be validated/committed quickly. The client primarily gains scalability along a similar axis (reduce amount of extraneous work for a given goal) where it can request just the pieces of a repository it needs to do its job, when it needs them. For example, agents can begin reading files from a checkout eagerly before the whole updated version of the repo is finished being downloaded, then during a compile step, updates can be fetched only for the module being compiled, etc.* The system seems well designed from the perspective of considering "when exactly do I need a thing to be done." Git tends to bundle more of this work into synchronous operations when a request comes in, which ensures the system is consistent at the end and doesn't require a persistent process, but is costly. This system makes intentionally different decisions about "what work happens, when" so that the minimum amount of work is done to confirm a write and allow for the state of the repo to be reconstructed consistently, but it defers certain things that are useful but don't need to block a write. The discussion of "derived data" mentions that certain useful structures can be computed in a deferred way, which supports doing work around the time it's needed.* A large part of the nice operational features of the system is downstream of making core data structures immutable. File contents are immutable, content-addressed blobs. WAL entries are immutable records. As mentioned in the article, this supports excellent caching, and simplicity in reasoning about history/updates. Additionally, the derivation of other useful data can end up as immutable outputs (themselves stored as pointers to objects, if scalability requires it).* The decision to develop a custom VCS supported a number of other integrations into "agent-first" software development systems. The system makes it easy to enforce access control on specific directories, nice if you want to have agents explicitly denied the ability to edit something. You can also get a sense that it supports some valuable features in the associated code review system, for things like pointing a human at the most important changes in a changeset. You could imagine in the future, some associated highly flexible "owner" rules/notifications where a human can specify "I want to be notified if X system has a significant design change" and that intent can be recorded/managed in a more useful way than "add me as a reviewer if files in /abc directory change."* I do wonder if content-addressing of the files is broken into chunks or not. Doing "one blob per file" is nice and simple, so maybe that's how it starts. But you also duplicate a lot of data, but maybe the dataset is still trivially small in the scheme of things, and the operational concerns win out. And if files are small anyways, you'd want to avoid splitting them into tiny chunks bc that'd affect the bandwidth you can achieve when downloading (spend more of your time on per-object/request overhead rather than actually transferring data).Very nice piece of engineering work. I was also impressed by some other parts that received a little less discussion in the post (understandably), but would love to hear more in a future post:* the testing approach of driving tons of system interactions in a hermetic way is really exciting to see. Feels like agents should help us write really excellent testing infrastructure, and that this would itself be important for gaining confidence to deploy without requiring a read of every line committed.* Similarly, the mention of the "superfan" agents that closely monitor very specific parts of the system seemed very cool and would help a lot with deploying code you haven't necessarily read closely but seems reasonable architecturally. Though it'd still ofc be best to catch issues prior to merge/release, having extremely good monitoring/rollback capabilities would mitigate a lot of the downsides of high-speed, agent-based software development.
• Menu

  htrp
  Sounds like they should stop using their mono repo
• Menu

  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.
• anon
  undefined
• nojs
  Curious what happened at Anthropic HQ for a week in August
• 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!
• barsandtones
  Sounds like they re-implement fancier CVS?
• alansaber
  If any engineering org needed its own VCS, it would be anthropic.
• willmeyers
  Seems similar to how version control works for large game and 3D assets. Neat.
• philipwhiuk
  I'm worried that the frontier lab doesn't read the code they are writing.It's also hard to believe all these non-Git alternatives aren't merely an attempt to capture developers into a new proprietary solution.This could have been done as an open-source fork of Git.
• jauntywundrkind
  Related, I've always wanted to see someone other than Meta run EdenFS, to hear more reports of what it's like. Feels like there's massive overlap. [Edit: I've chatted with Astra Pro some on this too now, https://chatgpt.com/share/6ace7be6-68f8-83ea-ad68-0f9d144483... ]. https://github.com/facebook/sapling/blob/main/eden/fs/docs/O...It's designed for container running, but ArtifactFS has some similarity in principle to me. The on-demand materialization. Quote: ArtifactFS is a Git-backed filesystem daemon (FUSE driver) in Go that mounts repositories as normal working trees while avoiding eager blob downloads. https://github.com/cloudflare/artifact-fsI threw together my own jujutsu powered FUSE subtree project just the other night. This was basically one-shotted, just to see how it does it, to learn more, not really intended for use. But obvious overlap. https://github.com/rektide/jj-workfuse
• anon
  undefined
• 978ahdsg
  Source control for huge monorepos has prior art, notably Google’s Piper and Meta’s Sapling, so we were able to build Scion with their hard-won lessons in mind.What an unexpected candor! Of course you plagiarize prior art.No sane person is going to put their sources in this slopware Scion monster.
• Menu

  vitacoco
  Extremely annoying - can we throw anthropic class resources at more agreed upon solutions across companies. We don't need custom source control at every company - google has its own, fb has its own and now Anthropic.Can please we all converge to 1 f'ng solution.how does it compare to Epic's https://lore.org/ ?
• stackedinserter
  Back to SVN then? Noted.
• j45
  Solving monorepos in an LLM world seems to be very universally applicable as a need.I appreciate it's different than git, that type of argument for monorepos is not new.Agents coding is akin to having a very large developer team, who may or may not be online 24/7.Anthropic is calling it very specialized, and it's a little baffling.. maybe I'm missing something.There's no way software development is the same anymore. The previous ceremonies and structures and seats at the table at each stage were human based, and now that's a different make up to the point that different steps and processes are needed.There's nothing more fundamental to growing software development other than making tools like this available.My hope is a vibe coded internal mono repo management tool can aim for a v2 with multi-tenancy built in.Was anyone else looking forward to feature flags as a part of a post like this?
• kreutz
  Am I the only one not feeling the output of this velocity?
• Menu

  rfgplk
  Yea, I'm pretty much hiting the same limits. I'm still using git for the time being, mainly because I package everything as daily commits with an external orchestrator managing tasks/issues. Lately my code velocity is at ~1 million LOC added per week, spread throughout my various repos (I don't use the monorepo approach). Problem is I'm looking at 100x this velocity over the next few months when I get a new code generator up and running, so I'll definitely have to drop git.Another issue that I believe Anthropic here didn't state is that git performance _severely_ get degraded when you have hundred of commits landing in parallel. Hence why I fell back to the daily commit approach. You get less granularity but you get stability.
• jonathanyc
  We’re completely rethinking our priors. This project prompted us to take a very hard look at other workflows designed for human scale. A proper merge queue, for example, doesn’t make much sense at agent scale. What does CI even mean when hundreds or even thousands of changes can merge while tests are running? We haven’t been able to effectively replicate the industry standard of a global repository lock on the merge queue, so instead, we’ve invested in post-merge and pre-deploy automated testing. This does mean that concurrent changes can conflict, but Claude can typically fix these conflicts faster than humans can even identify them. I see, that's why https://status.claude.com/ looks like a Christmas tree on fire.
• hollerith
  All the other tech billionaire are jealous: they all want their own recursively-self-improving megacorporation.
• Huntsecker
  [dead]
• tarofchaos
  [dead]
• sklinkert
  [flagged]
• ls-a
  [dead]
• Menu

  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.