When you can make the promise, do not place the bet. That sounds obvious written down, and it is violated constantly, expensively, by people who are not stupid — because nobody was ever promoted for saying “we solved it with an IF statement”.
You could use a calculator, or you could ask a very clever friend to estimate it in their head. Ask them both, as many times as you like.
Which would you use for an invoice? Nobody hesitates — and yet asking a language model to do arithmetic is asking the friend. It is not calculating. It is producing the most plausible-looking answer.
Right most of the time is a catastrophic property for an invoice.
This is the most common live violation you will see. Someone pastes a column of numbers into a chatbot and asks for the total. A spreadsheet has done that correctly since 1985, for free, and it does not have opinions.
The pattern behind that and every case like it: these are jobs where the answer already exists and merely needs retrieving or computing. Inference is for when the answer does not exist yet and must be guessed at from evidence. Pick a task and see what should really do it.
Skip the dictionary. Deterministic means: same input, same answer, every single time, and you can say in advance what it will be. Two questions settle it for any system. Try them on a few.
And then the interesting middle, which is where the real arguments happen. Should we approve this loan? Part of it is deterministic — is the applicant over 18, is the document valid, does the income clear the legal floor. Part of it is a genuine prediction — will they repay? Almost every real business decision splits like this.
Pick a dimension and see the gap.
That silent-failure row is the one people underweight. A broken rule throws an error. A degraded model just gets quietly worse while continuing to produce confident, plausible answers — far more dangerous than an outage, because an outage is at least noticed.
Here is the whole decision, as seven questions. Work down and stop at the first yes. Notice the order — the first three ask are you even allowed to guess? and the rest ask can a fixed rule keep up? Most bad projects fail because somebody started at question five and never asked one to three.
Ten pairs. Each pair is two tasks from the same business, sitting right next to each other. In every pair, one is a rule and one genuinely needs a model. Pick the one you think is the rule.
Two of those pairs run in the opposite order to what everyone expects, and they are the most useful ones on the page. Reading handwriting and transcribing speech genuinely need a model — and then a dead-simple rule checks the model’s work.
And the discount pair is worth its own minute, because both halves sound like the same topic. “Give the top tier ten percent off” and “decide who belongs in the top tier” feel like one question. They are completely different: one is a policy the company chose, the other is a prediction about the future.
Faster than the pairs, and closer to how the question actually arrives: one job at a time, described in plain business language. Rule, model, or both?
The five plain rules in that list — tax, free delivery, file type, notice period, invoice approval — are the ones where somebody, somewhere, has genuinely proposed using AI. It is worth imagining what that pitch sounded like.
Take one apparently simple job: validating a phone number. Three questions live right next to each other, and only one of them is a rule.
Which of those three did you assume “phone number validation” meant? Validation is not verification is not judgement. Most arguments about whether something needs AI are really arguments about which of these three questions is being asked — and they settle the moment somebody states the question precisely.
It is worth making the alternative concrete. Suppose you built a model for the formatting question instead. You would need thousands of labelled examples, and after all that work you might reach 99.7% accuracy — meaning three wrong in every thousand, forever, with no way to know which three. It would cost money on every call. And when a customer asked why their perfectly good number was rejected, nobody could tell them.
You would have spent real money to make a solved problem worse and unexplainable.
The principle is not “never use AI”. It is do not use AI where a rule already works — and in practice that produces a layered design, which is what almost every well-built production system looks like.
Layer one is what can be decided with certainty before any model runs. Layer two is what genuinely needs a judgement. Layer three is the rules that sit on the model’s output before anyone acts on it. Seven different problems, one shape.
In every one, layer one handles most of the volume and the model only ever sees the genuinely uncertain remainder. That is not a compromise — it is what makes the system cheaper, faster and more defensible than a pure model would be.
Why not rules alone? Because in some domains there is an adversary. Someone with a stolen card will probe — a small amount, then a larger one — until they find where the wall is. A fixed threshold tells an attacker exactly where to stand.
Why not a model alone? Two reasons. Some cases are certain — a frozen account needs no judgement, and paying for a prediction there is pure waste. And you must be able to say why you blocked someone’s rent payment. “The model scored 0.91” is not an answer a customer or a regulator accepts.
That last point is the half nobody teaches. Predicting that a customer is likely to leave is a model. What you do about it — who gets a call from a human, who gets an automated email, what discount anyone is authorised to offer — should be a rule. Nobody would accept a model deciding on its own how much money to hand out. That is a policy, and policy is written by people.
You will meet this. The productive move is not to argue about AI — it is to ask what job it is doing. Pick what they said.
The fair, non-cynical version of all of this: the goal is not to keep AI out. It is to spend it where it earns its cost. Every rupee spent modelling something an IF statement would have handled exactly is a rupee not spent on the problem where nobody can write the rule — and that problem is where all your competitive advantage actually is.
State this yourself, before someone else does, or the principle sounds dogmatic. Rules rot. A rule is a snapshot of the world at the moment somebody wrote it. When the world moves, the rule does not. Watch it happen.
So the principle is not “rules are better than models”. It is narrower and more useful:
Rules are better than models where a rule is genuinely available — and available means it will still be correct next year.
Three warning signs that your rule has stopped being available: somebody has to update it every few weeks; the list of exceptions is longer than the rule; the person who understood why the thresholds were chosen has left. Any of those, and you have a machine learning problem you are currently solving by hand.
And the mirror-image failure is equally real. Forcing a rule onto something inherently uncertain is its own kind of mistake. A hard rule that rejects every applicant under a certain age is deterministic, explainable and cheap — and quite possibly both wrong and discriminatory. Determinism guarantees consistency, not correctness.
Two lines to keep. A rule is a promise and a model is a bet, so when you can make the promise, do not place the bet. And the point is not to use less AI — it is to spend it where nobody can write the rule, because that is the only place it can win you anything.