The AI hype cycle has pushed many teams to use models for tasks that would be better served by deterministic code. The result is slower, more expensive, less reliable systems. The discipline is to use AI where it shines and code where it shines, and to know the difference.
The comparison is stark when written as a table. Code: exact, instant, effectively free per call, testable with assertions, fails loudly. Models: probabilistic, hundreds of milliseconds or more, metered per call, testable only statistically, and fail plausibly, which is the dangerous part. A model asked to do arithmetic does not error; it returns a confident wrong number. Every property that makes models magical for fuzzy work makes them a liability for exact work.
The decision rule
Use deterministic code for any task with a clear correct answer that can be specified in rules. Use AI for tasks where the input is unstructured, the correct answer is fuzzy, or the rules cannot be enumerated up front. The mistake is using AI for both because AI is exciting.
Two questions sort almost every case in practice. First: could a precise spec for this task fit on one page? If yes, write the code; the spec is the code. Second: when it fails, must it fail loudly? Money movement, permissions, quotas, and anything compliance-adjacent must fail loudly, which rules out models on the critical path regardless of accuracy. A 99% accurate model doing validation is a 1% silent-corruption generator running at scale.
Where the line is
Routing, validation, calculation, formatting, and most workflow logic are deterministic. Summarisation, classification of unstructured text, generation, extraction from messy documents, and similarity matching are AI. The architecture should reflect this: deterministic shell, AI core where it earns its place.
The shell pattern in one sentence: code decides whether and with what, the model transforms, code verifies what came back. Deterministic pre-processing gates the inputs, the model does the one genuinely fuzzy transformation, and a deterministic post-layer validates the output against schema and bounds before anything downstream trusts it. Teams that invert this (model orchestrating code) inherit variance in their control flow, which is the most expensive place to have it: the same request taking two different paths on two different days is a support ticket generator.
The hybrid patterns that actually work
The best systems use the model to propose and code to dispose. The model extracts fields from a messy document; code validates every field against type, range, and business rules, and anything failing validation routes to review rather than through. The model drafts the classification; code applies the threshold and the consequences. The model suggests the mapping once; an engineer reviews it and freezes it into a lookup table, so the model's judgement gets amortised into deterministic speed. In each pattern the model contributes judgement exactly once, and everything load-bearing stays testable.
The cost of getting it wrong
Using AI for deterministic work means you have introduced variance, latency, and cost where you had none. Using code for fuzzy work means you have shipped a brittle system that fails on every new input pattern. The discipline is recognising which is which before you reach for either.
A quarterly audit closes the loop: list every model call in the product and ask which ones now have stable enough behaviour to be replaced by rules or a cached mapping. Models are excellent scaffolding for discovering the spec; once the spec stops changing, promote it to code and spend the saved tokens where the fuzz actually lives.