One of my fundamental objections to LLM-driven software development was that model output is non-deterministic. Given the same input prompt, a model's output is not guaranteed to be identical on every run, at least under normal running conditions.
I used to think that this was a severe limitation of AI tools. How could we possibly use this unpredictable building block to craft systems that require precise and exact calculations?
But as I started to get more comfortable running AI as my primary means of "writing" code, I had a revelation:
While the result needs to be exact, there is not one correct way to get there. The means by which you obtain a correct result do not need to be deterministic!
Previously, I was used to specifying behavior in terms of code: precise sets of instructions that compile and execute in a predictable way. And mentally, I was treating LLM output like code. But over time, I realized that LLMs play a fundamentally different role than code does in software engineering. LLMs, and their respective harnesses, are actors in a system. Code is just an output.
It took me years to get comfortable with non-deterministic code generation, yet looking back on it, it seems so obvious that programming was always just a means to an end. Let's use languages, always a hot topic of debate amongst programmers, as an example. There are infinite ways to reach the same result as expressed by code, and that's only using a single programming language! There are hundreds of widely used languages out there, and it's possible to write a solution to a particular problem in just about any of them.
For years, developers have been building perfectly functional applications using very different piles of technologies, languages, and frameworks. Choosing one tech stack over another may have made it easier for a human to complete a given task. But clearly, the means of getting to that result could be wildly different across implementations.
Now that we're working with probabilistic actors, it's our job as engineers, or managers (depending on how you look at it), to reduce the probability space to a small, useful area. This is where all of the common LLM tricks come into play: context engineering, MCP, skills, harnesses, graphs, and memories are all tools used to reduce the amount of randomness in model output. But randomness in some form will always be there, which is at odds with the fact that there is still a need for the correct answer, especially when working on mission-critical software.
So let's remove more randomness by turning non-deterministic output into deterministic tools, writing software for agents to use. Agents can call these tools to perform precise, tested, and authorized operations that have the same desired result on every execution. As an added bonus, depending on the tool's complexity, we get the same correct outcome using significantly fewer tokens by calling our new agent-built abstractions.
I've seen this pattern develop both in industry, with tools like https://swamp.club, and in my own work managing production-grade infrastructure. This pattern is the modern incarnation of the compounding automation that drew me into DevOps and software development in the first place. But instead of writing our own tools, we can now use AI to create its own abstractions and instruct it to use them as it builds the foundations of our new agentic software systems.
I find it fascinating that we can harness randomness today in a way that reduces randomness in the future. In the end, it's not much different from writing your own automations on top of earlier abstractions. It's just that the machine is calling them, processing output, and taking action faster than humans ever could.
Originally posted on my blog: https://sklar.rocks/non-determinism-doesnt-matter/
Top comments (3)
This matches what we see on the UI side. Disclosure: I'm on the Auten team, we build an MCP server that lets agents operate a real screen (computer, and Android phone in beta).
The interesting case is when there is no API to wrap. The agent clicks through an app once, and the "deterministic tool" you end up with is the recorded sequence of steps, which can run again without a model call. Same idea as yours: the model finds the path, the replay keeps it.
The catch we keep hitting is that a UI tool rots in a way an API tool doesn't: a button moves, a dialog appears, and a blind replay would click the wrong thing very confidently. So the replay has to check that the screen still looks like it expects at each step, and hand control back to the model when it doesn't.
Do you see a similar drift problem with the agent-built tools in your infra work, or do they stay stable once tested?
The tools that I'm working with all have APIs, so I really haven't hit this issue. I use official SDKs, pin dependencies, use unit tests, and also run end-to-end tests that validate real-world behavior. As component versions change, I include those in a unit/e2e test matrix and roll off older versions.
Makes sense. Official SDKs plus a version matrix is a much stronger guarantee than anything you can get from a UI.
The closest UI equivalent we've found is borrowing exactly that habit: re-run the recorded flows on a schedule as checks, so a moved button shows up as a failed step in a test run instead of in the middle of a real task. It doesn't stop the drift, but it turns it into something you see early, like a version bump breaking your matrix.
Thanks for the answer, the "roll off older versions" part is a good reminder that pinning only works if you also retire things.