Every project that lands on our desk now comes with the same reflex baked in: and we should use AI for it.Sometimes that's right. More often, it's the most expensive way to solve a problem that didn't need it.
We're not AI skeptics — we build with it every day. But we've watched enough teams bolt a language model onto a workflow that a forloop would have handled, then spend the next quarter babysitting the thing: tuning prompts, eating token bills, explaining to a customer why the output was confidently wrong. The technology wasn't the problem. The judgment about where to point it was.
So here's how we actually decide.
Most “AI problems” are just problems. So before we reach for a model, we go back to first principles — ignore what everyone else is reaching for, and ask a deflating question: what would this look like with no AI at all? A surprising amount of the time, the honest answer is a lookup table, a SQL query, a regex, a state machine — something deterministic, fast, effectively free to run, and correct every single time. If you can write the rule down, write the rule down. A forloop doesn't hallucinate. It doesn't cost a fraction of a cent per call. It doesn't change its mind on Tuesday. Determinism isn't a limitation you settle for; it's a feature you should want.
The bill comes due in three currencies. When AI isin the path, it's never free — even on a free tier. You pay in tokens, you pay in latency, and you pay in trust, because a non-deterministic system can't be fully trusted without something deterministic checking its work. That third cost is the one teams underprice. A demo that works 90% of the time feels like magic. A production system that works 90% of the time is a liability with a failure rate you can't predict.
So where does AI earn its place?At the edges a rule can't reach. Unstructured language. Fuzzy matching where the variations are endless and the patterns won't sit still. Judgment-shaped work that genuinely needs to generalize from messy input — pulling structure out of a thousand differently-formatted documents, drafting a first pass a human will refine, deciding which of ten thousand records actually warrant a look. When AI clears that bar, it doesn't just help — it unlocks things that couldn't be built before.
The test we use is plain: does AI measurably outperform the deterministic alternative, on an ROI basis, for this specific job? Not “could it” — does it, here, by enough to justify the cost. If yes, it's in. If it's a wash, the boring option wins, because the boring option is cheaper and more reliable.
And even then — validate. The only way to trustan AI output is to check it against deterministic logic anyway. Once you accept that, the architecture inverts. You don't build an AI system with some guardrails; you build a deterministic system that reaches for AI selectively, at the points where it earns its keep, and validates what comes back. AI as a sharp tool inside a sturdy structure — never the structure itself.
This is just value engineering.None of this is anti-AI. It's the same question we ask about every part of a build, reasoned from first principles rather than fashion: where is the value, and what's the cheapest, most reliable way to capture it? Sometimes that's a model doing something genuinely new. Sometimes it's twelve lines of code you'll never think about again. The goal was never to “use AI.” The goal is software that does the job, holds up under real use, and doesn't cost more to run than the problem cost in the first place.
Knowing the difference — and being honest about it when the easy answer is to just say yes to the model — is most of the job.