This sounds like someone who hasn't used compilers for long. I remember plenty of fun compiler undefined behavior that had essentially non-deterministic outcomes.
And actually using power tools in the real world is pretty uncertain, try running a straight starting cut with a multitool against wood grain and then come back and talk to me.
Sure, but those were likely bugs in the compiler's codebase that in principle could be isolated and fixed. With an LLM there is no bug and there is no fixing procedure: all outcomes are context-driven and (more or less) nondeterministic by design. I don't mean this in a dismissive way, but there is clearly a difference there.
Another way to think about this: if the compiler has a miscompilation, the user is usually not blamed for the mistake (unless gross lack of QA). If the LLM makes a mistake, the user gets full blame. Thus, slowly combing over the output is required.
> And actually using power tools in the real world is pretty uncertain, try running a straight starting cut with a multitool against wood grain and then come back and talk to me.
I especially liked table saws and backhoes as examples of _automation_.
That's not a good counterexample.
Formal languages are called 'formal' because they have rigorously defined semantics. The 'undefined' parts, if anything, reveal that most of the expressible sentences have clearly defined semantics, rather than lack of them.
In addition, the semantics of 'undefined' behaviors is not 'non-deterministic' in the literal sense, since it is, well, undefined.