When an enterprise workflow mixes AI with ordinary software, the first design decision is not which model to use. It is which steps should be deterministic code and which steps deserve model judgment. Draw that line in the wrong place and both sides fail in their own way: rules hard-coded where interpretation is needed break the moment a real input arrives, and model judgment applied where a fixed rule exists can give different answers to identical cases. This post explains how we think about where the line goes, and why neither side of it works without correct inputs and tests. As generative AI moves from demos into production workflows, that line decides more of the outcome than model choice does.
What deterministic code should own
Deterministic code covers any step that must produce the same output from the same input, every time:
- Calculations: totals, taxes, discounts, unit conversions, currency rounding.
- Fixed business rules: eligibility thresholds, approval routing by amount, credit limits.
- Validation: required fields, formats, ranges, cross-field consistency.
- Ordering and set operations: sorting, deduplication, merging records.
The test for belonging here is simple: if the business can write the rule down and it does not change case by case, it belongs in code. Code is reviewable, testable, and auditable in a way a model’s reasoning is not. When a finance head asks why a number is what it is, “the pricing rule in version 14 of the rate master” is an answer. “The model decided” is not.
Where LLM judgment earns its place
Model judgment belongs in interpretation tasks: turning variable, unstructured input into structured understanding.
- Reading an enquiry email that arrives as free text and extracting what is actually being asked.
- Pulling requirements out of a statement of work whose structure changes from client to client.
- Classifying incoming documents, summarizing conversations, and drafting text that a person will review. A dedicated classifier model or a general model with a tight prompt both work here; the choice is an engineering detail, not a strategy.
The common property is that inputs vary in form and the task is to produce an interpretation, not a number. A rule-based parser for free-text enquiries tends to break on every new phrasing; a model usually reads the intent. This kind of structured data extraction is where agent workflows earn their place: a judgment step inside a larger deterministic pipeline. The output of a judgment step should still be structured and checkable: extracted fields, each with a reference to the source passage, not a paragraph of prose nobody can verify.
The line moves over time
Where judgment repeats and stabilizes, it should harden into rules. When a reviewer corrects the model’s extraction the same way three times, that correction is a rule waiting to be written down. Keeping those rules as editable reference data, rather than buried in code, lets the business change a threshold or a mapping without a redeploy. The boundary between code and judgment is not drawn once at design time; it is maintained as the workflow learns where the variability actually lives.
Code does not excuse you from inputs and tests
Deterministic is not the same as correct. A pricing rule computed from a stale rate master is deterministically wrong: perfectly repeatable, reliably incorrect. Both sides of the line need their own discipline. Code gets tests: known inputs, expected outputs, edge cases, and the boring cases like zero, blank, and negative numbers. Model steps get evaluation sets: a fixed sample of representative inputs with reviewed outputs, rerun whenever the prompt, the model, or the surrounding code changes. These are LLM evals in the plain sense: code-based evals with known expected outputs, and a short error analysis of the failures shows whether the prompt, the model, or the parser regressed. Different mechanisms, same habit. And both depend on inputs. An extraction error upstream flows silently into a flawless calculation downstream, which is why validation belongs at the hand-off between judgment steps and code steps.
What the checking machinery looks like
The checks that keep both sides honest are themselves deterministic code, and they deserve as much design attention as the model steps. In a healthy build, model output flows into a validation and correction loop: a schema rejects a missing field, a range check rejects an impossible date, and the step reruns or routes to a person instead of passing bad data downstream. Keeping a human in the loop for the cases the checks reject is a design choice, not an admission of failure. This is the same discipline ordinary software engineering already runs on. Test harnesses execute regression tests on every change inside CI/CD pipelines, test coverage targets decide what must be exercised before a merge, and a stack trace from a failed run points at the exact deterministic behaviour that broke. Teams that track delivery performance with DORA metrics are measuring whether that machinery works, not whether the code was written by a person or a model. When the checking layer is weak, the model tends to get blamed for failures that are really missing validation. Accuracy validation on a fixed sample, run regularly, is what separates a working check from a reassuring one.
A worked example (synthetic)
An illustrative example from an enquiry-to-quote workflow. The scenario uses synthetic data throughout: it shows the shape of the workflow, not any client engagement. A manufacturer’s sales team receives enquiries as free-text email:
- Model judgment: read the enquiry and extract items, quantities, materials, and deadlines into structured fields, each linked to the sentence it came from. Flag anything missing rather than guessing.
- Deterministic code: validate the fields, look up prices in the current rate master, compute line totals and taxes, and apply the discount rules the business wrote down.
- Model judgment: draft the covering note a salesperson will edit.
- A person: approve before anything goes to the customer.
Swap any of these and the failure is predictable. A model computing totals can produce uncheckable numbers that vary between runs. Code parsing the free-text enquiry tends to break on the first unusual phrasing. Removing the human approval sends unreviewed interpretation straight to a customer.
Where this shows up in modern tooling
The same line-drawing is happening across software engineering right now, under different names. In LLM-based workflow automation, the reliable systems wrap probabilistic model steps inside a deterministic system: fixed orchestration logic decides what runs when, and the model fills only the steps that need interpretation. In code generation specifically, the strongest results come from treating the model as a draft producer inside a deterministic build: generated code is checked by compilers, static analysis, and regression tests before it is trusted, not because the model is careless, but because “looked right” is not a verification method.
The boundary in code generation often sits at explicit contracts. A model can draft an implementation, but API calls and function signatures are fixed agreements with the rest of the system, and a mismatch fails loudly at compile or integration time rather than silently in production. It is also worth remembering where the model’s ability comes from: much of it is learned from open source code, so common patterns come out well and a company’s idiosyncratic internal conventions come out poorly. That is one more reason a generated draft lands inside a deterministic build, reviewed and tested, instead of going straight to production.
Deterministic logic also has a maintenance advantage that matters to enterprises: when the rules live in code and data, a change is a diff with a reason attached, and a regression test proves the rest of the system still behaves. That discipline, deterministic where the business needs guarantees and judgment where inputs demand interpretation, is what makes an AI workflow operable rather than impressive.
How to draw the line on your own workflow
Four questions settle most of the boundary:
- Is the rule written down, and does it change case by case? Written and stable means code.
- What does a wrong answer cost, and who discovers it? The higher the cost, the more the step belongs in tested code, under human review, or both.
- Can the output be checked mechanically? If yes, generate it however you like, but check it with code.
- Does the input arrive in a fixed form? Fixed forms favor code; free-form input favors judgment.
This is also the shape of the structured build path we described in why Jinja2 belongs in a structured workflow build: deterministic generation for what must not vary, model judgment in bounded steps, and review at the boundaries.
If you are mapping an enterprise workflow and want a second pair of eyes on which steps should be code, which should be judgment, and where the checks belong, book a working session with our team: https://digibull.ai/book-consultation/
