Chris M.Reviewed
Where AI Belongs, and Where Code Belongs
Almost every expensive mistake in an AI project comes from getting one decision wrong, and the decision is not complicated. Before anything else is designed, bought or built, ask whether the correct answer to a task can be written down as a rule, a formula or a database constraint. If it can, that task belongs to deterministic software. If it cannot, because the task needs interpretation, ambiguity resolved, language understood or judgement exercised, that task belongs to an AI model.
This is part one of the AI and Software Architecture Translation Guide, a six part series on how modern AI systems are actually assembled. The full guide covers all six parts on one page.
Why the decision comes before any other
If a system needs to multiply a quantity by a rate, that is code. It is exact, repeatable, costs nothing per run once it is written, and can be audited line by line. Asking a language model to do it instead introduces cost, latency and a small but real chance of a wrong number nobody can trace back to its source.
You would not ask a commercial director to multiply every quantity by every rate by hand. Equally, no spreadsheet formula can read a vague site note, work out whether a verbal instruction was a variation, or compare the meaning of two differently worded specification clauses. Both are tools. The skill is placing the right one on the right task, and the placement decides most of what a system will cost to run and how much you can trust its output.
Every AI call has a price, a delay and a failure mode. Deterministic code has none of the three in the same way. A system that routes routine arithmetic through a model is paying a subscription to be less reliable than the code it replaced, and in a delivery business running thousands of small operations a day, that difference compounds quickly.
Rule of thumb. If the correct answer can be expressed reliably as a fixed rule, formula or database constraint, start with software, not a language model. Reach for the model at the point where the rule stops being writeable, not before. PostgreSQL's own documentation on constraints is worth reading for how much a database can already enforce before any AI system is involved at all.
What makes a task complex enough to need a model
Complexity is not the length of a task. It is the number of ways it can quietly go wrong. Six factors decide how much intelligence, evidence and human control a piece of work actually needs, and the first five are a different question from the sixth.
| Factor | What it asks |
|---|---|
| Long horizon | Does the answer depend on a chain of steps, where an early error invalidates everything after it? |
| Ambiguity | Is the information incomplete, contradictory, novel or badly structured? |
| Trade-offs | Do several valid options exist, with downstream effects that have to be weighed against each other? |
| Context | Does the answer need drawings, specification, correspondence, programme and cost read together? |
| Self-correction | Might the system need to try something, recognise failure, and take a different route? |
| Consequence | If a wrong answer gets through, what does it cost? |
The first five factors tell you how much intelligence to buy. The sixth tells you how much control to build, and it is a separate decision that both have to be made. Counting a payment certificate is not complex. Getting it wrong is. That is consequence acting alone, and it is the factor most often missed when a workflow gets designed around what a model can do rather than around what a wrong answer would cost.
Where code and a model actually meet
Traditional software follows explicit rules: same input, same output, because the logic is written down. An AI model infers a likely output from patterns and context: useful, not guaranteed, and something that needs evidence behind it rather than trust alone. Good architecture combines both and stays very clear about which one is doing what.
| Deterministic code | AI model | |
|---|---|---|
| Typical work | Quantity times rate, date arithmetic, duplicate detection, mandatory field checks, permissions and identifiers | Extracting a figure from a messy PDF, classifying an event from a site note, summarising correspondence, comparing two differently worded clauses |
| Cost per run | Effectively nil | Real, every call |
| Failure mode | Visible and traceable: a constraint is violated, a job errors, an alert fires | Fluent, confident and easy to miss |
That last row is the one worth sitting with. When code fails it usually fails loudly. When a model fails it can produce a well written answer that is wrong in a way that reads as correct. That asymmetry is the reason the deterministic layer should carry as much of the load as it can, and the reason anything left to a model needs evidence attached to it rather than being taken on trust.
In practice the two work in sequence. A model reads messy input and proposes structured values. Code then checks those values against known project codes, valid ranges, existing records and mandatory fields, and flags anything that fails rather than accepting it silently. The model does the reading. The code does the enforcing. Anthropic's own guidance on building effective agents draws a related distinction, between predictable workflows and open-ended agents, one level up from this one; the underlying judgement is the same, predictability where a task allows it against flexibility where it does not.
A test to apply in any design review. Ask whoever is proposing a system to point at the exact line where the model stops and the code starts. If they cannot draw that line, the system has not been designed. It has been prompted.
Setting out on site is deterministic. Interpreting a badly drawn detail is not. Nobody would use the same person, the same instrument or the same tolerance for both, and a system built on this guide's routing matrix applies the same discipline to every task before it decides which model tier, if any, a piece of work should reach.
Next: the model tiers themselves, what they cost as at August 2026, and why capability and account access have started to separate. If you would rather have this mapped against your own workload first, AI Metric runs that exercise with contractors and consultants directly.
Sources
- 1.AI Metric Ltd, AI and Software Architecture Translation Guide, edition v3.1PrimaryAccessed
- 2.Anthropic, Building effective agentsPrimaryAccessed Anthropic's own framing is workflows against agents, not code against a model call; the distinction this guide draws is one level below that, but the underlying judgement, predictability for well-defined tasks against flexibility for open-ended ones, is the same one.
- 3.PostgreSQL Global Development Group, PostgreSQL documentation: constraintsContextAccessed
Published , last reviewed . This guide explains general principles and is not legal, contractual or safety advice. The position on any project depends on the contract signed and the facts of that project.