I am pretty tired of this analogy because it does not hold up to scrutiny. The purpose of a programming language is to describe a logical routine in deterministic nonambiguous language. A program is a set of nonambiguous instructions. Heightening levels of abstraction traditionally did not result in less understanding of the program's high-level routine.

An example: 'read input from CLI, do this specific transform on it, send log with this text to external service, then output transformed data to CLI' is a program. Going up the abstraction levels from assembly to Ruby, you always know the "What" of the program, while you understand less of the "How" at each step. This is not the case with LLMs used in the common way. The problem with LLMs is that you no longer have a grasp of the "What", because you are not reading the code; you may have memorized the ambiguous English "What" that I wrote above, but that is not sufficient to understand the true behavior because English is not sufficient to represent it; it must be represented in a programming language. (What is 'read'? What is 'send'? What happens with errors?) By the time you have sufficiently represented the program in English to be nonambiguous, you've written more text than the code would have been, with just as much rigor.

So LLMs represent a fundamental difference to traditional abstractions: the user has lost the understanding of what is actually happening, because they are prompting ambiguously, and thus they cannot possibly have a grasp of the behavior, because the behavior is not defined in their prompt. In other words, they are programming in a new programming language that has a ton of undefined behavior that just randomly happens. No one could understand the What of their program when using such a language, unless they compiled it to a nonambiguous language and then understood that instead.

Of course it is possible to read and understand the code output by the LLM. It is even possible to build a whole knowledge graph in your head, as you traditionally would, and have a pretty full understanding of the whole thing. But, you are always doing this with the outputted code, not with the inputted prompts. The prompts are not analogous to a higher level of abstraction in this way; they are analogous to JIRA tickets. You don't have to read the assembly to understand your program, but you do have to read the LLM outputs.

The other issue is that the above paragraph's process of understanding is discouraged. The time taken to fully understand the outputs approaches the time it would have taken to write them yourself, so is very rarely done, and that increasing rarity of understanding is what we are concerned about. The programmers are moving from an understanding of the program into an understanding of the JIRA tickets that produced the program; they are becoming product managers. The thing is, currently you still need someone who understands the program beyond the level of a product manager in order to retain maintainability and quality. Maybe in the future you won't, but right now you do.

No. Nada. Wrong.

With compilers, you still had to think in depth about the code, write it, develop and maintain muscle memory, understand what you were doing.

Many are not doing any of that, and coding is a skill you need to constantly practice.