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.

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.

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

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.

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.

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.

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.

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

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

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.

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.

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.

[flagged]