When Not to Use AI: Recognizing the Wrong Use Case Early
A client came to us wanting an LLM to classify incoming support tickets into twelve fixed categories. It sounded like a natural fit — free text in, category out. But the category set was small, stable, and the language patterns were consistent enough that a lightweight embedding classifier trained on two thousand labeled tickets hit 97% accuracy, ran in under 20 milliseconds, and cost nothing per request beyond the initial training run.
We built that instead of wiring up GPT-4 for every ticket. The tell was that the output space was bounded and enumerable — twelve categories, not open-ended text generation. When the correct answer set is small and known in advance, a classifier or even a well-tuned set of rules will usually beat an LLM on cost, latency, and consistency, and it won't hallucinate a thirteenth category that doesn't exist in the downstream system.
The second recurring pattern is when determinism is a compliance requirement, not a preference. For a healthcare intake client, the same input had to produce the same output every time for audit purposes. LLMs, even at temperature zero, don't give you that guarantee across model versions and provider-side updates. We used AI for the parts of the flow that genuinely needed language understanding — summarizing free-text notes — and kept the eligibility logic in deterministic code that could be unit tested and audited line by line.
The questions we now ask before reaching for an LLM: is the output space bounded? Does the answer need to be reproducible? Is the latency budget under a few hundred milliseconds? Would a human reviewing ten failure cases say 'a rule would have caught this'? If the answer to any of these is yes, we prototype the non-AI approach first and only bring in a model if it clearly outperforms it on a real evaluation set, not a demo.
None of this is an argument against AI — we use it heavily elsewhere on the same projects. It's an argument for treating 'should we use an LLM here' as an engineering decision with a cost-benefit analysis, not a default. The projects that go sideways are usually the ones where AI got bolted onto a problem that a database query or a regex would have solved more reliably and for a fraction of the cost.
