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.

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.

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.

[delayed]

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

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.

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.

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

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.

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.

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

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.

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.

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

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.