As human developers, I think we're struggling with "letting go" of the code. The code we write (or agents write) is really just an intermediate representation (IR) of the solution.
For instance, GCC will inline functions, unroll loops, and myriad other optimizations that we don't care about. But when we review the ASM that GCC generates (we don't) we are not concerned with the "spaghetti" and the "high coupling" and "low cohesion". We care that it works, and is correct for what it is supposed to do. And that it is a faithful representation of the solution that we are trying to achieve.
Source code in a higher-level language is not really different anymore. Agents write the code, maybe we guide them on patterns and correct them when they are obviously wrong, but the code is merely the work-item artifact that comes out of extensive specification, discussion, proposal review, and more review of the reviews.
A well-guided, iterative process and problem/solution description should be able to generate an equivalent implementation whether a human is writing the code or an agent.
> review the ASM that GCC generates (we don't)
Of course we do not. Because there is no need. The process of compiling higher order language to assembly is deterministic and well-tested. There is no need to continue reviewing something that always yields the same result.
> We care that it works, and is correct for what it is supposed to do.
Exactly. Which is something we do not have with an output of an LLM. Because it can misunderstand or hallucinate.
Therefore, we always have to review it.
That is the difference between the output of compilers and the output of LLMs.
This. The comparison between compilers and LLMs is so utterly incorrect, and yet I've heard it multiple times already in the span of a few weeks. The people suggesting this are probably unaware of the fact that Turing complete languages follow mathematical properties not just vibes. You can trust the output of your compiler because it was thoroughly tested to ensure it acts as a Turing machine that converts one Turing complete language (C, C++, whatever) into another Turing complete language (ASM) and there's a theorem that guarantees you that such a conversion is always possible. LLMs are probabilistic machines and it's grossly inappropriate to put them in the same category as compilers - it would be like saying that car tires and pizzas are similar because they're both round and have edges.
> The process of compiling higher order language to assembly is deterministic and well-tested.
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.
I've posted this 3 times now. Code-generation by compilers written by experts is not deterministic in the way that you think it is.
In the 12+ years I've been a professional developer, I can only remember two bugs that were caused by the compiler / interpreter, everything else were logic bugs, oversights, 3rd-party libraries, misunderstanding of the requirements, internal contradictions in the requirements etc.
So that's maybe 0.1% of all the bugs I've touched.
In that sense, code generation isn't really an interesting source of bugs for the discussion at hand.
There were more ~26+ years ago. gcc and egcs had some subtle register allocator bugs that would get tripped up under heavy register pressure on i386 that were the bane of my existence as a kernel developer at the time.
It's close enough. If we had a build pipeline that kept prompts in source control, and ran it through an LLM and then a compiler to produce the build output, this would fall over constantly. You'd get radically different results every time. Build pipelines that store actual source code in source control, then run them through a compiler to produce the build output, are used all over the place and they generally work great.
If the "bug" shows up every time in the output given the same input, then it definitely is deterministic.
Just because there are bugs does not mean a compiler is non-deterministic. I looked through a bunch of the bug reports and there is nothing there that can't be fixed to make it deterministic.
You can't fix an LLM to be absolutely deterministic, but you can fix a compiler.
>Source code in a higher-level language is not really different anymore
Source code is a formal language, in a way that natural language isn't.
Right? That's the only reason that "coding with LLMs" works at all (believe me, all at the same time, I am wowed by LLMs, and carry a healthy level of skepticism with respect to their ability as well). You can prompt all you want, let an Agent spin in a Ralph loop, or whatever, but at the end of the day, what you're checking into Git is not the prompts, but the formalized, codified artifact that is the bi-product of all of that process.
Somewhat ironically, perhaps a formal, deterministic programming language (in its mathematical-kind of abstract beauty) is the outlier in the whole soup. The customers don't know what they need, we don't know what we ought to build, and whatever we build nobody knows how much of it is the right thing and what it actually does. If the only thing that causes people to sigh is the requirement to type all that into a deterministic language maybe at some point we can just replace that with a fuzzy, vague humanly description. If that somehow produces enough value to justify the process we still won't know what we need and what we're actually building but at least we can just be honestly vague about it all the way through.
When you get to the really tightly controlled industries, your "formal" language becomes carefully structured English.
Legalese exists precisely because it is an attempt to remove doubt when it comes to matters of law.
Maybe a dialect of legalese will emerge for software engineering?
Legalese is nowhere near precise, and we have a whole very expensive system because it’s not precise.
It is an attempt the be precise, and to remove doubt. But you're right that doubt still creeps in.
Legalese already exists in software engineering. Several dialects of it, in fact. We call them programming languages.
This is the answer
If you truly believe that, why don’t you just transform code directly to assembly? Skip the middleman, and get a ton of performance!
I assume you're being cynical, but there's a lot of truth in what you say: LLMs allow me to build software to fit my architecture and business needs, even if it's not a language I'm familiar with.
I know you're being cheeky but we are definitely heading in that direction. We will see frameworks exclusively designed for LLM use get popular.
I think that’s possible too but the trouble is training them. LLMs are built on decades of human input. A new framework, programming language, database, etc doesn’t have that.
We are in the low hanging fruit phase right now.
If it knows the language already a new framework is a piece of cake. A few MD files explaining it is enough for the pattern recognition to kick in. I've had one LLM create a novel framework and pass them to another and it's trivial for a fresh instance to pick it up.
Assembly eats up context like crazy. I usually only have my LLM use assembly for debugging / performance / reversing work.
Can agents write good assembly code?
With the complexity of modern pipelines, there are very few humans that can beat a good optimizing compiler. Considering that with an LLM you're also bloating limited context with unsemantic instructions I can't see how this is anything but an exercise in failure.
I don't know if I agree with that. It's a struggle to get a modern compiler to vectorize a basic loop.
you know if I could I would (Android dev)
In my experience it doesn't really work that way. It's somewhat akin to a house that's undergone multiple remodels. You eventually run out of the house's structural capacity for more remodeling and you have to start gutting the interior, reframing, etc. to reset the clock.
At least today the coding agents will cheat, choose the wrong pattern, brute force a solution where an abstraction or extra system was needed, etc. A few PR's won't make this a problem, but after not very long at all in a repo that a dev team is constantly contributing to (via their herds of agents) it can get pretty gnarly, and suddenly it looks like the agents are struggling with tech debt.
Maybe one day we can stop writing programming languages. It's a thought-provoking idea, but in practice I don't think we're there yet.
The semantics described in the high-level language are absolutely maintained deterministically.
With agentic coding the semantics are not deterministically maintained. They are expanded, compressed, changed, and even just lost; non-deterministically..
I see it differently: The code is our medium of communicating a solution.
> "Programs must be written for people to read, and only incidentally for machines to execute." -- Hal Abelson
Without this, we quickly drift into treating computers and computer programs as even more magic, than we already do. When "agents" are mistaken about something, and put their "misunderstanding" into code that subsequently is incorrect, then we need to be able to go and look at it in detail, and not just bring sacrifices for the machine god.
Just because an LLM can turn high level instructions into low level instructions does not make it a compiler
None of the comparisons make any sense. In short, these concepts are essential to understand:
- determinism vs non-determinism
- conceptual integrity vs "it works somewhat, don't touch it"
> determinism vs non-determinism
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.
Deterministic doesn't mean correct. Compilers can have bugs. What deterministic means, given the same input you get the same output every time. So long as given the same code it generates the same wrong thing every time, its still deterministic.
99.9% vs about 20%. Pretty weak argument.
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.
> 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.
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.
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.
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.
> 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.
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?
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.
>For instance, GCC will inline functions, unroll loops, and myriad other optimizations that we don't care about. But when we review the ASM that GCC generates (we don't) we are not concerned with the "spaghetti" and the "high coupling" and "low cohesion". We care that it works, and is correct for what it is supposed to do. And that it is a faithful representation of the solution that we are trying to achieve.
The more complex the code becomes, iteration after iteration by the AI, it keeps adding more and more code to fix simple problems, way more than is reasonably necessary in many cases. The amount of entropy you end up with using AI is astonishing, and it can generate a lot of it quickly.
The AI is going to do whatever it needs to do to get the prompt to stop prompting. That's really its only motivation in its non-deterministic "life".
A compiler is going to translate the input code to a typically deterministic output, and that's all it really does. It is a lot more predictable than AI ever will be. I just need it to translate my explicit instructions into a deterministic output, and it satisfies that goal rather well.
I'll trust the compiler over the AI every single day.
Is this a copypasted response? I've seen the exact same bs in other AI threads on this site.
This user has posted the parent post nearly verbatim twice. And the exact same responses about determinism several times.