AI Plus Deterministic, Not AI Versus Deterministic

Almost every automation request that comes our way now opens with the same line: "Can we use AI for this?" It's a fair question, and it's usually asked with real hope behind it. It's also the question most teams answer by gut feeling, which is how you end up with an expensive tool nobody trusts.

We've been chewing on this internally for weeks. A couple of our architects who code are running a team session called "Deterministic vs. non-deterministic: when should I choose which?" It's not an easy answer, because the right call changes from one job to the next.

The loud version of the AI story says: point an agent at the problem and let it figure things out. In delivery work, a result that's right 98% of the time can be worse than useless. A door schedule that's 98% correct is not 98% done. It's 100% un-shippable, because someone still has to check every row to find the 2% that's wrong. You haven't saved the work; you've moved it, and made it harder to see.

So the question isn't "can we use AI?" It's: what kind of problem is this?

We can map automation tasks on two axes to make the conversations easier. The first axis is input structure: how messy and ambiguous is what comes in? A clean, well-named Revit model is structured input; a pile of inconsistent DWGs, or a hand-marked PDF, is messy input that needs interpretation. The second axis is output tolerance: how much does a wrong answer cost, and how easily can you catch it? Anything that lands in an external deliverable is expensive to get wrong and tedious to check by hand. A first-pass suggestion a human reviews next to the model is cheap to get wrong and easy to catch. "Exact" is a spectrum and where a task sits matters more than the label.

Once you know where a task sits on those two axes, the answer mostly falls out. Here's how it plays out across the tools we work in.

Forma and concept-stage work. This is where non-deterministic methods earn their place, for two different reasons. The first is speed: a machine-learning surrogate can predict the result of a daylight or wind study far faster than running the full simulation. There's still a single ground truth here. You're trading a little accuracy for a big speed-up, not inventing an arbitrary answer. The second is exploration: early massing, "give me twenty options to react to," where there genuinely is no single right answer and a human is choosing. Both fit non-deterministic generative logic (AI or otherwise) well. The picture changes the moment that concept moves downstream into documentation, the area schedules, drawings and code-compliance numbers that get built in Revit.

Revit. Structured input, low tolerance for error, most of the time. The model is semantic: an element is classified as a door, with a fire rating and a mark, and that structure is exactly what deterministic code thrives on. AI earns its place at the front door of Revit, helping you ask and locate. Revit 2027's built-in MCP server (and tools like it) let you ask "find every door in Phase 2 missing a fire rating" in plain language, which is a nice way to interrogate a model. But the edit that lands in a schedule or on a sheet should go through validated, deterministic API code you can test, repeat, and undo. Let AI find and propose; let the C# add-in execute.

Rhino. Rhino is the case worth dwelling on, and the one we'd expand most. Its geometry is "dumb" by design. As one of our architects who code put it while triaging a client request, Rhino doesn't know what a piece of geometry is supposed to represent. It's meshes and polysurfaces, not a door with a swing or a wall with a clearance zone. The general principle is that AI and ML are good at finding patterns in data that carries no explicit structure, and that's exactly the gap Rhino leaves open. Classifying loose geometry, deciding whether an imported blob is a wall, a column, or noise, is one example. Spotting that the same assembly repeats forty times across a model that has no block definition for it is another. In each case there's no semantic handle for deterministic code to grab, so a pattern-finder can be the right tool in many cases. For the opposite job, producing exact geometry from well-structured input, deterministic code still beats handing the task to an AI.

‍

On a more general note one of our architects who code was triaging a client's wishlist recently that included turning a plan, elevation and section into a 3D volume automatically. Her note on it was simply: "very tricky, not sure about the right methodology here, deterministic or AI/ML." That's exactly the right question to sit with. When a task has messy input and an output that's costly to get wrong, you can consider splitting the task.

Splitting lines up with where the wider software world has landed in 2026: the framing has shifted from "language models versus deterministic systems" to "language models plus deterministic systems." The model interprets the mess and proposes a plan; deterministic code validates and executes the part that has to hold up. The AI might not touch the deliverable directly. In practice that means letting the model produce a structured, checkable intermediate, then running boring, testable code to turn it into the actual output, so that when the AI is wrong it gets caught at that boundary instead of leaking silently into a drawing set.

This is the part the AI hype skips. AI is a tool, and a tool is only as good as the person holding it. You build skill with a chisel before you trust yourself with it on a finished surface, and AI is no different. You put in the reps to learn when it's helping and when it's confidently wrong, and, more importantly, you need the domain expertise to judge the output. Someone still has to know enough about Revit, about geometry, about how the building actually goes together, to catch the 2% that's wrong before it reaches the drawing set. That's why "just point AI at it" falls over: it can produce an answer, but it can't tell you whether the answer is any good. That judgment is still yours, and it's still the scarce thing.

So the next time someone asks "can we use AI for this?", we'd push back with three questions instead:

1. How structured is the input?
2. How costly is a wrong answer, and how easily can you catch it before it goes out?
3. If the input is messy and the output is costly to get wrong, where's the clean line to hand off from interpretation to execution?

Answer those, and the conversation usually stops being whether to AI or not AI. Reach for AI where it fits, and remember it's another tool to get good at, in the hands of people who already understand what good looks like.

Deterministic AI could help you control your spending and give you better outcomes

There's a point that's worth repeating here, because it's where a lot of teams are about to spend a lot of tokens and hence money. Now that MCP servers are everywhere, including the one built into Revit 2027, it's tempting to wire an LLM straight into the model and let it do the actual work on every run. That's fine in a demo. In production it carries two costs. The first is tokens: every run ships a pile of context to the model and you pay for it, so the bill grows with every execution and every person who uses it. The second is variability: the same request can produce slightly different actions each time, which is the opposite of what a deliverable needs.

A pattern that scales better is to use the LLM once, at authoring time, to build a deterministic tool, and then run that tool as often as you like with no tokens to pay for and the same result every time. You pay for the intelligence when you create the thing, not every time you use it. A renumbering routine written with an LLM's help costs you tokens once; running it across four hundred projects afterwards costs nothing in tokens and behaves identically on all of them. The model's job is to help you write the tool, not to be the tool.

That's the bet behind Reope Toolmaker: use AI to turn an idea into a deterministic tool you can run as much as you want, rather than renting the model's attention forever. We'll write more about how that works in a future post.

We spend a lot of our time on exactly this line, working out which half of a design technology or BIM workflow wants a model, which half wants code, and where AI fits in between. If you're wrestling with the same question on your own automation, we're always happy to talk it through.