We spent seventy years building machines that do exactly the same thing every time. It took about three years of AI hype to start describing that property as a limitation.
I keep running into the framing in threads, in pitch decks, in hallway conversations: deterministic systems as the old world, rigid, unimaginative, waiting to be disrupted by something that improvises. And every time, I want to push back with the least fashionable opinion I hold: determinism is not the boring baseline that AI liberates us from. It is the single most valuable property a production system can have, and 2026 is the year we are most eagerly trading it away.
Let me be precise about what this post is not. It is not an anti-AI post. I run an engineering team, and we run agents in production: they draft, they call tools, they touch real systems every day. I like this work. The argument here is not "don't use models". The argument is that the more probabilistic components you add, the more load-bearing the deterministic parts around them become, and that almost nobody is hiring, promoting, or celebrating for the second half of that sentence.
What determinism actually buys you
Reproducibility is not an aesthetic preference. It is purchasing power. Walk through what "same input, same output" quietly funds:
A reproducible bug is a bug that is already half fixed. You can trap it, shrink it, watch it happen in a debugger. A non-reproducible bug is not a bug, it is a haunting. You don't fix hauntings, you appease them: add a retry, widen a timeout, sacrifice a sleep(500) and hope.
A failing test means something. In a deterministic system, red means broken. The moment flakiness enters, red means "run it again", and the entire signal collapses. A suite that people rerun until it passes is not a test suite, it is a slot machine with CI minutes.
git bisect works. Bisect is a miracle we stopped noticing: binary-search across history and the machine tells you which commit broke the world. The miracle rests entirely on replay giving the same answer twice. Bisect over a component that answers differently each run is not debugging, it is astrology with version control.
A diff tells the truth. Code review works because a change in behavior is legible from a change in text. The whole social contract of "I read your PR, therefore I know what it does" assumes the text determines the behavior.
Incidents can be reconstructed. The 3 a.m. question is always "what exactly happened, in what order?" Every answer you can give assumes the system will tell the same story twice.
Notice the shape of that list. Testing, review, bisect, rollback, audit: essentially every practice we call "software engineering" is a child of determinism. It is not one nice property among many. It is the property the rest of the discipline is built on.
The bottleneck moved
Here is the economic argument, because the craft argument never convinces anyone in a planning meeting.
For most of my career, producing the artifact was the expensive part. Writing the code, the config, the migration, the docs. So that is where the effort, the tooling, and the prestige went.
That cost just fell off a cliff. Code, tests, configs, entire services: generating a plausible version of almost anything is now nearly free. And when the cost of production approaches zero, the remaining cost of software is the cost of verification. Checking that the plausible thing is actually true is no longer a phase of the project. It is the project.
The asymmetry is brutal. Generated output scales with compute, which gets cheaper every quarter. Verification scales with human attention, which does not scale at all. Every team I talk to is discovering the same imbalance: the pipeline that produces changes got a jet engine, and the pipeline that validates them still runs on the same few pairs of eyes it had in 2019.
So the scarce skill inverted. The valuable engineer of 2020 was the one who could produce faster. The valuable engineer of 2026 is the one who can look at something plausible and determine, efficiently and reliably, whether it is correct. Plausible is the commodity now. Correct is still artisanal.
Put the non-determinism where wrong is cheap
None of this means banning models from production. It means placing them deliberately, the way you place any component with a known failure mode.
A probabilistic component belongs where a wrong answer is cheap and checkable: a draft, a suggestion, a summary, a first pass that a cheaper process can validate. It does not belong holding your state, moving your money, or standing alone in front of an irreversible action.
The pattern that works is deterministic rails around a probabilistic core. And the rails are built from the least glamorous toolbox in the profession: schemas validated at the boundary, state machines whose enums make illegal transitions unrepresentable, idempotency keys so a confused retry collapses into one effect instead of two, version-bound writes so decisions made on stale data get rejected instead of applied, a plan-then-commit gate in front of anything with blast radius, and an append-only log so "what did the system do?" never depends on anyone's memory.
I wrote a whole article on the how of those rails at one specific boundary, agents writing to production systems: where each mechanism goes, what each one catches, what the server contract looks like. Consider this piece the why. Nothing in that toolbox was invented this decade, and that is exactly the point: it is decades of transactional common sense, redeployed at a new boundary, the line between a model and everything you care about. The model gets to be creative precisely because the rails are not.
Read it back before you believe it
I have a rule I apply to everything now, and it started long before agents: a system's report about itself is a claim, not a fact. Read it back before you believe it.
The agent says it published the article? Fetch the article through the same path a reader would, and look at it. The migration says it ran? Count the rows. The dashboard is green? Green means "the things we chose to measure are within the thresholds we chose to set", which is a much smaller statement than "everything is fine". Your own code from last year? Same treatment. The author being you buys it nothing.
For years this was a habit. Recently I understood it is actually a design requirement, and this is where it connects back to determinism: verifiability is a property you build in, not a virtue you exercise afterwards.
A deterministic system is cheap to verify. One run is proof; the test you wrote once keeps testifying forever. A probabilistic system can be made verifiable too, but not for free: you have to design the read-back paths, the invariants, the reconciliation jobs, the alert that fires when the report and the reality disagree. Skip that work and you have not built a system, you have built a story the system tells you about itself.
The question that changed how I build is not "does it work?" It is "how will I know it is still working when I am not watching?" A system that cannot answer that question is not finished, no matter what the demo looked like.
Boring is a career strategy
Ten years ago, Dan McKinley told us to choose boring technology: spend your innovation tokens on your actual problem, not on your stack. The 2026 version of that advice is one level deeper: choose boring properties. Determinism. Idempotency. Reproducibility. Auditability. The stack will change under you; the properties transfer.
Because here is the career math nobody puts on a slide. When everyone on the team can generate code, generating code stops being what distinguishes anyone. The floor rose; the ceiling did not move. What is scarce in a room full of people who can produce plausible artifacts is the person who can say "this is correct, and here is how I know", and have the second half of that sentence be load-bearing.
That skill compounds, too. The prompt tricks of last spring are already quaint. The ability to design an invariant, bound a blast radius, or smell a non-reproducible test has been appreciating since the seventies and shows no sign of stopping.
Nobody demos idempotency keys. Demos are generation; production is verification. The distance between the two is where reputations are quietly being made right now.
Ship the boring thing
The systems I trust all have the same personality: they do the same thing every time, and they can prove it. When I add a model to one of them, and I do, I add it where being wrong is cheap, with rails around it that never improvise.
Determinism is a feature. Some years I would have said an underrated one. This year I will go further: it is the feature, the one that makes all the others checkable.
Ship it. And read it back before you believe it.
What is the most boring thing in your stack you would defend to the death? Genuinely curious.
Top comments (0)