When coding, a few things are happening. You build a representation of what you want to achieve in your head and translate that to code, aka "typing the code", which is actually a pretty complicated process but certainly not all of the entirety of the software engineering process. Then you review what you wrote and commit.
With LLMs you still maintain steps 1 and 3. you reason about the solution, translate it to English and then let the LLM do the "typing the code". Finally you review the output.
The output review is completely deterministic and you have the opportunity to even tweak the LLM's output to match your mental model. The nondeterministic nature of the LLM isn't super relevant because it just changes how much work you do in this step. At this point it's just like standard coding minus the typing. Ultimately it's still an objective relationship with the compiler. It's very much like how tech leads engineer a system through their teams.
Assuming that you truly understand and own every line of the LLM's output, the model is almost working like a macro.
I don’t have to review the output of a macro invocation once I’ve convinced myself that the macro’s definition is correct, similar to how I don’t have to review a compiler’s output. That’s the difference we are concerned with here.
For comparison, consider the statement “Assuming that you truly understand and own every byte of the compiler's output, […]”. The point of a compiler is that we can depend on it without having to impose such an assumption.
I might take on to saying that compilers are more deterministic than vibe coding, that should stop the vibecoders from arguing about how technically 1+1 is not deterministic because of UB in C or whatever.
That said, they'll probably start debating that something is either deterministic or it isn't, and we can answer that they couldn't be more wrong, and they'll answer that wrong is an absolute state and not subject to gradation, , and we can answer that of course it's relative, it's wrong to say a tomato is a vegetable, but it's more wrong to say it's a suspension bridge, and then we can finally go to bed because the online arguments have all been solved, the end, it's done.
You literally don't know what it does, though. And it's not a given that QA testing the program will lead to an answer before it leads to a bad outcome. There's an understanding, when we use software we can't read, that some humans looked at it and talked to other humans about how it works. Maybe got calls from customers about bugs, made workarounds.
If I'm just vibecoding stuff for me, and I don't understand any of it, I would not feel safe running it on my computer. And I'm not convinced a lot of people are even going to do this, because non-technical users seem to intuitively understand they are rolling dice in some way.
You certainly can, but you can't tell people anything about how it works, if it's safe, whether it spies on people, when it needs to be upgraded, etc. Is there going to be a market for vibe coders who sell services they don't understand? I don't know.
For documenting business logic, code is highly specific and dependable even with non-deterministic compilers. We can look at code and say "Yes, we can connect this to our Stripe account, because we have reviewed what it actually does." We can mock services and test that it works. We can do all of that without reading build output
The same, obviously, cannot be said of LLM prompts. And due to the flaws (and strengths!) of Natural Language, I'm not sure that will change. If someone told me their vibe coded app was safe because they politely asked it to be, I obviously wouldn't use their service. If they told me they asked it to write tests and do mocks, I wouldn't know if it actually did. A pure vibecoder can, at best, reread the prompt they gave, and maybe ask the LLM if there are vulnerabilities, hoping that it finds something.
Maybe we will get to a point where people are feeding 80 page specifications to LLMs as the input, but I'm not sure a person who is capable of writing that level of detail but incapable of learning to read code really exists. I don't think it will get that far. I think people will keep their prompts short and just roll the dice, QA testing.
As a sibling commenter said, I agree that the concept here is "chaotic". A small change in the input (the prompt) can create large (or not!), unpredictable changes in the output. And variations on that small input change can have wildly different effects on the output.
But a change (large or small) to C code will create predictable (large or small) changes to the assembly output.
A tiny change in the inputs can result in a large (and hard to predict) change in the output. Non-determinism is a different axis completely, and some compilers are (semi-accidentally) NOT deterministic either (two runs are not byte identical)
A vanishingly small percentage of coders are thinking about this when they're coding. Compilers do so many optimizations that most work-a-day programmers don't think about as well. If you're one of those people who care about the exact instructions coming out of your compiler, you're just inlining assembly.
Although even program results are not guaranteed, famously C standard leaves some things undefined and up to implementation.
So the analogy works as long as you understand that natural language itself (aka the prompt) doesn't give complete specification, and it's the LLM itself which selects a particular formalization. But in principle it's not much different from compiler electing to use an optimization and making program faster. Or using a particular flavor of stdlib.
In fact today even the execution itself is unpredictable. For example, a different input can cause cache eviction or branch misprediction, making a loop much slower. Or a different thread might execute on hyperthreading core, affecting the performance.
I think with LLMs, we will be in a long tail of finding those scenarios (where natural language leads to big misunderstanding) and fixing them.
> famously C standard leaves some things undefined and up to implementation.
And the language specification lets you reason about when the code will invoke undefined behavior and when not. You can ensure that you’re on safe ground by reasoning about the code in accordance with the language specification. With LLMs, such rigorous reasoning is not possible. The very fact that the C language specification does define when UB occurs is what lets you reason about it.
> I think you're wrong, the compilers are already unpredictable (or chaotic, better to say than nondeterministic, as someone pointed out).
I made the point in the root comment that the compiler may be non-deterministic and that this doesn’t matter for the argument. Because the point isn’t about determinism, it’s about being able to reason with high precision about the program’s behavior based on the source code.
> If a junior programmer does not learn to write code and simply generates it, they are robbing themselves of the opportunity to develop the visceral understanding of code that comes with being down in the trenches.
I never learned to write any assembly language and am pretty sure as a result I do not viscerally understand what a compiler generates, though I enjoy recreationally looking at godbolt as much as the next person. Given a lot more time I'd get to assembly (and below) but I don't feel that I robbed myself.
There's a difference in how you can reason about a nondeterminstic system from how you can reason about a determinstic one, but you can reason about both, and you can develop a visceral understanding of both.
I think the wider view is usually what people mean when they talk about nondeterminism in LLMs. Maybe because computers are traditionally so deterministic the wide view is almost taken for granted by programmers.
yells at cloud
a human can predict that the number that is generated will be suitably random.
a human can predict the result from a pseudo-random generator with enough knowledge of seed/program state/etc.
now I can't say this holds for a TRUE random number generator. nor do I know where we were going with this.
Can you really ?
With LLM, if your input is stupid, the llm may/may not nudge you and happy to continue with that input and gives it 100% effort.