>> "we're already not writing machine code by hand for 50 years, how is AI different from a higher level language?"

I never got that argument. Compilers are formally proven, deterministic algorithms . If you understand what compiler does, you can have pretty good idea what it will produce. If it doesn't do that, its a bug. Definition of correctness is well defined by semantic equivalence.

LLMs are none of that. Its a fuzzy system that approximates your intent and does its best. I can make my intent more and more specific to get closer to what I want, but given all that is just regular spoken language its still open to interpretation. And all that is still quite useful, but I don't get the assembly language comparison here.

Because compilers are only deterministic when using ahead of time compilation, without profiling data, and always the same set of compiler flags.

Introduce dynamic compilation, profiling data, optimization passes, multiple implementations, ML driven heuristics, and getting deterministic Assembly output from a compiler starts to get harder to achieve.

You are right about that but that's talking about what you generate but not what the output does. My point is that the compilers still designed to preserve semantic equivalence. semantic equivalence makes sense here because there are semantics well defined for both input and output. That bit is supposed to be deterministic. If something breaks that that is a bug.

I just don't think comparing with compilers is a good argument.

Semantic equivalence breaks down with UB optimizations.

and hence reading code is unnecessary because how well LLMs understand and converts my prompts is almost equivalent to how well compilers can understand programs and turn into assembly. The prompts carry equal amount of ambiguity as the prompts I would write to define the behavior and want.

By extension, does this imply that all the HLL advocates from decades past were shilling for compiler companies?