The most important decision in any AI project is the one teams skip: whether to use AI at all. In a climate where every roadmap has "add AI" written on it, the reflex is to reach for a model first and find the problem later. That is backwards, and it produces expensive, unreliable features that a few lines of ordinary code would have handled better. Before anything else, ask the honest question: does this actually need a model?
AI Is a Means, Not a Goal
"Use AI" is not a product requirement; it is an implementation choice, and often the wrong one. Users do not want AI - they want their problem solved reliably, quickly, and cheaply. If deterministic code solves it, that is almost always the better answer: it is faster, cheaper, testable, predictable, and it never hallucinates. Reaching for a model when a rule would do is choosing a slower, pricier, less reliable tool to look modern. The goal is the outcome; AI is one way to get there and should have to earn its place.
The Test: Is the Problem Fuzzy or Crisp?
The cleanest dividing line is whether the task has a crisp specification or a fuzzy one. If you can write down the rules - if this, then that - use code. Tax is math; a state machine is logic; a lookup is a lookup. But some problems genuinely resist specification: understanding messy natural language, summarizing, judging tone, extracting structure from unstructured text, handling the near-infinite variety of human phrasing. Those are the tasks where writing the rules is impossible and a model earns its cost, because it generalizes over a space you could never enumerate.
Can you write the rules down?
Yes -> use code. It's cheaper, faster, testable, exact.
No, but you can show examples of good vs bad output
-> AI is a candidate. The task is fuzzy by nature.
No, and you can't even judge good vs bad
-> stop. You can't build OR evaluate it yet.The Cost-of-Wrong Question
Even when a task is fuzzy, ask what a wrong answer costs. AI is probabilistic; it will be wrong some fraction of the time. If the task is high-volume and a mistake is cheap and correctable - a suggested tag, a draft email - AI fits beautifully. If a single wrong answer is catastrophic or irreversible and there is no human check, the probabilistic nature of the model is a liability, not a feature. The right frame is not "can AI do this?" but "can we tolerate AI being wrong at this, and can we catch it when it is?"
The Hybrid Answer Is Usually Best
The false choice is "AI or code." Mature systems use each for what it is good at: deterministic code for the parts that are crisp, exact, and must be right; a model for the narrow fuzzy step in the middle that code cannot express; and validation code wrapped back around the model's output to catch its mistakes. Let AI do the one thing it uniquely can - turn messy language into something structured - and let ordinary software do everything around it. The best AI features are mostly not-AI.
Why This Decision Pays Off
Getting this right early saves enormous cost and pain. Every task you correctly route to deterministic code is a task that is cheaper to run, easier to test, impossible to hallucinate, and simpler to maintain. Every task you correctly route to a model is one where that model's cost buys something real. Teams that ask this question ship features that are both reliable and modern; teams that skip it ship a model where a regex belonged and spend the next year apologizing for it. Before you choose which model, choose whether you need one.