Aren’t the concepts mostly already in place for a decade or two at Meta and Google?

Which would support your argument, but I don’t think this is particularly new.

> fifth major article

Seventh, at least, all the major code forges are on it: https://about.gitlab.com/blog/scaling-git-for-the-agentic-so...

Entire also seems focused on this: https://entire.com/news/entire-launches-distributed-git-netw...

Don't forget that Claude just got 3x faster by... using gzip!

Ideas are getting cheaper with the day, so convergence is less likely every day too.

On one hand, we speak of code its authors never read, never share, and never accept patches. So the entire point of git is moot.

On the other hand, some lower-level tools have to be simple, reliable and efficient. Here, sharing is critical. Even the authors of the post shared some incremental improvements to git. Here, the scalability story is moot.

I think git is becoming a protocol. One product can no longer cover these cases.

What they do not have is a version of chatgpt.com that is not a slow, awkward, glitchy mess.

As a user of Astra, it writes code that appears to work. It does not necessarily write sensible code that is architected in a way that makes sense based on what it does. I just watched it do a major rework of a couple thousand lines of code by keeping the original organization and kludging up an adapter to make old code have new semantics.

I would expect that this approach, coupled with lots of fun asking for changes and none of the grunt work of actually thinking about the result, could result in exponentially increasing amounts of mess.

I haven’t used a recent Anthropic model - maybe it’s better at this.

> Why would the volume that any of this be increasing exponentially?

Because the limiting factor for software has always been the supply, not the demand. When the average human engineer would ship 100 lines of production code / week, you could only afford to do the most critical things. But if code gets cheaper to produce, the projects that were marginal become worth doing, and the projects that were obviously insane become marginal. And that's exactly what is happening as models get cheaper and better, leading to the frontier of worthwhile projects expanding rapidly.

> And what are all the engineers doing when (besides the model quality) their products don't seem to be changing very much?

That's got some nice But other than that, Mrs. Lincoln, how was the play? energy to it!

Engineers are working on multiple sessions, and LLM is doing most of the commits/pushes. This is becoming norm at big techs.

If you are wondering what these changes are, you can take a peek at https://github.com/openclaw/openclaw/commits/main/

This isn't to say that such pace of iteration is good or bad. That's a separate discussion.

For one, they have the internal models that us normies don't have. Also, machine learning as a field is probably the most automate-able field for AI. It's 100% on computers without "real world" collisions at all, AI can do the whole stack today even with publicly available models. And since it's so empirical, you can make a lot of progress by just running more experiments with more compute.

RL environments. RL environments as far as the eye can see

At some point I imagine they will be writing their own software for the entire training and inference stack. Kernels, libraries, why not? With compute so constrained it must be beneficial to optimize everything as much as possible

[facetious]

many yaks to shave. many bikesheds to paint.

if you're paid by the line, why not go to town...

If it's anything like the code it generates for me, it's thousands of lines of throwaway slop for a dashboard I needed to vizualize something. Or if it's on code that is actually important it's a single line fix with 10 lines of comments explaining the diff (not explaining the new behaviour that someone might want to see, explaining the diff vs the old behaviour that no one coming to that code in the future will ever care about)

They’re designing custom silicon and solving millennium problems, maybe some of this code is in support of that.

Can’t roll out fusion powered data centers in 2030 without a simulation engine.

> Why would the volume that any of this be increasing exponentially?

Surely it's obvious?

Slop cannons firing at a rate so high no human can hope to restrain them.

Such a colossal volume of slop that even the most well engineered, efficient technology on the planet, written by one of the greatest coders of all time, is no longer sufficient to contain it.

They are using one of the oldest tricks in the book, rapid evolution as per Nature's handbook for how to constantly improve. By allowing the millions of monkeys^W AI agents total autonomy to "Throw Things at the Wall and See What Sticks"(TTWSWS, TM), this has lead to unprecedented and amazing progress towards AGI.

In doing so, they obviously need to keep track of the myriad of changes, hence the requirement to ensure Git can scale up.

(I'd like to think /s, but you know what, maybe not)

Everytime you use sites it should record the code, for example. machine speed code needs machine speed vcs.

It's AI slop. AI coding agents write much more voluminous code, in my experience. The base code is more expansive, and there are more tests, and there are many, many more commits as you keep fixing and fixing and fixing over and over and over.

becuase devs stop coding by hand and start prompting AI even for smallest of tasks, for example "hey codex, check grafana alerts and tell me x, y, z" instead of navigating it by hand and figuring out in grafana UI

It's the billions of scripts we used not to commit. And billions more.

RL environments

Realistically, lots of it is probably also just duplication. Why adhere to DRY and abstractions if the LLM can just regenerate relatively low level code whenever I need it? I don't even mean this in a disparaging way or anything, I found myself falling into the same habit of just generating very problem-specific tools and processing pipelines.

Of course, then the question is if it's even worth committing them - you might as well just commit the design spec and let the model generate ephemeral code to run this whenever you need it. For now, I almost consider committing generated code a caching step in some sense, so you don't have to spend the tokens and time to generate it again.

Once super fast and super cheap tokens become more ubiquitous, however, I expect this to change.

Anyone who has fallen into the ADR pit with agents could tell you this. Its just slop, slop to fix slop, docs about slop, slop to fix the docs, etc. 600 commits and 200k LOC/Docs for software that used to be 15 commits and 10k LOC +README and no real value to be found.

Or it's yet another iteration to get another test with overbuilt providence catalogling, boated code, overbuilt nonsense. Suddenly you're 2.5 Billion tokens deep and you just wonder "What the actual Feck did they do, how did they burn that many tokens? It's just a web app with a plugin system, my god."

Maybe it could be faking code and ai usage?

I've seen it on other workplaces, but from what I see from open ai and anthropic, the code shouldn't be as extended.

But maybe I'm crazy lol

Naive to think you can tell whether a human or their unreleased model wrote this

Haha, I'm also building a code forge (at eol.sh, just a placeholder is there now). I like that you don't look like yet another Github clone, which is my primary frustration with the alternatives.

Is this related to jujutsu? It's not mentioned in the landing page (and oddly enough, Git isn't either)

You might be missing the point.

About 7x longer than Linus took to develop Git.

It is truly a strange time to be alive. I've made systems in the past month that I've wanted to do for years, and they're astronomically better than I would have been able to rush together had I found the time. And I'm even trying to be tempered and work out more careful approaches to some of the folks I've seen.

Because monorepo people are embracing the light, while the other are stuck in darkness ? Who knows;

And then you have companies like Microsoft who invented software development at scale who still use git

Some companies grow into git

They would be hitting different problems. Taken to a ridiculous opposite extreme, think about your most recent project. Think about having it organized into a separate git repo for every file. One file per git repo. Absolutely ridiculous. You'd need a bunch of glue programs to deal with the pile of git repos you now have. How do you handle the problem of different branches for every file? You need some sort of orchestrator. It's a just a thought experiment so you wouldn't actually do that, but at Google, Facebook, and now OpenAI scale; that gives you some idea of their problem and what they're optimizing for. Orchestrating between a bunch of different repos is a different problem entirely but a monorepo solves a lot of problems while creating others. Some are more solvable than others.

This is what always scared me about monorepos. While I'll never reach the scale of big tech it was always a nagging feeling that I'd hit some limit. I know that is less likely to be a problem with smaller component based repos and if something goes wrong only that component is impacted.

The non-agentic coding take is that a monorepo makes code sharing a lot easier. Especially in my case with OCaml front to back, I can just share protocol.mli files between parts of the code without duplication or vendoring my own repos.

The same is really true for agents. All code in one place makes it faster and more reliable to load the proper context for coding tasks.

This is obviously just a response to https://www.anthropic.com/research/redesigning-source-contro.... Probably no one in the chain of writing this even thought about your question.

Instead of keeping it simple, they decided to go stupid.

It's an asset because it's a demonstration that their technology works. It would be stupid for them not to tokenmaxx even if that was more efficient. Kinda like you don't want an Apple salesman to be using an Android device.

This thing aside... IDK, I used to think that there's no way to manage such a mess but apparently there is. Or rather, it starts to seem plausible that models will evolve faster than this mess, and once it becomes unmanageable, you can simply ask AI "make it better, no bugs please" and it'll mostly work.

It's becoming harder and harder to justify my own existence as a software engineer. It's surreal that that I dedicated years of study to prepare myself for a job that's being automated away.

Of course the demand for human developers won't drop to 0 but it'll be limited to a handful of industries where even small mistakes are costly, like aerospace. But then let's be real - what percentage of currently employed devs are competent enough to write such code?

Because this kind of growth is how they get to RSI.

Not really. In fact it's fairly mild given OpenAI's size. For my personal work I've stopped even counting code changes in locs/commits and started looking at disk size changes.

> Technical details aside, this volume is ridiculous. How on earth do they see this kind of "growth" as an asset and not a liability?

That coding volume is a liability only for human engineers, with their limited memory, short attention span, tiredness, and quirky coding preferences. LLMs don't have any of those problems.

wait til' they learn about zstd!!

I thought so too. I understand the TLA+ part but Lean not as much.

More than two

This doesn't work if the pulls are happening in swarms of ephemeral sandboxes.

Also, maybe FUD, but is there anything useful to learn from (p)npm other than cautionary tales?