Redesigning source control at Anthropic (anthropic.com)

Even with humans out of the loop you will still want features like branches, pull requests, tags/versioning, build reproducibility, etc.

Agents use source control, too. It's a pretty important part of the development process to understand how code has changed.

For example, you can imagine, at the extreme, that agents could get caught in code change loops: a code change seems appropriate, it is implemented, it turns out there's some external factor which makes it not appropriate, the change is reverted, then that same code change seems appropriate again, etc.

Obviously you can prevent that from occurring with some extra infrastructure in-place, but at that point you're basically creating source control.

I expect mainly because the coding models are trained to roleplay that process and don't work as well if they can't pretend to use git

I've been doing that for one project/experiment. No source control. Tests and an agent swarm let loose.

It works, but there is a significant amount of churn. I find when the swarms use git it's less churn and less token usage.

Lets take the idea further, and since nobody seems to be reading it, just throw away the source code. Just let the agents go directly to assembly.

Source code exists, that’s not in doubt. If it exists it needs to be managed.

From the post (especially the end) it seems that they are essentially letting software be fluid.

Reading this post put me in a similar head space.

I believe you're mostly thinking of version history though. There’s plenty of other reasons to have source control we still need, like guarding against racing writes or continuous integration to ensure correctness. Even some industries require version history for compliance reasons.

I do love how AI is challenging us to rethink our tools though rather than blindly reaching to git for every project.

I don't think this is stupid, and I think the logical extension to this is agents will start writing directly to prod with fully automated code changes.

Pulling that off successfully at scale would be pretty incredible to watch.

Good way to keep metrics and prove work is happening would be my guess.

They are probably like 3-6 months away from just letting their agents work directly on prod after realising that repos don't scale enough.

didnt the article say thay engineers still review change requests? They just switched from reviewing code to reviewing intent.

So "no direct human supervision" seems like a misunderstanding. Article even bigs up the purpose of engineers with a hilarious (to me at least) line about auto adversial reviews resulting in over engineered designs.

> then why even have source control?

I know you are joking, but the answer is the same. Because the agents need it, not because any human need it. The Agents quite actively use the history. It's more effective than any comments or separate documentation might be for the agents working on the code.

Many parts of the Git distributed version control are the results of good decision made. Anthropic source control team just think that their trade-offs needs are vastly different from other businesses. They said these too:

1. they have no-cap token spend allowance internally

2. their agent swarms are amongst the largest if not the largest, again because #1 above.

3. their git repo is enormously large (100GB uncompressed git history on main, 25GB compressed).

4. their merges per day count grew an order of magnitude from May to September to 30000 times per day, they are not seeing it slowing down anytime and probably only going to accelerate.

5. all of their code agents are networked and has network access, full local pull down is not needed at all and too slow (see #3)

6. their design of the Scion is based off prior art Google’s Piper and Meta’s Sapling.

Given their own constraints and characteristics of their own. It only makes sense to build their own homegrown solution based on prior arts. But this was NOT a complete redesign from scratch - so it's an full online download only what you need type of source control system. The problem is the version control software itself but its prior tradeoffs are misaligned with their scaling needs.

PS, if anyone noticed, Anthropic starts to concealing their employee full names and replaced with only first name + last name initiate, not sure why.

PPS, the project Scion is so bad, scn is worst, it reminds people of prior SVN, which is bad by itself.

This has always been the dream, code flowing constantly like a river, like green rain. Imagine a world where you never use the same piece of software twice, because every day it changes.

This is how we solve cybersecurity, by making code into constant shifting sand, so a vulnerability never truly lives long enough to be exploited at scale. Sure, a hacker may occasionally pick out a vulnerability like a bear picks salmon out of a river, but it makes larger scale cyberattacks impractical. The code is a firehose, constantly in flux.

You’d expect that while the frontier of changes fans out and grows, some of them burn out and disappear and some of them survive and solidify into a relatively static code base.

The big baddies of build have worked this way for a long time already. Git surfaces a single Merkle tree id for the whole repo on each commit, but build tools like bazel/blaze, buck, pants, et al look at hashes of subtrees and use cached artifacts for the parts of the tree that didn’t change.

Your CI no longer becomes a binary signal on the code and more of a continuous signal on how much your “this works” pointer has caught up with your “this is the latest code” pointer.

My mental model, for what it's worth, is this: - deterministic foundation - non-deterministic on top of it operating against (and building) it

That is, the deterministic part is the platform that is being built and that non-deterministic agents will use and build it, but that layer is a key part of how they do work and will continue to be.

Funny you mention that, that’s actually the direction I’m taking with the architecture that I’m building

In fact most of the architecture work I’m building, assumes that there will not be a human reading code, they read (effectively) UML and data diagrams

so most of the interesting parts I’m working on now are how do you make code blazingly fast, formally verified and memory safe if you remove the constraint of human interpretability of machine instruction

You're asking if the bitter lesson is true and the neural nets will become so general purpose, they'll eat the source control as well? Yes, but that won't happen for another couple months.

You think CI and distributed builds aren't necessary if you change the code fast enough?

There's lots to improve in how we handle code, and losing the agreement on what the codebase even is sounds like an awful regression.

Surely their goal is ever-faster recursive self-improvement.

I find the accelerationist mindset utterly ridiculous. All that busywork and for what exactly? What effect has all this overproduction of LOC had on the physical world and on our existence (beyond the externality of erecting huge data centers in every corner of the globe and the consequent ecological impact)? Is software getting better (in terms of quality, security, efficiency)? Are we getting better government services? Are we getting better food? A better environment (silly question)? Are we working less, as tech titans keep promising us? Are we getting anything better? Not to mention all the negative aspects of this technology and the financial apparatus driving it.

> What is are the benefits of supporting extremely high churn rate in version control

Inventing new problems caused by our "solutions"

> What is the code doing

Don't you know? We're just 6 months away from AGI; no one will ever need to read source code ever again!

> What problems are being solved?

How do we build a house of cards that's so tall, people value it at trillions of dollars, and build it so quickly, people don't realize it's worth far, far less?

> goal is to write software which solves real problems

No, no, you silly goose. The goal of software is to make gluttonous amounts of money. The side effect just happens to sometimes, occasionally solve real problems

This is the main thing that raises my eyebrow.

If you are constantly churning your codebase to the point that you need to invent a system that handles your churn... then you must at least be admitting that the previous 6 refactors you wrote were not good, but NOW you have it right.

I feel that good, well designed code change by accretion, not by rewrites. Code that remains stable for a long period of time was likely better than code that needs be continuously rewritten (at least with humans writers).

But maybe this is just a human-centric view of what good code means? That LLM "slop it until it works" approach to development will have a different measure of what quality looks like?

I think that they're essentially solving the wrong problem.

Imagine that you have git but you don't even have a concept of programming language more complex than assembly. All your commits and git history are pure assembly. Everything is cool, until one day C++20 randomly spawns into existence, and a bunch of guys decide to use it in the company. The issue is, the compiler generates so much assembly, that your existing workflow cannot keep up with it. Your assembly git repo grows into hundreds of gigabytes, with PRs that are pretty much complete rewrites coming every single day and there's no way to review any of that shit.

What Anthropic is doing is redoing git from scratch so that it can handle all that assembly, while the correct thing to do is to commit C++ code into the repo, with deep trust that you'll never hit a bug in the compiler - basically impossible for initial versions of compilers, taken for granted nowadays.

What I'm saying is, Anthropic should create a versioning system for prompts, because they are the true "source code". Given the same prompt and the same sequence of random numbers, LLM will generate exactly the same code, which sounds awfully close to how compilers work. Once in a while put the generated code as a point of reference+ caching and presto.

Cursor's blog on scaling Git makes me think that Anthropic just likes reinventing the wheel with their infinite token capacity: https://cursor.com/blog/git-at-any-scale

Cursor scaled git to way more writes/s than Anthropic did with their rewrite.

Anthropic already has their own WebSearch tool in Claude

In a gold rush you want to sell the shovels, and in this case the AI is the shovel.

Because creating a successful software product is more than just writing code.

If investment managers are so good at investing why don’t they just make money for themselves instead of trying to get people to invest with them?

> For example, a competitor to Google search

What do you think Claude (chatbot web interface) is?

Writing code is less than 10% of the average business.

One word: focus.

> a competitor to Google search

Fielding a web index takes a massive amount of compute and storage of a very different kind than what Anthropic is using. AI is extremely heavy on GPU, maybe somewhat on storage but (comparatively) light on CPU. They need CPU to train coding agents, obviously, but scaling to a billion user web search is a whole different thing.

Lack of focus can kill you, too. OpenAI learnt this the hard way: https://www.wired.com/story/openai-shuts-down-sora-ipo-ai-su...

There is more money in selling shovels than you can ever win by having a monopoly on really effective shovels. They don't need to build a competitor to Google there's 300 companies throwing money at them while they build the "next google" and even if they all fail Anthropic still wins.

Because creating a successful company takes a lot more than writing code.

Anthropic could easily build a CRM equivalent to or better than salesforce but they still wouldn’t be able to compete with salesforce. It makes a lot more sense to sell salesforce tokens instead.

If farmers are so good at farming, why don't they grow every crop there is and just live for free instead of selling 1-2 crops?

That’s kinda like asking why does any company make and sell any tool rather than just using the tool to make money? Why does Milwaukee sell power tools to contractors rather than keeping those tools to themselves to profit from contracting work?

Well both Microsoft and Google are part owners of Anthropic, and Anthropic uses their data centers. I think those companies would use that leverage to prevent Anthropic from directly competing with them

Probably because the shovel Anthropic is selling may not be as good as they claim it to be.

Same reason banks sell mortgages rather than just buying all the homes.

At 30000 commits per day this sounds like an integration nightmare

How does leaving a monorepo help? It implies you aren't testing dependents on every change?

Does it really matter since It's one-time import pipeline.

This is quite insightful: even the best of software engineers (presumably) already are unable to even loosely keep up with these models.

Just a reminder to simply embrace their superior capabilities instead of feeling threatened.

Was it a first version in TypeScript then rewrite to rust situation?

Perforce was fine. It just had a terrible ui and didn’t allow me to code on the beach.

If I were still manually merging conflicts the p4merge tool was GOAT

I used it in git

That my thought when I saw online only, we're back to Subversion.

You think you have it bad now when GitHub goes down, wait until you're stuck with an online only client.

Oh the SVN days, brought back memories

Yeah pretty much Perforce.

> And they won't release the code.

This is the weirdest part, because you know, coding is solved, so anyone could create their own one, so why not publish it?

>If I was an investor I would be on the phone with Dario asking why we are wasting engineering talent on reinventing source control and churning the product with 30k pulls per day.

To be able to write PR pieces, like TFA.

It would be interesting to segment that graph by bug fixes vs changes, and maybe also significant changes vs minor/trivial changes.

Prompt Claude for PR articles?

besides optimizing inference I would assume a lot of non trivial code would also be worked on on the training side, at the scale they are operating I also assume a lot of usually trivial things become no so much.

I can’t give a non-snarky answer. I guess they’re all training Claude Code and testing it so that the Claude desktop apps can be native apps instead of Electron based nonsense. This is the only thing Claude Code is still unable to accomplish.

as the article says one of the main jobs of the humans is to say no to Claude regularly

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

Claude will always need meat puppets, at least until it figures out how to automate owning stuff. And after that I'm sure it will want to keep some humans in zoos.

Teaching Claude to compare taking the simpler path instead of the average (more verbose) path every time.

You think software engineering, system design and machine learning research is just about writing code?

One does wonder why Anthropic and OpenAI have employees, when HN knows the superintelligence can do all jobs already.

Prepare to make us all jobless, without any moral issues in doing so, as they profit from their stock value assets.

It is even there on the blog post, doing more with a small team, followed right after by a hand waving paragraph how software engineers are still valuable, to avoid the expected backlash from the previous paragraph.

Sitting over an Anthropic (TM) developed, specialised 2 button keyboard accelerating the development further:

[Yes] [Yes, and don't ask again]

The last jobs left for humans will be those dedicated to keeping AI under human control. By definition, that's the one thing we can't delegate to AI.

I'm also a bit confused what Anthropic needs all this code for. Their main product is selling access to their model, but the model isn't comprised of code, it's a bunch of weights right?

So the code is for the stuff around the model, claude CLI, the website, the API... that probably shouldn't be infinitely growing right?

Is there a bunch of code they are using as part of training, or as pre-processing or post-processing the requests to the model?

It's a daycare for software developers so that they don't get laid off/quit and go to a competitor

GTM engineering? Customer-facing roles? I work at a firm with around 700 employees. We have an enterprise relationship with Anthropic and there have to be a dozen Anthropic employees in our shared Slack channel.

That many commits in a day I wouldn’t call it engineering. That’s basically brute forcing.

I think the article would tend to agree with you, given its position on the reluctance of open sourcing and/or sharing the actual Scion software stack.

There's so much intricacy and subtlety in each organization and even individuals' environment being incorporated into tooling that expecting these tools to generalize at this point is perhaps an expired ethos.

I even see this in the tooling that I run in my own personal stack. Many projects are candidates for sharing, and I have nothing against it, but they incorporate such specificity toward my own environment, including things like hardware, that creating shareable and more generalizable projects from them adds more to the maintenance surface than I would care to support.

When people wonder about where all the productivity of LLMs is going to I think this is part of the answer.

There is no doubt everyone is far more productive with LLMs in generating code. However, a lot of productivity is going into things like that. Have you always been bothered by the limitations of Grafana? You can generate another dashboarding solution that works best for you. You know that deployment team that is so slow and annoying? Now you can generate your own deployment engine. Have you always hated how kubectl lets you manage one k8s cluster at a time? Now you can ask AI to generate fleetctl. You can start your project with DynamoDB, rewrite it to mysql, then to postgres, then to duckdb. Start with Python, switch to Golang, then switch to Rust. Deploy on AWS, then move to Azure, then move to a hybrid option then throw colocation in the mix. Don't like your source control? create a new one. Json is too limiting? Invent a hybrid JSON/HCL language. The browser sandbox is limited? Make a desktop app, make a language, make an OS, make a kernel.

Originally I felt that there was going to be a reinvention of the wheel, until I saw the "shape" of software development changing, and the tooling needing to support the new flexibilities in positions and process.

Software development is not as much de-risking at the front like it used to be before building.

Now teams can build lots of stuff that works great, except it's the wrong things.

Most things are becoming the understand the problem "shape".

Understanding the shape of the problem isn't something LLMs can always make as.. svelte as early on.

Word generators gotta generate..

Recently a colleague of mine shown us a demo using a fresh model designing a building construction detail live, in minutes, which is a function that we struggled to bring into our construction design software due to resource limitations (and legacy barriers) for long. All this in the context of offsite constructions where the design can directly be exported to the right CNC machines in the factory, and arranged for delivery and assembly order. We have let ourself amazed, despite the controlled demo situation and the small detail, it was a remarkable performance. For a minute or so, but thinking further, why would the customers (construction design engineers) of our competitors flow to our legacy software full of legacy pitfalls they know about and have to live with when they can turn to AI for a fresh design solution themselves, just like we did? They know the context better than us anyway, just do not have time for bit-carving. Why would we have customers when customers of our customers can turn to an AI for a design that is buildable? I was consulting one model about a structural engineering detail, and it was quite well informed I have to say. From training data alone. I felt, maybe I need to rethink the rest of my career, that is not that long but still uncomfortably long for being predictable beyond a few years.

Well, things are not that bleak, probably, at least not for our customers. Regulations (accountability) and physical world matters still require them. But not us for our customers, not that much and not for too long. They tend to be the tech savvy folks eager to jump at adjacent domains when it saves them a percentage or two off the construction costs (not a small pile of money), and AI with its programming language of English and deep knowledge pool is not that big a jump from their standpoint. Our domain is pretty well formulated, regulated, documented, inherently built on do-check-adjust loops already. With a thing like AI it might worth to try making and improving a design solution in a second loop. But they also started to invest in robots already driven by software for their factories, AI might jump in there, and I wonder how much more until the regulations are forced to change by Super Intelligent (R) politicians for the sake of AI accelerated built environments (housing crisis, you know!), shifting the AI use further out towards generic population, wanting to order a new two bathroom condo for next Friday from Alibaba. The conservative construction business is a nuisance and obstacle in the way of modernisations anyway, go around it!

I will go to work tomorrow, and for some time, but the picture above feel less and less fictious with each passing day of AI news and usage.

I agree, but most of this sits above the raw source control layer; we have a lot of this kind of context in Antique (our code review / code management platform). I hope we can share more about what's worked well for us here soon!

> Instead of infrastructure being more easily shared with the collective, or valued enough to build a business, now companies can tailor even major infrastructure to their own needs, and avoid all that coordination.

Large companies have always done this. Tons of early 2010s open source projects came out of reimplementing white papers from closed-source Google projects.

It’s also the major downside of this kind of thing. Once someone gets acclimated to how things are done at a large company with custom tools, it’s not always easy to switch to another process, especially a simpler one. There are tons of stories about FAANG engineers joining a startup and being useless.

There’s real value in having consistent tools across an industry. It makes hiring and training easier. Even if you’re convinced that a LLM could crank out a payroll or ordering system that’s perfect for your org, you still have to train the accountants and admin assistants to use it. And you’ve now become the customer support.

The bar is lower with version control, but it’s still more friction than git + GitHub + a well-known workflow.

This is the single biggest skill of engineering nowadays. Rapidly looking at a solution and saying, "yep that's good keep going" or "nope, that's bad fix this" or even "wrong approach, do X instead"

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

Speed reading code is huge. You just need to focus on certain hotspots and know which things you're scanning for. The traditional approach of reading the code and trying to compile it or reason with it in your head is too slow.

With 1000 engineers and most PRs bein housekeeping we’re down to 10 prs per day per engineer. And as they said - this is engineers core job now. It’s a new kind of job.

Personally I can easily imagine one or two orders of magnitude more than that. They crossed the rubicon of not gating PRs on tests. In that land you can just roll out changes to production, a small subset of it, during code review to assess behavior. Or during key moments of coding.

I’ve been thinking a lot about this recently: what can we get if every change goes to production in 100ms, and what do we need to do to maintain stability?

I genuinely don't understand the core value they're pitching here. The tech is interesting, and I'm not trying to under cut that, but I question the idea that this is directionally valuable advice to nearly any company.

This amount of churn feels like a thing only possible with no real profit motives and a lot of money to waste.

Lots of activity is not necessarily synonymous with productivity, and it carries real cost.

So I think the design here is interesting, and the concepts seem applicable to where some agentic development may end up, but I question the underlying principles that drive this being the right solution space at all. At least if the goal is a profitable company.

im still not sure what they built software wise that warranted these many commits.

How about 100GB disk space for a checkout. That's pretty weird too. Makes you wonder if they're the best stewards for code. Makes you wonder about turning claude loose on your codebase.

In a repo this large, there are a lot of tests and pipelines that need to run as code is tested, built, and deployed. Each test shard we run in parallel needs to check out the code, for example.

I suppose massive churn in commits would also bloat the history.

Not sure they should be proud of these numbers, they’re a sign of dysfunction.

We have a file size limit of 5MB and I aggressively pruned all binary content that really wasn't fit for source control since it compresses really poorly and can cause performance problems in git when updating a checkout over many binary file changes.

This is really all just text.

Yes. When things are too big to live locally, access on demand is the answer. See Piper, Microsoft's VFS for Git, etc.

>> My best guess is that the uptick in code changes corresponds to the availability of Mythos/Fable-class models inside of Anthropic.

Yeah. OpenAI basically said the same thing with regards to having Astra available to their team internally over the summer.