Yeah, I don't understand this comparison. I've programmed for years in higher level languages professionally and never learned assembly and never got stuck because the higher level language was limited or doing something wrong.
Whenever I use an LLM I always need to review its output because usually there is something not quite right. For context I'm using VS copilot, mostly ask and agent mode, in a large brownfield project.
People keep comparing higher-level programming languages to lower-level abstractions - these comparisons are absolutely false. The whole point of higher-level programming languages is for people to get away from working with the lower level stuff.
But with the way software engineers are interacting with LLMs, they are not getting away from writing code because they have to use what comes out of it to achieve their goal (writing and piecing together code to complete a project).
My career sat at the interface of hardware and software. We would often run into situations where the code produced by the compiler was not what we desired. This issue was particularly pronounced when we were transitioning some components from being written in assembly by hand vs using a compiler.
I think the parallels are clear for those of us who have been through this scenario.
In reality, the outcome doesn't appear to be the result of "pure chaos and randomness" if you ground your tools. Test cases and instructions do a fantastic job of keeping them focused and moving down the right path.
If I see an LLM consistently producing something I don't like, I'll either add the correct behavior to the prompt, or create a tool that will tell it if it messed up or not, and prompt it to call the tool after each major change.
In the previous scenario, programmers were still writing the code themselves. The compilers, if they were any good, generated deterministic code.
In our current scenario, programmers are merely describing what they think the code should do, and another program takes their description and then stochastically generates code based on it.
Compilers are (a) typically non-deterministic and, (b) produce different code from one version to the next, from one brand to the next, and from one set of flags to the next.
To some degree you're correct -- LLMs can be viewed as the kind of "sufficiently advanced" compiler we've always dreamed of. Our dreams didn't include the compiler lying to us though, so we have not achieved utopia.
LLMs are more like DNA transcription, where some percentage of the time it just injects a random mutation into the transcript, either causing am evolutionary advantage, or a terminal disease.
This whole AI industry right now is trying to figure out how to always get the good mutation, and I don't think it's something that can be controlled that way. It will probably turn out that on a long enough timescale, left unattended, LLMs are guaranteed to give your codebase cancer.