Feel this strongly. That all of the "autocomplete"-style improvements that LLMs to programming are indications of massive deficiencies in programming: we're in many ways stuck in a ~2010-era model of what programming is, which is actually quite medieval and useless.

Probably programs as "text that you run on a computer" is, long-term, not how anything is going to be done. After all, what is a prompt but a (lossy, error-prone, inexact) specification for a program, or at least part of a program, before you go in and modify it by hand? The code itself is just an interchange format, no different than JSON. Can we formalize that abstraction such that the prompt is an exact specification, just, at a super high level? AI-text generation makes it faster to write text, but no amount of text-generation gets around the fact that maybe text generation is... not... what we should be doing, actually. And the LLMs are going to be better working at that level also.

I really wish the people geeking out over LLMs would be geeking out over radical new foundational ideas instead. Picture Bret Victor-style re-imaginings of the whole programming experience. (I have loads of ideas myself which I've been trying to find some angle of attack for.) Hard work at improving the world looks like finding radically new approaches to problems, and there are loads of ways to make the world a better place that are being distracted from by the short-term view of working entirely in the existing paradigm.

> Finally, I would like to mention an irony. If you talk with people who use AI agents a lot for software development, they will tell you that the quality of the requirements and the architectural design and documentation make a huge difference regarding the quality of the code produced by the AI agents. Thus, it would be necessary to put more effort into phrasing requirements and designing a good architecture.

> I mean, for at least the last 3 or 4 decades, one of the biggest impediments we had regarding fast and reliable software development were poor requirements and poor architectural design. Human software developers had the same problems with poorly designed and documented requirements and architecture for the last decades, but nobody cared. Instead, the only complaint was that writing software would take too long.

> Writing production code is a completely different game than (vibe) coding a prototype. To get this right, you need profound knowledge of the programming language, of its ecosystem, of the dos and don’ts of good software design and development, of the additional bolts and screws needed to make the software production-ready, and much more.

Having spent some of my career as an SRE, I would argue that what distinguishes production code from it-worked-on-my-machine code has very little to do with the things at the start of that list and almost everything with the "bolts and screws needed to make the software production-ready", and particularly the 12 factors [0]. With my anecdata, I've had a much more productive time maintaining in production systems written by junior coders who only started using that particular language a few months ago, but are eager to take direction, than experienced developers with profound knowledge and strong opinions held tightly.

With this in mind, I've been quite productive doing "vibe engineering" [1], rigidly controlling the code from the outside as mostly a black box, with extensive precommit testing, focusing my code reviews on preventing weird "going off the rails" issues and adding new tests against them, while not worrying at all about code style.

[0] https://12factor.net/

[1] https://simonwillison.net/2025/Oct/7/vibe-engineering/

Not the same thing, but reminds me of Type III Error: providing the right answer to the wrong question.

https://en.wikipedia.org/wiki/Type_III_error

Suppose that an LLM would produce excellent, production-ready code automatically given high-quality architecture and design documentation and proper requirements. Could we offload the code generation to the machine and focus on producing architecture and design documentation? And would that provide meaningful improvements?

I don't know the answer to that. But it's an interesting point that's buried in the article is that companies like to shortchange that part of the process, and it's that part of the process that is the most important to getting good code out of an LLM. I suppose part of the problem with using LLMs is that the providers have a vested interest in collecting fees that are barely less than the fully-loaded cost of the development staff.

So it'll be interesting to see if some companies find themselves ratcheting up on the documentation, and then revisiting the need for the LLM when the LLM pricing rises to the maximum the market can support.

> They respond in much smarter ways than traditional multi-layer perceptrons or traditional RNNs like LSTM networks because their attention mechanisms helps them to make much better sense of the input they were provided by selectively paying more or less attention to different parts of the input (including their output generated so far). This is similar to what humans do.

This is not in any way similar to what humans do.