When AI is actually worth it
Not every problem needs a model. A practical filter for deciding when to reach for AI and when a boring function wins.
- AI
- Engineering
There is a lot of pressure right now to put a model into everything. Some of it is warranted and a lot of it is not. We build AI features when they earn their place and push back when they do not. Here is the filter we actually use with clients.
Start by asking what the model replaces
A useful AI feature replaces something specific: a slow manual step, a search that does not work, a form nobody fills in correctly. If you cannot name the task it removes, you are adding a model for the demo, not the user.
The three questions
Before we reach for a model, we ask:
- Is the input messy and the output forgiving? Language, images, and free text are messy inputs. Summaries and suggestions are forgiving outputs. That combination is where models shine.
- Can a wrong answer be caught cheaply? If a mistake is visible and easy to correct — a draft the user edits — the bar is low. If a mistake ships silently to a customer's bank statement, the bar is very high.
- Would a plain function do? A regular expression, a lookup table, or a sort is faster, cheaper, and debuggable. If the rules are known, write the rules.
If the answers are "clean input, expensive mistakes, and the rules are known," you probably do not want a model. You want code.
Good fits we have shipped
- Retrieval over a company's own documents, so support staff stop hunting through wikis. Wrong answers are visible and the human stays in the loop.
- Classifying and routing inbound messages, where being right 95 percent of the time beats a rules engine nobody maintains.
- Drafting structured content that a person reviews before it goes out.
Bad fits we have declined
- Anything where the output is a hard number that flows into money or compliance without review.
- Replacing a deterministic workflow that already works, purely to say it uses AI.
The unglamorous truth
Most of the value in an "AI project" is not the model. It is the plumbing around it: clean data, evaluation so you know when quality drops, guardrails, and a fallback for when the model is wrong or the provider is down. When we quote an AI build, that plumbing is most of the estimate — and it is what makes the feature survive contact with real users.
More writing
Have a project that needs this kind of thinking?