That comic, while funny, is making a pretty weak argument (and basically reverses that other joke that the highest-level/sixth generation programming language is a graduate CS student).
Obviously machines need code to execute. But humans don't need to write every line of it. Transitioning to using (future) LLMs as a programming language is transitioning from the role of a programmer to the role of a customer (or at least PM). Conversely, as a programmer (or technical manager), if your job is to extract a precise spec from a customer that doesn't know what they want, your job is exactly the one "LLMs as a programming language" are going to replace.
The point is that explaining the requirements in a precise manner to LLM is literally coding the problem in a higher level language; the LLM is acting as a compiler for that precise description in English.
I actually am sympathetic to your point about the value of LLMs in programming, but more from the perspective that LLMs can help us to do the precise description gradually and interactively in a much better way that a dumb REPL.
Have you interacted with a Common Lisp, Smalltalk, or Prolog REPL. That’s what programming should look like, but with other languages, you have to mostly visualize these interactions or do with the rougher edit-compile-run cycle.
If you think your job as implementing only specifications (in form of Jira tickets), then maybe you don’t see the difference. But more often, you’re trying to define the problem in the first as the customers can only describe the current situation and needs. The job is to design a system that could satisfy these needs and going iteratively from natural language to code, removing ambiguity in the process. Stopping midway in the process and hoping an LLM can continue down is just playing slot machine with code. And then there’s the whole system evolution and maintenance.
And the tragedy is now we'll be allowing economic rent on something that has been free for decades but most people refused to use. /jaded lisp and prolog programmer
That was kind of my point, too: no LLM will solve your problem zero-shot based on a vague description. Iteration will always be required. A good enough LLM will ask you clarifying questions, write prototypes, accept your feedback, etc., and as you iterate, you get closer and closer to a program you want without writing a line of code.
The "precise" part is not even necessary. In short, if 90% of the time guessing the intent works, then I may want to use that system anyway. The projects almost every one of us work with are underspecified anyway, but we have a decent intuition of what should happen (or we just don't care in many edge cases and let the default failure happen). We can read the result and say "is the good enough?" and iterate as you described.
Obviously machines need code to execute. But humans don't need to write every line of it. Transitioning to using (future) LLMs as a programming language is transitioning from the role of a programmer to the role of a customer (or at least PM). Conversely, as a programmer (or technical manager), if your job is to extract a precise spec from a customer that doesn't know what they want, your job is exactly the one "LLMs as a programming language" are going to replace.