[Animats]

The upper bound on program complexity used to be the power of the human mind. "Vibe coding" can break through that barrier. But not because the problem being solved needs that complexity. Because the process does not drive itself towards compact abstractions. It's the AI-powered version of the scaling problem Brooks described back in "The Mythical Man-Month". The combinatoric problems get worse with scale. Concretely, multiple similar implementations of roughly the same thing appear in different parts of the project. This is a known problem of vibe coding now.

We need some way to make AI-driven coding strive for parsimony.

[conartist6]

Why would it? It has optimized what it was built to optimize: this is the token-selling industry. Take note that the people hawking the dream of a gold rush are not actually mining but selling shovels

[ashdksnndck]

Same issue happens in models trained by organizations who aren’t selling tokens. I believe it’s because being parsimonious is simply harder. Achieving the task at hand independently and declaring the job done is easier than building an abstraction and reconciling between every use case.

[radarsat1]

Agreed. I've noticed this happens without fail in any project driven primarily by "tickets" and "sprints". Finishing the immediate task ends up taking precedence over future concerns that cover a wider scope. On the other end of the spectrum it's easy to spend too much time at the beginning humming and hawing about the best, most future proof design, because you just know you're not going to be able to easily fix it later. As is often the case, the right approach is somewhere inbetween, which is partly why it's a hard process to automate. you're constantly making judgement calls.

[marcus_holmes]

I have a vaguely-relevant war story.

1998 - Huge business, re-writing some vital piece of the platform in the middle of Y2K. Contract coders are expensive but also the only available people to throw at this.

The architect had mapped out the entire system down to class/method level. They'd produced a huge list of classes and methods that needed to be built. So the company hired a bunch of contract coders to build said classes and methods, including your humble protagonist. We were each given a list of methods to write up - parameters, operation, expected output. We wrote them up, and ticked them off the list. We were not briefed on how they interacted. There were no tests that we could run. There was apparently no-one checking that what we wrote in the method actually matched the spec. This was before git, so version control was extremely rough, and also before JIRA (iirc the list was an Access database).

We all realised very quickly, like the first week, that this entire project was doomed. But we were getting paid a lot of money to do this, so we just did it. It got really boring really quickly. Every day we wrote a bunch of methods, and next day got a list of the next set of methods to write. The lists just kept coming, with no idea how long the master list was, or how the classes interacted with each other, or how the system actually worked, or anything.

I left after a month. The money was good, but the boredom was driving me insane.

I learned later from friends who stayed that the whole project was canned a couple of months later when it became obvious that this was a complete waste of money and would never work.

Whenever I see a project manager staring at JIRA instead of talking to their people or looking at the codebase, I'm reminded of this project. And your comment reminded me of that ;)

[zeafoamrun]

Crazy to think that if it was specced out so well, a modern LLM would make short work of the whole thing. The things we used to get paid for!

[conartist6]

lolol you're joking right? as a joke it's funny. If you think thats really what it sounds like when a project's design is well-understood... ... ...

[mpweiher]

Poe's law continues to be a bitch...

[tekacs]

Labs are trying to make long-horizon work. Even if you're a coding agent, adding more and more surface area is distracting to that goal. There is reason that RL over long traces should, at least in principle, optimize for building in ways that help the result fit in the model's context window.

A meaningful risk of course is that the tools available to the model (ripgrep + fancier semantic approaches) allow it to do a good job of reasoning over things much larger than its context window, and so it doesn't pay the penalty sufficiently to fix it.

[conartist6]

Does that not sound a little silly to you when you say it? Should I invest in becoming a memory athlete as a way of becoming a better software engineer? ...or should I learn how to build and use tools?

[gnatolf]

While I don't disagree, memory certainly was more of a restrictions on us humans than it is on llms. Therefore, the answer may not be as obvious as it seems. We build abstractions to reduce (memory) footprint of features, right?

[chongli]

Humans built codebases many millions of lines long, well before LLMs existed. Human memory has not been a restriction on us in a long time.

Look at all the libraries full of books we've built. It's useful for more than mere training sets.

[conrs]

I think the trick here is plural; I guarantee no single human knows all 1 million lines. Note this is different than knowing how to orient yourself in a million line codebase quickly.

The limit here I think the ancestor comments are getting at is cognitive load, which is real and measured. We only have so much memory to devote to a "stack" when executing, and it's usually quite constrained.

[FuckButtons]

While you’re not wrong, this is also simply mechanical, the context window is the root problem here, if the llm doesn’t happen to have read implementation n of a thing that it needs that session, well now you have n+1 implementations.

[nomel]

All the open weight models, that are given away for free, across orgs and even nations, are using the same methods to achieve high performance.

What's more profitable, optimizing for inference time or optimizing to increase inference time by increasing token count?

[ColdStream]

The question is that if it can go beyond the upper limit of human mind complexity, would we be able to understand it or use it?

I cannot remember who it was but there was an author who was traveling with their dog. They noticed that their dog would always pee on various tree to mark them as their territory. On their travels they ended up need some giant Red wood trees and figured, "I want to give my dog the ultimate claim of territory."

So he took his dog up to the Red wood tree and it did nothing, instead the dog wandered over to a smaller sapling and peed on that instead. The problem was the Red wood was so big and alien to the dog, it didn't recognize it as a tree.

I do wonder how many things are like that in our universe, that even if we could see them, we just wouldn't be able to understand it because it just goes beyond what we are capable of understanding. We think we have a grasp of the universe and use models to codify it but that is no guarantee that we can truly 'get it'.

Could higher level AI code be like that, would we know when we see it?

[psychoslave]

If we would be able to act that consciously, humanity would be flourishing without anyone sent to war or starvation.

It doesn't look like we are that bright, at least collectively. And if they are individual which are really above everyone else on that matter and the rest, like maybe you but definitely not me, then their individual power seems to be unable to move us all away from our collective ill habits.

[jambalaya8]

Excellent post.

[fooqux]

> The upper bound on program complexity used to be the power of the human mind.

Maybe for simple one-person projects. We've long since developed methods and models to allow us to make things bigger than ourselves. Linux, SAP, etc. These software projects are not held in the mind of a single developer. But we use structure, rules, and other tools so that the pieces still fit together.

[RevEng]

They said "the" human kind, not "one" human mind. Even with structures, rules, and other tools, we are limited in the amount we can abstract, comprehend, and communicate. As projects get larger, we inevitably see a friction develop where coordination breaks down and we turn to isolation and responding to failures at the boundaries. This is where complexity in design of an individual system ends. Larger ecosystems aren't designed or coordinated - they emerge organically as each tries to adapt to the other. If only we could handle such complexity, we could design efficient systems that don't suffer from the same waste.

[fooqux]

Fair enough.

I do worry what that will mean for projects such as Linux though. Not that I think it will die or anything, but rather that it will become so fragmented that forward movement ceases.

[docmars]

>We need some way to make AI-driven coding strive for parsimony.

This is the single reason why my experience with agentic development honestly kind of sucks, and wastes so much of my time.

The simplest prompt can result in the most verbose garbage ever produced, and scope-creep nobody's every seen before.

AI has a huge cognitive load problem right now. It's no wonder why so many devs say they're completely exhausted after a few hours, and not in ways they were before they picked up agentic dev.

[TacticalCoder]

> "Vibe coding" can break through that barrier. But not because the problem being solved needs that complexity. Because the process does not drive itself towards compact abstractions.

It's the infinite AI monkeys at a computer keyboard phenomenon.

Or the car on the highway that bumps left and right on the guardrails until, eventually, it arrives at its destination and nearly everybody is amazed at that great success.

The AI kool-aid drinkers are going to answer: "but that's how human code too".

And I'm really not sure about that.

[bluefirebrand]

It's perhaps how some humans code but frankly if you have those people employed to build software for you, you have big problems

[pishpash]

That's some idealistic nostalgia. Software is generally poorly built today, and it's evidently not big enough a problem to fix.

[munk-a]

Large companies that can keep themselves alive with regulatory capture - absolutely. For smaller companies that need to compete the software quality and ongoing cost of maintaining that software is a real consideration.

That isn't to say software is perfectly built, but it's usually pragmatically built to balance costs of development and correctness - well chosen abstractions let us push up both qualities at once.

[tibco]

I think every type of company has ways to workaround software quality. B2B can tend to define the bug as the feature or too low priority.. B2C can often decide backwards compatibility simply doesn't matter and just replace things with other things with only some actual feature overlap, etc.

[khafra]

A friend of mine built just built a project for doing something like that, although it's built on enforcing a spec rather than elegance: https://medium.com/@joeldg/architecting-out-of-the-vibe-how-...

[mpweiher]

We need programming languages that can express the problems at densities similar to the English language prompts.

So: better modularity.

https://blog.metaobject.com/2019/02/why-architecture-oriente...

[petra]

That's an interesting question.

What happens if we take the most abstract libraries in any given field - and:

1. Bound to the llm to only use those as building blocks. Does it affect his reasoning ? Will it think more abstractly ?

2. Train the llm on those, so maybe it will get a feel for abstraction ?

[sroerick]

The Allegorical Agent-Aeon?