Three tools, briefly
Deterministic software is code that follows explicit rules. If the tax rate is 8.25%, you multiply. It is fast, cheap, testable, and it fails in ways you can enumerate and fix. Its weakness is that it only handles inputs you anticipated. Feed it something the rules did not cover and it either errors or does something dumb with great confidence.
Automation — in the sense of scripts, pipelines, integrations, scheduled jobs — is deterministic software's workhorse cousin. It chains known steps together to remove human toil from predictable processes. It is not smarter than the rules you gave it; it is just tireless. Most of what gets called "AI automation" in marketing copy is, on inspection, ordinary automation with a model bolted onto one step.
AI, meaning a model exercising judgment, earns its place when the input is genuinely open-ended and the rules would be endless. Reading arbitrary documents, interpreting fuzzy requests, drafting language, classifying things that resist clean categories. It handles the long tail that deterministic rules cannot. In exchange, it is slower, more expensive per call, and probabilistic — which is a polite way of saying it will occasionally be wrong in ways you did not predict.
A decision order that saves money and grief
We work through candidates in a specific order, and the order matters because it is roughly ascending in cost and descending in predictability.
First, ask if deterministic code can do it. If the logic can be written as rules — even a lot of rules — write the rules. Validating an email format, calculating a total, routing a request based on known fields, enforcing a policy: these are solved problems that do not improve when you add a probability distribution. Deterministic code here is not the unambitious choice; it is the correct one.
If not, ask if automation can chain existing deterministic pieces. A great deal of "we need AI" turns out to be "we need three systems to talk to each other on a schedule." Integrations and pipelines are unglamorous and extremely reliable. Verification workflows are a good example: tools like Playwright can deterministically confirm that a web flow behaves as expected, which is exactly the kind of check you do not want a model to eyeball.
Only then, ask if the job needs judgment on open-ended input. If the honest answer is that the input space is too large and irregular to enumerate — real human language, unpredictable documents, ambiguous intent — that is where a model earns its cost. Reach for it with intent, not as a reflex. The major platforms are well documented for exactly these cases; start from primary sources like the OpenAI, Anthropic, and Google Gemini docs rather than a vendor's launch blog.
The elegant part is that these tools compose. The best AI-native systems are usually mostly deterministic, with automation moving things around, and a model applied to the one or two steps that actually need judgment. The model reads the messy document and proposes a structured result; deterministic code validates it; automation carries it downstream. When a model needs to reach into other systems, a standard like the Model Context Protocol keeps that boundary clean, but the model is still one component in a larger, mostly boring machine — not the machine itself.
The cost conversation nobody starts early enough
Deterministic code and automation have costs that are basically fixed: you pay to build them, and running them is nearly free. Model calls have a marginal cost on every single invocation, and that cost multiplies by volume in a way that surprises teams who prototyped on a hundred requests and shipped to a million.
We have seen features that were delightful in a demo become quietly unaffordable at scale, not because the model got worse but because someone routed a high-volume, perfectly deterministic step through it. A classification that a lookup table could do for free was costing real money per call, at millions of calls, to produce an answer that was occasionally worse than the table would have been. When you catch that early, it is a design note. When you catch it on the invoice, it is a fire drill.
So we put cost in the decision from the start. If a model is doing a job that a cache, a rule, or a lookup could do, that is not innovation — it is a recurring tax you are paying for the privilege of unpredictability.
What This Looks Like in Practice
- Define "reliable enough" up front. Before choosing a mechanism, we write down the acceptable error rate and what a wrong answer costs. A job where mistakes are expensive tilts hard toward deterministic code, even when a model could technically do it.
- Work the decision order. Deterministic → automation → AI, ascending in cost and uncertainty. Stop at the first tool that clears the reliability bar.
- Compose, don't replace. Use a model for the judgment step and wrap it in deterministic validation and ordinary automation. Most of the system should be boring.
- Price the marginal call. Multiply the per-call cost by realistic production volume before committing a high-traffic step to a model.
Common Mistakes
- AI as the default hammer. Reaching for a model because it is interesting, then bending a deterministic problem to fit it. The tell is a model doing arithmetic or format validation.
- Ignoring failure modes. Deterministic code fails predictably and loudly; models fail unpredictably and sometimes silently. Putting a model on a step where silent wrongness is dangerous, without a check behind it.
- Prototype pricing. Validating cost on a tiny sample and discovering the real bill only at scale.
- Automation cosplay. Calling ordinary integration work "AI" so it sounds modern, which sets wrong expectations and invites a model where none is needed.
