Topic 05

When Not to Use ML

Concept

Fresh from her first week, Iris does what every product manager does after discovering machine learning: she starts seeing uses for it everywhere. Personalized push notifications! Smart coupon amounts! An AI that picks the restaurant photo order! She brings the list to the data team, and their first lesson is not about any of her ideas. It is a rule, and it sounds almost hostile to their own profession: if you can write the rule, write the rule.

This page is that lesson. Machine learning is the expensive, permanently-imperfect option you reach for when rules genuinely cannot be written. Knowing when not to reach for it is the judgment call that separates people who understand ML from people who chant it — and it is a call you will be equipped to make by the bottom of this page.

If a Rule Exists, Code It

Take "free delivery on orders over thirty dollars". That is one line of ordinary code. It is exact — every order over the line qualifies, no exceptions, ever. It is explainable in one sentence to a customer or a regulator. It can be tested completely before launch, changes only when someone changes it, and costs nothing to maintain beyond the sentence itself.

Now imagine "learning" that rule instead: collect thousands of past orders, train a model to predict who gets free delivery, and accept that it will be wrong on some fraction of orders forever — while support fields angry emails asking why a $31 cart didn't qualify today. Every property got worse: exactness, explainability, cost, trust. Nothing was gained. Where a rule works, the rule is not the modest choice — it is strictly better.

What ML Actually Costs

The comparison above hints at the price list, so let's write it out. An ML feature needs collected examples — often thousands of them, labeled, cleaned, and kept fresh (Chapter 2 is entirely about this). It needs training, evaluating, and retraining as the world shifts (Chapters 3 and 7). It needs monitoring, because it can degrade silently. And it carries a permanent error rate: some predictions will simply be wrong, forever, and the product has to absorb that gracefully.

Here is a way to hold it: a hand-written rule is a stone — you place it once and it sits there doing its job. An ML model is a pet. It must be fed (data), taken to the vet (retraining), and watched (monitoring), and it will still occasionally bite a customer. Sometimes a pet is exactly what you need. But nobody sensible takes on a pet to do a stone's job.

Rule or model? — the three questions to ask about any idea

Can a person write the rule down exactly?→Write ordinary code — no ML

No writable rule — but are there recorded examples of the pattern?→No examples → collect data first

Examples exist — but is being wrong sometimes acceptable?→Errors intolerable → ML is the wrong tool

No writable rule + examples + errors survivable→A genuine ML candidate

Where ML Earns Its Keep

None of this makes ML a last resort — it makes it a specialist. It earns its cost in three situations, and Plateful has all three. First, when no rule can be written: fake-review detection, the melon problem from Topic 01. Second, when the decisions are too many and too individual for humans: personal restaurant recommendations for two million customers, refreshed daily — no team of humans can do that with rules or without them. Third, when the pattern shifts faster than rule-writers can follow: fraud, where every new rule is obsolete within weeks, but fresh examples keep arriving for a model to learn from.

Look at what the three have in common. In each, the alternative is not "a rule" — it is "nothing". That is the honest shape of a good ML use case: not replacing working code with something fancier, but doing what could not be done at all.

The Checklist, and Who Gets to Ask It

The figure above compresses this page into three questions: Can the rule be written? Are there recorded examples? Is being wrong sometimes acceptable? A "wrong answer" on any of the three — writable rule, no examples, zero error tolerance — means ML is the wrong tool for that idea, however exciting the demo would be.

Iris runs her list through the checklist. Smart coupon amounts survive: no writable rule, mountains of order history, and a slightly-off coupon hurts nobody. The photo-ordering idea dies instantly — the design team already has a simple rule (hero dish first) that works fine. Notice that nothing in the checklist needed math or code. These are product questions, and asking them is not intruding on the data team's turf; it is the most useful thing a non-engineer in the room can do. Half of this book is about asking better versions of exactly these questions.

Common Confusions

"More AI always makes a product better." An ML system is never exact and never free. Where a rule does the job, adding ML makes the product worse on every axis that matters — exactness, explainability, cost, trust.
"We have lots of data, so we should do ML." Data is a prerequisite, not a reason. Without a genuine pattern that rules can't capture — and tolerance for some errors — the project fails expensively.
"Once the model works, the work is done." A model is a pet, not a stone: feeding, retraining, and monitoring are permanent line items. Chapter 7 prices this out properly.
"Asking whether ML is needed is the engineers' question." The three checklist questions are product questions in plain English. Anyone in the room can ask them — and someone should.

Why It Matters

"Rule or model?" is asked in real product meetings every week, usually badly. You can now answer it with reasons — which is rarer in those meetings than you might hope.
Knowing ML's full price tag up front is what makes the rest of this book honest: every capability ahead comes with this page's costs attached.
The three-question checklist is your first reusable tool — it works on any "let's add AI" proposal, including the ones you'll hear this month.

Knowledge Check

Why is "free delivery over $30" a bad candidate for machine learning?

Plateful doesn't have enough order data to train on
The rule can be written exactly, so ordinary code beats a model
The pattern is far too difficult for any model to learn from the orders
Discount decisions are not allowed to be automated

Which costs does an ML feature carry that a hand-written rule does not?

Servers, electricity, and programmers' salaries
Expensive software licenses that hand-written rules would never require
Labeled data, retraining, monitoring, and a permanent error rate
Much slower responses for every customer request

A hospital wants a system where a single wrong dosage suggestion is absolutely unacceptable, with no human check in the loop. What does the checklist say?

ML is the wrong tool — a model is never exact, and this has no room for error
ML is fine as long as the hospital first collects a large enough training set
ML is fine if the model shows a confidence score with each suggestion
ML can never be used for anything in medicine

What do the three genuinely good ML situations — unwritable rules, too many individual decisions, fast-shifting patterns — have in common?

In each, ML replaces a hand-written rule that was already working perfectly well
In each, ML is cheaper than hiring more engineers
In each, the alternative isn't a rule — it's skipping the job
In each, being wrong carries no cost whatsoever

You got correct