Every engineering team eventually meets the meeting where someone suggests machine learning. Sometimes it is the right call. More often the problem is one that a few hours of thought, a lookup table and an afternoon of plumbing would solve outright — with the enormous advantage that everyone can read the result and see why it did what it did.
The rules already exist
If somebody in the business can write down the rule on a whiteboard, write it in code. A model trained to rediscover a policy you already know is a slower, fuzzier, less auditable copy of a document you could have read. Worse, when the policy changes you cannot simply edit it — you have to retrain and hope.
You cannot afford to be wrong
Every model is wrong sometimes; that is the deal. What varies is what a mistake costs. A recommendation that misses is a wasted slot on a page. A misread medical scan or a wrongly declined application is a different category of event, and the right design is usually not “no model” but “a model that hands the hard cases to a person”.
Signs you should stop and reconsider
A few patterns tend to show up early, well before a project has burned a quarter:
- Nobody can define success. If the team cannot say what a good prediction looks like, no amount of training will find one.
- The labels do not exist. Not “the data is messy” — genuinely nobody has ever recorded the outcome you want to predict.
- The world changes faster than you can retrain. A model tuned to last season’s behaviour is a liability in a market that moves weekly.
- You need an explanation, not an answer. If a regulator or a customer will ask “why”, start from something you can narrate.
The boring baseline is doing real work
Before anything more ambitious, build the dumbest thing that could possibly work: predict the most common answer, or the last known value, or the average for the group. It takes an afternoon and it gives you the number that every later model has to beat. Teams routinely discover their elaborate system is two points better than “guess the average” — which is a fact worth knowing before it ships.
The question is never whether a model would work. It is whether the model earns the complexity it costs you for the next five years.
None of this is an argument against machine learning. It is an argument for spending the complexity where it buys something — and for being honest, early, about the cases where a well-written rule and a clear log file will serve everyone better.