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.
This is in some ways a circular argument / problem.
Because, what does a well-specified formalisation of a problem solution look like? It looks like a programming language.
Since COBOL, the dream has been a language which is formalised for computers while being understandable and able to be written by "business users".
We've been promised this future by COBOL, Visual Basic, SQL, and many others.
And what does the reality look like? It looks like the business users being upset by the fussiness that formalisation adds.
That's why Excel is still king.
Does adding better visual descriptors of program execution really help communicate solutions?
LLMs are actually a great bridge between, "Here's an idea" and "Here's the idea formalised as a set of problem and solution statements".
They're really good at it. Claude Sonnet 4.5 will output a dozen pages of formalised steps for solving a problem that acts as a good bridge between the domain expert and the programmer.
It makes mistakes. It misunderstands things sometimes. Sometimes it understands things better than the programmer or the domain user, such as when it recently corrected me on my understanding on the OAuth2.0 spec, because I was using a non-standard parameter that Cisco Meraki had mistakenly added to their documentation.
Right. If an LLM is capable of writing good boilerplate code for you then your programming language is too low level. We need higher level languages which abstract away most of the repetitive patterns. What would a language look like where the code has much higher "entropy" but is still human readable and maintainable? Like could we design a language that combines all of the productivity advantages of APL / Lisp / Prolog but is still usable by average developers?
Programs aren’t text that you run on a computer though. Programs are text that describe an abstract syntax tree which encodes the operational semantics of the thing you’re computing.
Maybe (likely) you could come up with a more convenient set of operations, but I don’t really see how expressing that as plain text ast is really holding things back.
> Can we formalize that abstraction such that the prompt is an exact specification, just, at a super high level
That's another programming language. And if you think of an even higher level, where you e.g. specify, that you want to get data from a server in a format, and leave it to some other specification how to do that, that is called a program/library. You get that for free from e.g. Github or your OS repos.
> Can we formalize that abstraction such that the prompt is an exact specification, just, at a super high level?
... And you want a representation of that abstraction to persist on disk?
... But it shouldn't be "text"?
Why not?
And how will you communicate it? You want to prompt in lossy, error-prone, inexact text, and then trust that an opaque binary blob correctly represents the formalization of what you meant? Or go through feedback cycles of trying to correct it with more prompting, but without the ability to edit manually?
> but no amount of text-generation gets around the fact that maybe text generation is... not... what we should be doing, actually.
Well, sure. But that isn't a problem with text; it's a problem with boilerplate in our designs.
> 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.
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.
I find the back and forth more productive. Lots of up front requirements and docs is like waterfall. You do everything up front and don't realize until implementation time that the design is unclear, has flaws and contradictions, etc.
Often it feels more efficient to take shorter steps, try something in code, we how it looks, update docs, show a demo, etc. That was true before LLMs and I think LLMs make it even more true.
> 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.
ajkjk|4 months ago
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.
xnorswap|4 months ago
Because, what does a well-specified formalisation of a problem solution look like? It looks like a programming language.
Since COBOL, the dream has been a language which is formalised for computers while being understandable and able to be written by "business users".
We've been promised this future by COBOL, Visual Basic, SQL, and many others.
And what does the reality look like? It looks like the business users being upset by the fussiness that formalisation adds.
That's why Excel is still king.
Does adding better visual descriptors of program execution really help communicate solutions?
LLMs are actually a great bridge between, "Here's an idea" and "Here's the idea formalised as a set of problem and solution statements".
They're really good at it. Claude Sonnet 4.5 will output a dozen pages of formalised steps for solving a problem that acts as a good bridge between the domain expert and the programmer.
It makes mistakes. It misunderstands things sometimes. Sometimes it understands things better than the programmer or the domain user, such as when it recently corrected me on my understanding on the OAuth2.0 spec, because I was using a non-standard parameter that Cisco Meraki had mistakenly added to their documentation.
nradov|4 months ago
raincole|4 months ago
Every time people attempted on this they ended up with a programming language that is harder to use than usual programming languages.
SQL was marketed as "fourth-generation programming language."
Two other examples that come to mind: Github Actions, and node-based visual programming.
davemp|4 months ago
Maybe (likely) you could come up with a more convenient set of operations, but I don’t really see how expressing that as plain text ast is really holding things back.
1718627440|4 months ago
That's another programming language. And if you think of an even higher level, where you e.g. specify, that you want to get data from a server in a format, and leave it to some other specification how to do that, that is called a program/library. You get that for free from e.g. Github or your OS repos.
sirwhinesalot|4 months ago
zahlman|4 months ago
... And you want a representation of that abstraction to persist on disk?
... But it shouldn't be "text"?
Why not?
And how will you communicate it? You want to prompt in lossy, error-prone, inexact text, and then trust that an opaque binary blob correctly represents the formalization of what you meant? Or go through feedback cycles of trying to correct it with more prompting, but without the ability to edit manually?
> but no amount of text-generation gets around the fact that maybe text generation is... not... what we should be doing, actually.
Well, sure. But that isn't a problem with text; it's a problem with boilerplate in our designs.
mentalgear|4 months ago
> 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.
falcor84|4 months ago
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/
suioir|4 months ago
https://en.wikipedia.org/wiki/Type_III_error
throwway120385|4 months ago
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.
daxfohl|4 months ago
Often it feels more efficient to take shorter steps, try something in code, we how it looks, update docs, show a demo, etc. That was true before LLMs and I think LLMs make it even more true.
indymike|4 months ago
marshfarm|4 months ago
This is not in any way similar to what humans do.