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

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

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

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

reply
It's perhaps how some humans code but frankly if you have those people employed to build software for you, you have big problems
reply
That's some idealistic nostalgia. Software is generally poorly built today, and it's evidently not big enough a problem to fix.
reply
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.

reply