[tcmart14]

I really hate the trying to make LLM coding sound like it's just moving up the stack and is no different from a compiler. A compiler is deterministic and has a set of rules that can be understood. I can look at the output and see patterns and know exactly what the compiler is doing and why it does and where it does it. And it will be deterministic in doing it.

[petcat]

> compiler is deterministic and has a set of rules that can be understood.

Here are the reported miscompilation bugs in GCC so far in 2026. The ones labeled "wrong-code".

https://gcc.gnu.org/bugzilla/buglist.cgi?chfield=%5BBug%20cr...

I count 121 of them. It appears that code-generation is not as deterministic as you seem to think it is.

[tcmart14]

I commented elsewhere, but that doesn't mean it's not deterministic. Deterministic means given the same input it gives the same output. Compilers can still have bugs and generate the wrong code. But so long as given the same input it generates the same wrong output, it is still deterministic.

[petcat]

Compilers can generate wrong output in many different ways. And they're all analogous to the same ways that a sophisticated LLM can generate wrong outputs.

The compiler relies on:

* Careful use of the ENV vars and CLI options

* The host system, or the compilation of the target executable (for cross-compiling)

* It relies on the source code specifically

How is this really different from careful prompt engineering, and an extensive proposal/review/refine process?

They are both narrowing the scopes and establishing the guardrails for what the solution and final artifact will be.

> proposal/review/refine process

This is essentially what a sophisticated compiler, or query optimizer (Postgres) does anyway. We're just doing it manually via prompts.

[tcmart14]

And none of that means it isn't non-deterministic. Compilers still satisfy the, given the exact same environment and input, you get the same output. It doesn't matter the number of inputs. So long as f(3, 2) always gives 5, it's deterministic. Doesn't matter what f(x,y) does so long as it always gives the same output per input. LLM generation does not do this. If given f(3,2), sometimes it says 5, sometimes 6, sometimes 1001, sometimes 2.

And we are talking compilers, not query optimizers, so I don't really care what they do.

[xigoi]

It seems that the person you’re replying to is also deterministic. No matter how many times you explain what “deterministic” means, they fail to understand it.

[discreteevent]

> How is this really different from careful prompt engineering, and an extensive proposal/review/refine process?

So different that those concepts don't even exist.

I don't have to carefully prompt my compiler in case it might misinterpret what I'm saying. My compiler comes with a precisely specified language.

I never, ever, review the output of my compiler.

[petcat]

> I don't have to carefully prompt my compiler in case it might misinterpret what I'm saying.

Yes you do. You give it flags, you give it ENV vars.

> My compiler comes with a precisely specified language.

No, it doesn't.

> I never, ever, review the output of my compiler.

Yes, that's the whole point of the exercise. Have you ever reviewed the -S output from GCC? No? So do you really know what your code is doing?

[xigoi]

> Yes, that's the whole point of the exercise. Have you ever reviewed the -S output from GCC? No? So do you really know what your code is doing?

Because I gave it some code in a different language and it mechanically translated it through a deterministic, clearly documented process.

[nunez]

You can't guarantee that an LLM will yield the same answer twice, given the same input, by design. You can with compilers. That's the point being made here.

[slopinthebag]

It is deterministic, unless GCC is now including a random statistical process inside its compiler to generate machine code. You've copied this same comment repeatedly, it doesn't become more correct the more you spam it.

[Kilenaitor]

Having bugs is not the same as being non-deterministic.

I get the point that the compiler is not some pure, perfect transformation of the high-level code to the low level code, but it is a deterministic one, no?