The same plan, the same result

Run the same request through a coding agent twice and you get two different programs. One rounds half-up, the next rounds half-even, a third quietly truncates. Nobody changed anything. That's not a bug in the tool — it's what these models are. They sample. The useful question isn't how to make the model deterministic; it's how to get a reproducible result out of one that isn't. The answer turns out to be a detailed plan.

Same prompt, two answers

Language models generate by sampling from a distribution, so identical inputs don't guarantee identical outputs. You already know this from the chat window, where regenerating gives you a different phrasing. In a coding agent it shows up as something more consequential: a different implementation, a different set of assumptions baked in, a different edge case handled or missed. The output feels less like engineering and more like a slot machine — sometimes you pull the lever and get exactly what you wanted, and you have no reliable way to get it again.

The variance isn't really the temperature

It's tempting to blame the sampling temperature and reach for “set it to zero.” But turn it all the way down and the output is still brittle — reword the prompt slightly, or feed it in a different order, and the result moves. The deeper source of variance isn't the randomness knob. It's ambiguity. A loose prompt admits an enormous space of completions that are all “valid,” and the model lands on a different point in that space each time. The more you leave unstated, the wider the spread. The gap you didn't fill is exactly the thing that gets sampled.

A detailed plan collapses the space

So narrow the space. When the decisions are pinned down — the constraints, what “done” means, the context every choice has to respect (the same things that make a plan a harness) — there's very little left for the model to sample over, and it lands in nearly the same place every run. You haven't made the model deterministic. You've traded a wide distribution for a narrow one, by specification rather than by seed. The randomness is still there; you've just left it almost nothing to be random about.

You can't make the model deterministic. You can remove the ambiguity it would otherwise fill in at random — and that makes the outcome reproducible.

What reproducibility buys you

Reproducibility sounds like a purity concern. It isn't; it's what makes the rest of the work tractable.

• You can actually debug. When the output is stable, a change in the output means a change in the plan — so you can bisect, attribute, and confirm a fix. Against a moving target you never know whether your change worked or the dice simply landed differently this time.
• The quality stops depending on luck. You're no longer re-rolling every run and hoping for the good one. Pin the decisions and the floor comes up: the strong result becomes the one you get on purpose, not the one you got once and couldn't reproduce.
• It stops depending on who's driving. Without a plan, the outcome rides on who wrote the prompt and how they happened to phrase it. With one, the plan carries the quality — so a new teammate following the same planning process gets the same class of result as your most experienced engineer. The expertise lives in the document, not in one person's prompting instincts.

A process, not a personality

That last point is the one we care about most. Reproducibility that depends on a single talented prompter isn't reproducibility — it's a bus factor. What makes a result repeatable is a process anyone can run: sit with the agent, surface the decisions it would otherwise guess, resolve them in place, and keep going until the plan is concrete enough that there's nothing important left unsaid. That's exactly the interactive, thorough planning inplan is built to make routine — the agent drafts and raises its open questions as threads, you settle each one, and what you're left with is a plan tight enough to run twice and get the same thing back.

A non-deterministic model is fine. You just have to stop handing it your ambiguity and calling the result its fault. Give it the requirements in full, and the same plan gets you the same result — the plan is the seed.