So, this is what is actually going on (seen as they are) in plain English.
The sheer brute-force of data-center-sized “frontier” models is so brute that it easily appears as “intelligence”.
This is still the next-token prediction based on a conditional probability under the hood.
There is no “understanding”, no “reasoning”, no “knowledge”, no “skills” (these are just the same streams of tokens).
But this is not mere a “glorified autocomplete” anymore. There are compilers, code linters and even basic static analysis tools in the loop.
They pipe the slop through the selected tooling and feed the results back into the loop, so the compile errors are being fixed for you.
This is the only real selling point. Fixing compilation errors and tests is a YUGE productivity boost, approaching a 100x meme.
There is a lot of whining and moaning on a low IQ social media, like /g/, and this is perfectly justified.
If you know what to ask and what to expect (which means you are an actual senior level programmer) you can just prompt the right things and watch the compiler and the tooling do the rest (in a loop).
If you are a clueless junior or a student, you will eventually be buried under a mountain gradually (and inevitably) added complexity which you do not and cannot understand.
The canonical and real example is actual UB in the slop in C/C++. No compiler can catch a subtle Undefined Behavior of C/C++ and non-determinism of an imperative crap in general.
Use the right, well-designed and writtern by knowledgeable, top-level academics (Leroy, SPJ, Odersky) languages for your slop. Restrict to the pure-functional subset.
The “knowing what you do (and why)” has no equivalent and no replacement in an LLM loop-based workflow. Only an appearance that everything is okay (and the crap runs).
Making code that “runs” was never been a big problem – all the crappy imperative untyped languages (C, C++, PHP, Java, Javascript, Python) constitute the proof by example.
Coming up with something that runs is not the fundamental challenge. It is that “everything has been done Right” (which Ocaml, Scala and Haskell designers are trying to accomplish).
And striving for perfection is an operational definition of an Art. No LLM “knows about” or “understands” or “can deliver” such a perfection. It just puts the next token to the end of a stream..
One more time: a datacenter-sized “frontier” models, with their compiler and tooling “loops”, are doing all the “mechanical” work, and do it at the level no human can even compete (brute force).
And This Is What It Is today.
Another level of complexity is the training data. There are enormous amount of crappy C/C++, Python and Javascript, and very few textbook-grade Ocaml, Scala, Haskell, Rust.
The classic, canonical example is Haskell, where idiots are using monadic combinators and monad transformers outsize of the parsing libraries where they belong.
No code uses the properer Hexagonal Architecture (isolating IO within adapters at the outer abstraction boundaries) and all the other nice things smart people come up with.
99% of public Haskell code is an amateur crap with unnecessary and redundant “type-level pyramids of doom” (look, ma, I am so clever).
This implies that the slop will be crappy by definition – there is, literally, no good training data for the best languages.
The model will spew the right, reassuring verbiage, but the code will not match. One has to be an actual expert to notice the subtle semantic gap between the text and the actual code.
Amateurs will stand no chance.
Aside from that, if (You) ask something well-known, a frontier LLM will output something that runs.
The bottom line is this:
Just like in any competitive sports, there are some people which are noticeably better than others. The same principle applies to prompting and vapecoding. A senior dev with a proper CS background will outrun a whole team of amateurs easily and quickly. The promised 100x is Out There (when an LLM runs your compiler loop).
This means, among other things, that there will be way fewer “programming” jobs and ever fewer well-paid ones. The times of “100k per year after graduation” are over.
And yes, LLMs today are doing what Indian oursourcing teams did, but 100x faster and with 1000x less errors (but with nasty subtle ones) for a fraction of the costs.
Let that sink in. Everything else a reasonably smart individual could simply deduce from this actual fact.
One more thing: the best, well-researched and well-designed (with necessary constraints) mostly-functional well-typed languages make an enormous qualitative difference.