Tiota Sram on Nostr: "I can understand the output and see whether the logic is correct" shows a poor ...

"I can understand the output and see whether the logic is correct" shows a poor understanding of programming. If this were true, you'd simply generate the output itself, and skip the program. The entire point of writing a program to do something instead of just doing it yourself, *especially* in this age of generative systems, is to have the program be robust enough to handle cases that you do not inspect, either because it would be tedious to do so, it because it would be impossible as you can't predict what inputs users will supply. Properly constructed, a program is a tool that has *predictable* and *well-understood* behavior even for many cases that the programmer anticipated but did not check explicitly, and the programmer can be confident that it has this extrapolative behavior because the programmer has a good mental model of *how* the program works. Given your admission that you don't know the languages you're using, you definitely do not have a good mental model of how the programs work, so you're inspecting a few cases and then assuming the process is probably sound based on a poor/shallow mental model of the program, which is a great recipe for eventual disaster, pretty much no matter what you're using the code for (even hobby/art projects have significant reputational failure risks).

To address the larger point about compilers, which I've certainly wondered about myself, the qualitative difference is that compilers translate code from one language with well-defined semantics into another which also has well-defined semantics. This means that we can verify their correctness, make progress by fixing any correctness issues we find, and such fixes can be applied at scale by recompiling code. Many iterations of that process produce high-quality compilers, which give us strong assurances that as long as we understand the semantics of the high-level language being compiled, we can write programs with predictable behavior once compiled without needing to inspect or even understand the assembly code. Compilers enable a division of labor between those writing high-level code and those checking compiler correctness, and this is only possible because the abstraction they provide is not very leaky (in the correctness domain at least; it's quite a bit more leaky when considering performance, which is why we still teach assembly language in school).

LLM-based programming has basically none of these properties:

Nobody will every be able to give any guarantees about the semantics of the programs LLMs spit out, not can we even make progress towards such guarantees. Fundamentally, the translation performed by an LLM is between input prompts and programs, and "input prompts" is not a domain with any reliable formal semantics. Worse, I'd wager most vibe coders probably do not retain the sequence of prompts & hand-edits made to construct their programs, so it's like throwing away your source code as soon as you compile it. Even if someone did retain this stuff, the models used are mostly in the cloud without strong versioning or archiving, and thus with little ability to reproducibly query the same model in the future. Most models are explicitly tuned to *not* provide the same output multiple times for the same prompts anyways.

If all these things were true of compilers, I'd be against them today, and so would a lot of people. On the other hand, I think it would actually be cool (modulo a few other big ethical issues) to work towards LLMs for coding that actually had some of these properties, but I don't foresee those with the resources to do so doing that, because it undermines a lot of their AI hype, and because it sounds like an actually difficult project compared to tuning up an LLM (which to be fair isn't trivial).