When Not to Use Learning

1When not to reach for learning

If a short deterministic procedure solves the task, write the procedure. It is cheaper to build, it never drifts, its failures are legible, and it is never wrong about its own rule — a fitted model can only approach the certainty the rule starts with.

The clean case: a form whose declared total must equal the sum of its lines. The check is one line of arithmetic. A model trained on labelled forms would 'learn' that identity approximately — a strictly worse artefact acquired at strictly higher cost.

The test has three parts, and the procedure must pass all of them: you can write the policy down, exactly (no 'usually'); it is short enough to maintain; and it is stable — the rule tomorrow is the rule today. 'I could write it down but it would take ten thousand branches' fails the second clause, and that failure is real information: it is what 'the mapping is hard to write by hand' actually means.

Learning earns its keep precisely where the test fails: nobody can list every way spam looks, every pixel pattern that makes a cat, every phrasing of a complaint. That boundary — writable versus unwritable — is the single most useful line in this lesson.

Figure. If a short deterministic procedure solves the task, write it — a form whose declared total must equal the sum of its lines. Learning earns its keep where nobody can list every way spam looks, every pixel pattern that makes a cat, every phrasing of a complaint. Rules claim the writable end; learning the other.

The procedure test

1. Write itTry to state the policy in a few exact sentences or lines of code — actually try, on paper.
2. Check exactnessNo 'usually', no 'looks like': if the statement needs judgement words, it is not a procedure.
3. Check stabilityAsk what changes it — a rule revised weekly by the world is a mapping, and mappings are learned.

2Rules, search, learning: one shelf

Classical AI's honest summary is that there are three ways to get intelligent behaviour, and they are ordered by how much you must know in advance. If you know the policy, write rules. If you know the world — the states, the moves, their costs — but not the policy, search: the algorithm derives behaviour from your model of the world, which is exactly what the coming search lessons build. If you know neither, but you have examples, learn.

The order matters because each step down surrenders something. Rules are inspectable and provable; search is optimal relative to a world model you can audit; a learned model is a statistical artefact whose guarantees are only as good as its data and its eval. Never trade down for fashion: choose the highest tool on the shelf that fits what you actually know.

The classification is per sub-problem, not per product. A chess engine searches, its position evaluation may be learned, and 'never leave the king exposed' can be hard-coded. A payments system learns a fraud score, searches nothing, and enforces legal limits with rules. Decomposing a task into parts that each get the right tool is most of what senior engineers mean by architecture.

Figure. Three exits from one question: what do you already know? The policy itself — write it. The states, moves and costs — search will derive the policy. Only examples of inputs and answers — learn, and accept the eval and monitoring bill that follows.

3The bill arrives after training

The visible cost of a learned system — the training run — is the cheapest line on its invoice. The bill that decides build-versus-rule arrives afterwards, in three instalments that recur for the life of the system.

First, data: supervised learning is a machine for converting labelled examples into behaviour, and labels are bought with human hours. The ledger below prices a modest labelling job; production systems consume that continuously as the world drifts.

Second, failure modes you cannot enumerate: a rule fails where its clauses say; a model fails wherever its training distribution ran thin, and it fails silently, with full confidence. You cannot write the list of those places down in advance — that is the whole reason you could not write the rule.

Third, monitoring: because the failures are silent, a learned system without drift detection, slice dashboards and a rollback plan is not unfinished, it is unsafe. None of this appears in the demo, which is why the demo is not the decision — the evaluation lesson's offline-versus-online loop is this same bill, seen from the metrics side.

Figure. The training run is the cheapest line on the invoice. A first fraud model of 10,000 labels at about 2 minutes each is about 42 analyst days — and you pay it again when patterns shift. Failure modes you cannot enumerate, plus monitoring for the life of the system, sit in the tail after demo day.

4Rules fail loudly; models fail silently

The two artefacts do not merely differ in accuracy; they differ in how they are wrong, and operations is built around that difference.

A rule fails at its written boundary: the case not covered raises an error you can read, point to, and patch, and the fix provably does not touch the other clauses. A model fails off its training distribution: it produces an answer anyway — often with high confidence — and nothing in the output distinguishes the failure from a success. The defect is discovered downstream, by its damage.

Change management inverts too. A rule change is a diff a reviewer can reason about clause by clause. A retrain changes behaviour everywhere at once by an amount nobody can bound, which is why model rollouts borrow the machinery of experiments — canaries, shadow traffic, rollback — rather than the machinery of patches.

Neither mode is better; they are different budgets. Rules spend engineering time before deployment; models spend vigilance after it. The mistake is running a model with a rule's operational habits — deploy and forget — because 'it passed the eval'.

The figure in words: two timelines side by side — the rule system's flat line broken by one sharp, labelled spike at its boundary case; the model's line drifting smoothly off course with no spike at all, the error visible only when the two lines are compared at the end.

5Hybrids: learning perceives, rules guarantee

Real products rarely choose one tool; they compose them, and the composition has a load-bearing rule: learning handles perception, rules hold the guarantees, and the guarantee sits downstream of the score so that no model output can override it.

The payments shape from the what-is-AI lesson, now as architecture: a learned model scores each transaction's fraud probability — the unwritable mapping — and a rule layer after it enforces the written law, blocking any transfer above the legal limit whatever the score says. The model may be wrong; the limit may not.

The direction matters more than the components. Put the rule upstream as a mere feature and the model can learn to route around it; put it downstream as a constraint and it is unconditional. When a guarantee breach ships, the failure is architectural — a constraint was made to depend on a score — before it is a modelling error.

This is also how to read incidents: every layer owns a failure class. Score wrong: model incident — retrain, re-evaluate. Limit breached: rule-layer incident, even if the model also missed. A hybrid without that ownership map degenerates into 'the AI did it', which is another way of saying nobody is accountable.

Figure. The guarantee sits after the score. The learned layer produces a probability that may be wrong; the constraint layer holds the written law and cannot be outvoted by it. Reverse the order and the guarantee becomes a suggestion.

Reading a hybrid incident

1. Locate the layerAsk which layer's contract broke: a wrong score or a breached guarantee — they are different incidents.
2. Check the directionConfirm the constraint sits downstream of the score; a guarantee a model can override is already a defect.
3. Assign the fixModel incidents get retraining and eval updates; rule incidents get a code change and a regression test.