God Does Not Play Dice. We Built Software That Does.

On 4 December 1926, Albert Einstein wrote to his friend Max Born and lost his temper in the most polite way available to him. The new physics was impressive, he admitted. It produced results. But something inside it was wrong, and he could not let it go. "Jedenfalls bin ich überzeugt, dass der Alte nicht würfelt." In any case, I am convinced that the Old One does not play dice.

What offended him is easy enough to say at a dinner table. The new theory claimed that at the smallest scale, nature does not decide in advance. You cannot predict what a particle will do, only the odds of what it might do. Einstein was certain this meant the theory was unfinished, and that somewhere underneath there had to be real machinery making real decisions.

He was wrong.

It took forty years to design a test that could settle the question and thirty more to run it without loopholes. In 2022, Alain Aspect, John Clauser and Anton Zeilinger won the Nobel Prize for the answer. There is no hidden machinery, unless you are willing to let it work faster than light. Einstein spent his final decades defending a universe that does not exist.

I think about that letter more than I expected to. Not for the physics, which I am not qualified to argue about. For the offense.

Same input, same output

Software made a deal with determinism very early and never renegotiated it.

The promise came from Newton. If you know what a system is made of and the rules it follows, you know exactly what it does next. Everything we built sits on top of that. Lock files, so today's build matches last month's. Tests that go green or red and mean it. Tools that walk backwards through years of history to find the change that broke something, which only work because the past is fixed.

Same input, same output. That was the deal.

Then we put an AI model inside it.

The usual first reaction is to turn the model's creativity setting to zero and assume that solves it. It does not. In September 2025 a team at Thinking Machines Lab asked a model the same question one thousand times with the randomness switched off. They got 80 different answers.

The reason is worth sitting with. Not creativity, and nothing mysterious about neural networks. Arithmetic. The chips give slightly different results depending on how much work they are handling, and that depends on how many other people happen to be asking the same server something at that moment.

Your answer depended on strangers.

The engineers resisting this are not being nostalgic. Spend fifteen years learning to build systems that behave the same way every time and suspicion is the correct reflex. But quantum mechanics never killed Newton. We still fly spacecraft on classical mechanics, physics learned to work both sides of the argument rather than settle it, and a century later there is still no theory of everything. Software is heading somewhere similar, and I am fine with that. You do not need a theory of everything to ship on Friday.

The auditor had a bad Tuesday

Here is the part that took me longest to see, and once I saw it most of the anxiety went away.

We were never deterministic either.

Put the same code in front of two senior engineers and you get two different reviews. Put it in front of the same engineer on Monday morning and again on Friday at six, and you still get two. An auditor flags whatever their attention, their last incident and their blood sugar make visible that day.

Nobody has ever run a code review twice expecting the outputs to match. If a colleague handed you identical comments on two passes a month apart, you would not be reassured. You would assume they had stopped reading.

And notice what we did about that. Nothing.

We never asked humans to become reproducible. We built the process around them instead. Developers used to be artisans, everyone with their own tools and their own way of working, and then we industrialised without much noticing: shared builds, linters, mandatory review, staged rollouts. None of it made anybody deterministic. It decided where each person's judgment was allowed to matter. The surgical safety checklist does not turn surgeons into machines, and nobody wants it to. Industrialisation was never about removing the human, but about designing a chain where unpredictable humans could still produce a reliable car.

A different colleague in every language

What I did not expect is how literally the comparison would hold once somebody measured it.

In July, Anthropic published an analysis of how Claude's values shift between models and between languages, across 309,815 real conversations. The versions came out with visibly different temperaments. One leaned toward caution and depth, raising risks nobody asked about. Another leaned toward warmth and agreement. Same company, same philosophy, different colleagues.

Then I read the second finding, and it stopped being abstract, because it was about me.

The temperament changes with the language you are speaking. The model is warmest in Hindi and Arabic. It is most rigorous in English and Russian. I am Spanish and Catalan, and I work in English all day, which means the version of this technology I have been arguing with for two years is the cold one, the one that challenges assumptions.

When I opened the conversation that turned into this article, the first thing I did was apologise for my English. That choice was never neutral. A developer asking that same question in Spanish is not getting the colleague I get. Anthropic put the consequence plainly:

Two people asking for feedback on the same business plan, one in Hindi and one in Russian, may come away with different impressions of its quality because Claude expressed different values.

They are honest that they cannot explain it: "We don't yet know which properties of our training data drive these differences."

Some of it is deliberate, though. The labs tune these temperaments on purpose: Anthropic steers Claude toward careful, measured answers, xAI instructs Grok to be irreverent, OpenAI tunes ChatGPT to be agreeable. Which makes choosing a model closer to hiring somebody than to picking a library version. You are choosing a disposition, and every disposition has blind spots.

Taming the dice

So the question stops being how to force this thing to be deterministic, and becomes the old industrial one. Where in the chain does it add value, and what do we build around it?

Snyk ran that experiment in June and published it as VulnBench JS 1.0: Can LLMs Find the Same Bugs Twice?. Same code, same instructions, five identical repetitions. Of 161 findings the model reported beyond the vulnerabilities already known to be there, 80 appeared in only one run out of five.

That is the single-file reality, and it matches what I see building quodeq. Point a scanner at one file and what you get is a sample, not a measurement. For a long time I treated that as a defect I had to engineer away.

Then look at the other group, the findings that landed on a real, already-catalogued vulnerability. Almost every one came back in every run. The solid problems were stable, the noise sat in the speculative tail, and Snyk's conclusion was not that one approach wins but that you pair the probabilistic reviewer with the deterministic scanner.

Deterministic scaffolding, probabilistic core. The same shape the assembly line arrived at a century ago.

So the determinism did not disappear, it moved. It is no longer in the generating, it is in the accepting: the form the answer has to fit, the thresholds, the rules deciding what counts as a finding at all. You let the model be probabilistic and you make the gate rigid.

Scale does the rest, and this is the part I would defend hardest. One file is a coin flip. A whole codebase is a distribution. The same probabilism that makes a single scan unreliable is exactly what makes ten thousand of them meaningful, because across that many files the noise cancels and the tendencies do not. This area is consistently weak on input validation. This part of the system is consistently worse than that one. Not a verdict, a trend, and a trend is almost always what you actually needed in order to decide what to fix first.

None of that is new either. It is how probability has always been used outside a laboratory. No insurer can tell you whether you will crash your car next year, and every insurer can tell you how many people like you will. We have simply never had to apply that thinking to a build pipeline before.

And some of those 80 are real.

That is the bill. A finding appearing once out of five is not automatically noise. It can be a genuine bug that one pass caught and four missed, and every rule suppressing one-off results throws those away alongside the hallucinations. From the outside there is no way to tell them apart. Consensus buys trust by spending recall, and you are deciding in advance, and in the dark, how many real problems you are willing to lose for a report you can rely on.

There is a second limit I underestimated for a long time. Repetition cancels noise, because noise points a different way each time. It does nothing about temperament. If a model runs more suspicious in English than in Spanish, all five passes carry the same tilt. Randomness is cured by repetition. A disposition is not.

The bank and the artist

The tidy version of this essay ends here, with industrialisation as destiny. Everything becomes a factory, the dice get caged, we all go back to work.

I do not believe that, and I nearly wrote it anyway.

Because the exact property the bank wants to eliminate is the property the artist wants to set loose.

A bank running credit decisions needs the same case to resolve the same way twice, with a complete audit trail, and every piece of scaffolding above exists to give it that. Meanwhile Refik Anadol opened Dataland in Los Angeles in June, a museum where the work is generated live and no two visitors ever see the same thing. There, the fact that it never repeats is not a cost to be tolerated. It is the exhibit. Show the same behaviour to a compliance officer and it is an incident report.

So the fork is real, and it is not between good and bad uses. It is two honest relationships with the same property, and both are settled in the same place. The gate. Not in what the model is, but in how much variation you let through the thing standing in front of it.

Which makes it an engineering decision before a philosophical one, and puts it on us rather than the labs. It is being made in code reviews and architecture meetings, in the small question of whether this step gets a hard gate or a loose one, right now, while the conventions are still soft.

Einstein never accepted that the Old One plays dice. The dice rolled anyway, for thirty more years, then for another seventy after he died, and then in front of three Nobel laureates with every escape route closed. Belief was never the variable.

Our software is probabilistic now. That part is settled. What is still open is what we build around it, and whether we are caging the dice or reaching for them.