When Not to Use AI: Choosing the Boring Solution That Wins
We build AI into products for a living. Which is exactly why we'll tell you, often, to not use it.
That sounds like a strange thing for an AI studio to say. But our job isn't to sell you a model. It's to solve your problem well, and a surprising amount of the time the best tool for the job is a regular expression, a lookup table, or a database index that's been around since before any of us were born. The hard part isn't knowing how to add AI. It's knowing when adding it makes the product worse.
The hype tax
Every time you put an LLM in a path where it doesn't belong, you pay a tax. It's not one cost, it's four, and they all compound.
Latency. A deterministic function returns in microseconds. A database query, single-digit milliseconds. A model call is seconds, sometimes many. If you've ever wired up a "smart" feature and watched a spinner sit there for four seconds doing what an if statement could do instantly, you've felt this. Users notice. They always notice.
Cost forever. A rule you write once runs essentially for free for the rest of its life. A model call costs money on every single request, and it keeps costing as you scale. At a thousand requests a day, who cares. At ten million, you've signed up for a recurring bill to do something arithmetic could have done for nothing.
Non-determinism. The same input can give you a different output tomorrow, or after a model update you didn't ask for. That's wonderful for brainstorming and miserable for anything you need to test, audit, or explain to a regulator. "Why did the system do that?" is a question you should be able to answer.
New attack surface. LLMs hallucinate. They get prompt-injected. Feed user text into a model that can take actions and you've opened a door that didn't exist before. We've watched a chatbot get talked into ignoring its own instructions by a single cleverly worded support ticket. A validation function has never once been social-engineered.
None of this means AI is bad. It means AI isn't free, even when the API pricing looks cheap. The pricing is the smallest part of the bill.
A simple test before you reach for a model
Before we add a model to anything, we ask three questions. They take about five minutes and save weeks.
Is the rule actually fuzzy?
This is the big one. AI earns its keep on problems that resist being written down. "Is this email a valid format" is not fuzzy, it's a spec. "Is this support message angry" is genuinely fuzzy, you couldn't write the rules if you tried. If you can describe the logic in a paragraph of plain conditions, you don't have an AI problem. You have an afternoon of coding.
Can you tolerate being occasionally wrong?
Models are wrong sometimes. That's fine for suggesting tags, drafting a reply, ranking results. It's not fine for moving money, enforcing permissions, or computing someone's tax. If a single wrong answer is unacceptable, a probabilistic system is the wrong foundation, no matter how good the accuracy number looks. 99% is a great demo and a terrible payroll engine.
What do cost and latency look like at scale?
Run the multiplication early. Per-request cost times projected volume. Per-call latency inside your actual user flow. We've killed features in a planning meeting because the math said each call would cost more than the action was worth, and no amount of clever prompting changes that. Do the arithmetic before you fall in love with the demo.
Where the boring solution wins
Here's where we reach for deterministic code, every time, and don't apologize for it.
The pattern across all of these: the answer is knowable and exact. When there's a correct answer you can compute, computing it beats guessing at it. Even a very educated guess.
Where AI genuinely earns its place
We're not contrarians for sport. There's a real set of problems where AI is the right call, and for those we'll happily build it.
Notice these all share the traits from our test: the problem is genuinely fuzzy, an occasional miss is survivable (or a human catches it), and the value clears the cost.
How we actually decide
In practice it's less of a framework and more of a reflex, sharpened by having shipped both kinds of system and maintained them afterward.
We start by assuming the answer is no. Then we try to talk ourselves into AI and see if it survives the three questions. If a junior engineer could write the rule in a day, we have them write the rule. If the problem only gets interesting because the input is messy and human, that's our signal the model belongs there.
The other thing we do is keep them separate. Deterministic code does the parts that must be correct: the math, the permissions, the validation. The model does the fuzzy part, and its output gets handed back to plain code that checks, constrains, and contains it. The LLM proposes. Your own code disposes. That boundary is most of what makes an AI feature you can sleep at night having shipped.
And we measure. Once a model's in production we watch what it costs and what it gets wrong, because both drift. Plenty of features that justified a model on day one quietly became a rule we could have written all along, once we understood the actual data.
The goal was never to use AI. We sometimes have to remind ourselves of that, too. The goal was to solve the problem well. AI is one tool in the box, a genuinely remarkable one for a specific shape of problem, and a liability everywhere else. Knowing the difference is the whole job. Anyone can bolt a model onto a feature. Knowing when not to is what you're actually paying a senior team for.