The "AI isn't deterministic" objection imports a standard from pure math.

Physical reality never meets it either. Real tools ship when they meet a precision threshold, not abstract perfection.

Magnify any line ever drawn. It isn't smooth. It has grooves, bumps, tiny deviations from the geometric abstraction you learned in school.

You still call it a line. You still use it for the cabinet you're building, the diagram you're explaining, the envelope you're measuring. Straight enough for the job.

A physical circle is never the perfect circle. Click the buttons to change the inspection standard.
Real circle: useful at normal scale.

At the scale where you use it, the physical line is close enough to the ideal that the difference does not matter.

This sounds like a casual observation. It's actually the reason you should stop waiting for AI to be "deterministic."

The standard you're demanding

You're an indie hacker with an AI feature half-built. You've watched the model produce three different answers to the same prompt. Your gut says don't ship it. Ask for specifics and you'll reach for words like reliability, consistency, determinism.

Look at what you're actually demanding. Same input, same output, every time, forever. That's a mathematical definition. It describes a pure function in a textbook.

Nothing real meets it.

Your database has clock skew. Your network drops packets. Your CPU schedules threads in a different order on every run.

You ship every day on top of layers that are imprecise at some scale, and you trust them because their imprecision is small enough to not matter for your job.

What you're really importing is Platonism. The belief that the perfect Forms are the true reality and the messy physical world is a degraded shadow of them. It's a lovely frame for geometry class. It's a terrible frame for engineering, because navigating by perfect Forms requires omniscience about every edge case, every input, every future state. Nobody has that. Waiting for it is waiting forever.

Software builders are particularly susceptible to this import. Code feels like the closest thing to pure math humans build. Same instruction, same output.

The cracks show higher up the stack, but the mental model has already formed.

Every other craft has worked against imprecision as the baseline forever. You're meeting what normalcy looks like outside software, not encountering a new defect.

Zeno never shipped

One of Zeno's paradox examples: to cross a room, you must first cross half. Then half of the remainder. Then half again. An infinite number of halvings. So you can never reach the other side.

The paradox dissolves the moment you leave pure math. Real motion isn't an infinite sequence of subdivisions you have to complete one by one. Your foot lands. You cross the room in two seconds.

It's only paradoxical inside the abstraction. Take the abstraction outside and it breaks.

The "AI isn't deterministic" complaint lives in the same territory. A textbook objection about a product you plan to ship to humans, who aren't deterministic themselves.

What engineers actually do

Every real tool has a precision threshold. The real question every engineer has always asked is whether the error is small enough for the job at hand.

A tape measure accurate to a millimeter is precise enough for framing a wall. Way too sloppy for a semiconductor fab. Same tool, different job, different answer.

An autopilot reliable 99.9% of the time is unacceptable. A spam filter reliable 99.9% of the time is excellent.

Music lives here too. Equal temperament, the tuning almost every modern piano uses, is mathematically wrong on purpose. No interval in it is pure.

A pure fifth would be slightly wider, a pure third slightly narrower. The compromise is deliberate: a piano tuned to pure intervals in one key is unplayable in others.

Western keyboard music has run on a threshold, not a Form, for centuries.

AI is no different. The question is what precision this specific job needs, and whether you can engineer to meet it.

Engineering the threshold

You already know how to narrow AI's error bars. You just don't call it engineering because it feels suspiciously like prompt writing.

  1. Lower the temperature. Sampling randomness is a dial. Turn it down when consistency matters, up when you want variety.
  2. Constrain the output. JSON schemas, regex validators, typed function calls. The model can still hallucinate, but only inside a shape you control.
  3. Narrow the context. Less room means fewer paths the model can wander down. Prompts that describe the entire decision space produce tighter results than prompts that describe the vibe.
  4. Verify after generation. A second LLM call, a regex check, a test runner, a human. The generator doesn't need to be perfect if the checker is cheap.
  5. Budget retries. Non-deterministic often means mostly right with occasional drift. Three tries with a validator beat one try with a prayer.

None of this makes the model deterministic. All of it raises the precision threshold.

The gap between "not deterministic" and "reliable enough for this job" is where real engineering happens. Every real-world tool has always lived in that gap.

Which jobs clear the threshold today

Code autocomplete can tolerate a 5% error rate. Medical diagnosis cannot. A copywriter can ship AI drafts and edit them. A tax advisor cannot ship AI answers unchecked.

If the precision your job needs is higher than the threshold you can engineer to, don't ship it. The determinism question was always a red herring. The threshold question is the one that tells you whether to build.

If the threshold is met, ship it. The abstract version of a circle is round, and no drawn one ever will be. You're not building in pure math.

The real question

Stop asking whether the AI is deterministic. Start asking whether its imprecision is small enough that the user won't notice, or won't care if they do.

Your users are non-deterministic. Ask the same person the same question on Tuesday and Thursday and you'll get two answers.

They want different things at 9am than at 9pm. They'll forgive a response that varies because their own responses vary.

A tool that always produces the same output is in some sense less matched to them than one that adapts.

This doesn't mean anything goes. The target is appropriate variation: tight where the job demands tightness, loose where the job permits it.

That's the same question every engineer has always asked about every tool they've ever shipped. Nothing you've built was abstractly perfect, and your product worked anyway.

AI is the newest tool joining a very long list. The builders who ship are the ones who stop demanding it hit a standard nothing real has ever hit, and start engineering it to hit a standard that matters for the job.

No circle is round. Your product doesn't need one that is.

Rabbit Hole

If the precision threshold framing resonated, The One-Shot Illusion takes it into the territory of founders who ship AI that looks ready but isn't. 2X AI Coding Speed, Without the Slop is the practical version: the drift check you run before review becomes the bottleneck. And if you're still working out how to think about AI as a category of tool, not just a feature, You're Building a Stone Cathedral Out of Concrete picks up that thread.