Correctness Over Determinism

I've been writing software for twenty years. In that time, I've watched the industry obsess over a lot of things that turned out not to matter — and ignore a lot of things that did. Right now, I think we're doing it again. Specifically, with the conversation around AI-generated code.

The question I keep hearing is: "But the LLM isn't deterministic. You give it the same prompt twice and get different code. How can you trust that?"

It's a reasonable-sounding concern. But I think it reveals a fundamental confusion about what we should actually care about.

The Compiler Analogy

Think about your compiler. You write some C, you run gcc, and out comes machine code. You trust that machine code. Why? Because the compiler is deterministic — same input, same output, every time. And because very smart people have spent decades making sure that the output is correct.

But here's the thing most people don't stop to consider: if that compiler produced different machine code each time (different register allocations, different instruction ordering, different optimisation choices) but the resulting program always behaved correctly according to the spec... would you care?

I wouldn't. Not even slightly.

I don't actually care about determinism. I care about correctness. Determinism happens to be one way we've historically achieved confidence in correctness. But it was never the goal itself.

Why We Conflate the Two

We've spent decades building mental models around reproducibility. Version control, CI pipelines, lock files, pinned dependencies. The whole modern development stack is essentially an elaborate machine for saying "given the same inputs, I will always get the same outputs." And that's been a useful proxy for quality.

But it's still just a proxy. A build that produces the same broken binary every time is deterministic. It's also useless. Meanwhile, a system that produces different but always-correct implementations is non-deterministic, and perfectly fine.

The real question about AI code quality isn't "does it produce the same thing twice?" It's "does it produce something correct each time?" Those are very different questions, and only one of them actually matters.

Correctness Is What We Actually Verify

If you think about it, this is what good engineering practice has always been about. We don't ship code because the diff looks tidy. We ship code because:

• The tests pass.
• The behaviour matches the spec.
• Edge cases are handled.
• The system doesn't regress.

Those are all statements about correctness, not determinism. And here's where it gets interesting — if your test suite is comprehensive enough, and your spec is precise enough, does it really matter how the code was produced? Whether a human typed it, a different human typed it differently, or an LLM generated something entirely novel each time?

I'd argue it doesn't. And increasingly, the tools are catching up to that reality. As I wrote about in Bug Backlogs Are Dying, the whole paradigm of what it means to maintain software is shifting. The same is true for how we verify it.

Code Review Will Become Quaint

This is the part where people get uncomfortable, but I'll say it anyway: code review, as we practise it today, is heading for irrelevance.

Not immediately. Not next quarter. But a future where a well-defined spec gets correctly implemented by an agentic coding system 100% of the time? That's not science fiction. It's a trajectory we can see from where we're standing right now.

When that happens, reviewing the code line by line will feel about as necessary as reading the machine code produced by your compiler. You'll review the spec. You'll review the tests. You'll review the behaviour. But poring over implementation details that might look completely different on the next run? That becomes a quaint artefact of a time when humans were the bottleneck.

(I can already hear the objections forming. "But what about readability? Maintainability? What about when you need to debug it?" Fair questions. But consider: if the AI can generate it, it can also explain it, refactor it, and debug it. The entire lifecycle shifts.)

Where We Are Today

To be clear, we're not there yet. Today's LLMs produce code that is correct most of the time, not all of the time. That "most" is important — it means you still need verification, you still need testing, and yes, you still need human judgement. I'm not arguing for blind trust.

What I am arguing is that the frame of the conversation is wrong. When someone dismisses agentic development because "the output isn't deterministic," they're fighting the wrong battle. The right battle is about building better specs, better test suites, and better verification systems. The things that let you confirm correctness regardless of how the code was produced.

I've spent the last year building with Claude Code almost exclusively. Same prompt, different code, same correct result. That's my Tuesday. And honestly? It's liberating. I care less about how something is implemented and more about what it does. That feels like progress.

The companies that understand this distinction, correctness over determinism, are the ones that will move fastest. The ones still arguing about whether AI code is "reproducible" will be having that argument long after the rest of us have shipped.