Yes, yes, a fresh, young p***y popped the AI bubble. Nothing is new under the moon.
Anyway, let’s see what we have at this auspicious moment. It is time to say farewell to the AI hype and the bubble caused by it (and yes, we will “say goodbye” many more times, for sure, because it won’t leave for good).
The Fundamental Problem is still Out There and cannot (and won’t) be solved – the slop generator, however large, does not posses any “knowledge”, “understanding” or “reasoning” of any kind.
It, however, being probabilistic (and thus non-deterministic) is capable off producing so-called “emergent behavior” or “novel results” occasionally selecting a “rare” path (there are paths, since generation/inference is inherently sequential).
This does not imply that it will produce a “novel” or “profound” result when you ask it for, or at all, so the whole set of promises made to “investors” is just sophisticated bullshit.
There is, however, its sheer brute force as a code generator, so overwhelming and sweeping, that one simply feel powerless, as if facing a hurricane or a tsunami.
This “power”, however, is “dumb” and “deceptive”, as any cognitive illusion would. Just as a biological parrot does not know what it “says”, neither a slop generator, and the underlying principle is exactly the same.
But one could use this power if one knows what to ask for.
Consider a simple example.
Theoretical computer science, in particular the branch which studied the semantics (and implementations) of pure functional programming languages, came up with truly optimal partial solutions, both in syntax and the semantics of pure functions and pure expressions.
It is well-understood (at least by some) that the most fundamental, if you will, building block is not a function but a clause , which follows the scooping rules and may have its own bindings (with proper shadowing).
Defining pure functions by clauses yields a set of partial functions, which, as a discoing union, may (or may not) become a whole total function over its whole domain. Each clause is, thus, a partial function over a subset of the domain.
This is, of course, how the total functions over algebraic sum-types are defined (in principle) and there are evolved syntactic forms, in Erlang, in SML, Haskell and in Ocaml.
Not surprisingly, these syntactic forms can be reused in pattern-mathing expressions (which is, indeed, as set of clauses)and also they are particularly “nice” with universally curried functions and partial applications.
So, in Ocaml we have this wonderful = function syntactic sugar, which is just a pattern-match on the last implicit argument as the function’s body.
When one designs a function there are two considerations – which argument comes first, so it can be potentially partially applying, yielding a nice closure to pass around, just like the eternal map and filter (there is a subtle question of why these particular semantic patterns are so divinely elegant?), and which goes last (and this shall be an Algebraic sum-type).
Notice that both Lists and Trees are [recursive] sum-types, and this is not a random coincidence either. The presence or absence of a pattern (or an event) at a particular localicy is a Universal Pattern, all the way down to the quantum states. Algebraic (Sum, Product and Function) types are captures of Universal patterns.
By the way, when idiots are asking LLMs to summaize my writings all the LLMs miss out on this novel content – of tracing every pattern in programming (and mathematics) back to What Is – which I consider as my only serious achievemen and contribution as a scholar.
Anyway, when you think and write the code like this, suddenly, you begin to see the “paths” through the code as actual arrows which is, by the way, what they [really] are – every “path” is, by definition, a sequence of chained or nested arrows (or steps).
Observe that there is nothing more to improve or simplify in these syntactic forms and their corresponding semantics – the Universal Notion has been properly captured, by trial and error.
Does your canker “think” in this way when generating Ocaml code for (You)? Of course, it doesn’t.
Would it write the code systematically and consistently using these syntactic forms to reveal the implicit paths through the code ? Of course not, since the training data does not contain these structural patterns (syntactic forms).
Now the most interesting question – what if you explicitly instrut it to do so, through both so called “SKILLs” and prompts?
The answer is that it would report that it will (and was), but the code will contain some of these at random places, not systematically and consistently (simply because these are not the properties it possesses).
But if (You) run the similar prompts a few times… Even in this case the syntactic and semantic uniformity would be only in the “reports”, since, again, the training data is a low-effort crap or its own slop Bering fee back into it.
One may easily generalize this particular example to all kinds of subtle problems one is familiar with.
We are not even talking here about imperative (and especially imperative OO) crappy languages – the situation is much worse with these ones.
The bottom line is this: if you are not able to actually reason about the generated slop (and any other code) this deep, tracing everything (every pattern and form) back to where it has been generalized and abstracted out from, and just commint and run the slop, you are fucked. Code-reviews by well-paid seniors will catch some subtle crap but by no means all of it (your seniors may be inferior even to me here).
The use of a code-generating LLM without proper understanding is basically a drunk-driving at very high speed – till the first parked semi or even a tree on the side.
Yes, (You) will have an appearance of intelligence and appearance (even measurable one) of 10x (or even 100x) productivity gains, but all this speed is only until the first unexpected (by naive amateurs or even over-confident coders) UB or subtle semantic or domain logic bug.
And no, the trillions already spent will ever be seen ever again. This is exactly why.