alt Hacker NewsRedesigning source control at Anthropic
Comments
> as of September, we merged over 30,000 per day.
I just wonder what is the churn rate (and the cost per LOC) here.
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.
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.
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
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.
Making scalable source control is much easier when you can rely on a distributed database (Spanner) and object storage (GCS/S3/...)!
A "scion-daemon" is not something I want to meet...
It's not open sourced in case you are wondering.
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)
This is... surprisingly small?
From what I recall, Google's repo is closer to 80 terabytes.
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.
Can you estimate the total number of tokens you used to create this new system?
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"?
>Changes merged to our monorepo
> monorepo
Well, there's your problem.
I’m personally more interested in their Antique review tool. Does anyone have any details on how it works and what it does?
Hmm, so Anthropic is also in a monorepo club. Didn't know.
As someone that has revived and started maintaining an internal code review tool, I'm very interested in reading more about Antique.
No mention of lines of code changed or total LOC, what percentage of this is bugfixes vs features?
why does it feel like they are creating something so its more difficult to use a competitor?
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.
How much is the sheer volume of slop code that AI generates reduced by if you simply specify that you want it to be both minimalist and readable, getting it to think hard about architecture and completely rearchitecting requirements change? Surely if AI is so smart and useful it should be able to manage that?
maybe next month the agents will learn the 'commit locally' and 'git squash' skills
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-fs
I 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
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.
This sounds more like a trash pile than a source control system. Anthropic is spewing out code for codes sake. They cant possibly manage it, the more they generate the more they will realize they are just regurgitating training data for no real purpose that can serve anyone.
And for this they buy disk? Maybe this is irresponsible use of technology.
Seems similar to how version control works for large game and 3D assets. Neat.
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.
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.
If any engineering org needed its own VCS, it would be anthropic.
Curious what happened at Anthropic HQ for a week in August
E = mc²
E energy necessary to integrate changes
m mass of the monorepo
c rate of commits
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.
Sounds like they re-implement fancier CVS?
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.
I wonder what happened in late July, early August - the 'quiet period'
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.
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/ ?
Did they just reinvent cvs/svn?
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?
Am I the only one not feeling the output of this velocity?
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.
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.
Honey, it's time for your daily Anthropic PR piece!
This is such a Claude written post. Obvious tells everywhere, but the most annoying is how it uses private terms without defining them. What the fuck is "Spanner"? It refers to it multiple times. Of course we know the reason is that some dickhead at Ant told their Claude to write a blog post, and Claude being Claude has very poor/non-existent theory-of-mind for people and generates this trash.
A "scion-daemon". Hmm... That's something I don't want to meet.