Deterministic Code in the Loop
What's old is new again. LLMs shouldn't always be determining done-ness
Deterministic Code in the Loop
I was sitting in the HCA Healthcare presentation at Google Cloud Next, and a thought that had been forming for months finally snapped into focus.
We’ve spent the last two years debating whether humans or AI should be making decisions in production workflows. That’s the wrong debate. There’s a third option that nobody is naming, and it’s the one that actually gets enterprise AI past pilot.
The Governance Gap
If you’ve read the revised 4+1 Enterprise AI Field Manual, you know I’ve been developing an Inter Loop Governance framework. The core question isn’t “what can the AI do?” It’s “what determines done?” When an AI system completes one iteration of a workflow — generates a summary, scores a risk, classifies a document — who or what decides whether that output is good enough to move downstream?
Right now, the industry gives you two answers.
Human in the loop. A person reviews the AI’s output before it proceeds. This is the answer everyone defaults to because it feels safe. It’s also the answer that dies the moment you try to scale. You cannot put a human reviewer in front of every AI-generated clinical note, every invoice classification, every compliance check. The math doesn’t work. If your AI system is processing thousands of transactions per hour, human review becomes the bottleneck that kills your ROI — which is exactly why 77% of enterprises aren’t seeing returns on their AI investments.
AI in the loop. The model evaluates its own output, or a second model evaluates the first. This is where the agentic crowd is headed. It works for certain tasks, but it’s probabilistic by nature. Ask the same model to evaluate the same output twice, and you might get different answers. Try explaining that to an auditor. Try explaining it to a regulator in healthcare or financial services. The bar for letting AI determine “done” needs to be very high, and most enterprises haven’t done the work to understand where that bar should sit.
So you’ve got one option that doesn’t scale and another that can’t be audited. And in between, there’s a gap. That gap is where most enterprise AI projects go to die.
What I Realized at Google Cloud Next
Watching the HCA presentation, it became obvious. Healthcare is the domain where this governance gap is most visible. You’re dealing with patient data, clinical decisions, and regulatory requirements that demand auditability. You can’t have a nurse reviewing every AI-generated output — the volume makes that impossible. But you also can’t let a probabilistic model decide whether a clinical summary is complete enough to move to the next step. The stakes are too high and the compliance requirements are too strict.
What you need is something in between. Something that scales like AI but is auditable like human-written policy. Something deterministic.
Deterministic Code in the Loop
Here’s the term I’m coining: deterministic code in the loop.
The AI reasons. The code decides.
Let the LLM do what it’s good at — reasoning over unstructured data, pattern recognition, summarization, extraction. But when it comes to the governance decision — does this output meet the criteria to move forward? — that decision gets made by explicit, version-controlled, inspectable code.
Not a model. Not a prompt. Code.
Code that you wrote. Code that you tested. Code that you can point an auditor at and say: “This is the rule. It runs the same way every time. Here’s the git history showing every change we’ve ever made to it.”
This isn’t a novel software engineering concept. It’s a policy engine. It’s a rules layer. It’s the kind of thing enterprises have been building for decades in other contexts. But somehow, in the rush to make AI more autonomous, we forgot that the most valuable thing about software is that it’s deterministic. It does exactly what you told it to do. Every time. It doesn’t hallucinate. It doesn’t drift. It doesn’t have a bad Tuesday.
Where This Sits in DAPM
If you’re familiar with my Decision Authority Placement Model, deterministic code in the loop gives you a concrete implementation pattern for decisions classified as “Delegated.” You’re not delegating to the AI. You’re delegating to code. The AI is an input to the decision function, not the decision-maker.
This is the distinction most enterprises are blurring right now, and it’s the core reason they can’t get past pilot. They haven’t separated the reasoning from the deciding. They’ve let the model do both, and now they can’t explain their system’s behavior to the people who need to approve it for production.
The classification of which governance pattern to apply — human, deterministic code, or AI — is itself a DAPM exercise. You’re placing decision authority. Some decisions stay with humans. Some get delegated to code. And only the decisions where you’ve consciously accepted probabilistic risk and can justify that acceptance should go to AI.
The Counterintuitive Insight
The industry is obsessed with making AI more autonomous. More agentic. More capable of end-to-end execution without human intervention.
The actual unlock for production AI is making it less autonomous. Constrain it with deterministic code that enforces policy. Let the AI do the thinking. Let the code do the governing. That’s how you get scale and auditability in the same architecture.
This isn’t a limitation. It’s a design pattern. And the enterprises that figure this out first are the ones that will actually get to production.
Deterministic code in the loop is part of the Inter Loop Governance framework covered in the revised 4+1: The Enterprise AI Field Manual. If you want the full architectural context for where this pattern fits, that’s where to start.