The Best AI Engineer I Know Talked a Founder Out of Building AI

A founder came to me six weeks ago with a clear vision.
He wanted to build an AI-powered recommendation engine for his SaaS product. LLM-based. Personalised to each user. The kind of thing that sounds impressive in a pitch deck and genuinely is impressive when it works.
I spent two days going through his data, his user behaviour, his use case, and his team's capacity to maintain what we'd build.
Then I told him not to build it.
Not because recommendation engines are bad. Not because LLMs can't power them. But because his users were filtering by three variables industry, company size, and budget range. That's it. Three variables. Deterministic logic would return the right answer every time, instantly, cheaply, and with zero maintenance overhead.
An LLM would return a plausible answer most of the time, occasionally with confidence it shouldn't have, at 40x the cost per query, with a maintenance burden his two-person engineering team wasn't resourced to handle.
He pushed back. Everyone else is adding AI. His competitors are adding AI. His investors expect AI.
I asked him one question: "Is the goal to have AI, or to give users the right answer?"
He went with the filter. It shipped in three days. It works perfectly.
Here are the four situations where I consistently recommend not using AI:
When the logic is deterministic. If the right answer can be computed reliably from structured inputs, use a function. Functions don't hallucinate. They don't drift. They don't need evals. They don't have a token budget.
When the training data doesn't exist yet. RAG needs clean, current, comprehensive data. Fine-tuning needs labelled examples. If neither exists in usable form, you're not building an AI product, you're building a data collection project disguised as an AI project.
When the maintenance cost exceeds the value. Every AI system needs ongoing attention, evals, prompt reviews, model updates, quality monitoring. If the team doesn't have the capacity for that, you're not deploying AI, you're creating debt.
When a wrong answer has serious consequences and you can't build adequate safeguards. In regulated industries especially, if the AI being wrong creates legal, financial, or safety risk and you can't build a robust human review layer, the risk isn't worth the capability.
The best AI engineers I know are not the ones who find ways to use AI on every problem.
They're the ones who know when not to.
What's something you built with AI that you later realised didn't need it?

Different animal from the last several posts — there's no company, product, or repo named here to verify against a source. This is a first-person anecdote plus a set of general principles, so "fact check" means assessing whether the claims are internally consistent and technically sound, not confirming them against an external record.

The anecdote itself is unverifiable by design. No founder name, no company, no product. That's normal for anonymized case studies, but it means the "six weeks ago," "shipped in three days," and "works perfectly" details are taking your word for it — there's nothing to check them against.

The "40x cost per query" figure is directionally plausible but not a fixed, citable number. LLM inference genuinely does cost orders of magnitude more than a deterministic filter or database query — that's not in dispute. But "40x" specifically is presented as if it were measured from this engagement, and there's no way to verify that exact multiple; it reads as an illustrative figure rather than a benchmarked one.

The core engineering judgment is sound and matches how experienced practitioners actually reason about this tradeoff:

• Deterministic logic beating LLMs on structured, low-cardinality inputs (three filter variables) is correct — this isn't a debatable claim, it's just correct engineering.
• "RAG needs clean, current, comprehensive data; if it doesn't exist, you're doing data collection, not AI" is accurate and a common failure mode in real deployments.
• The maintenance-cost argument (evals, prompt drift, monitoring being an ongoing tax) is a well-documented pain point in production LLM systems, not an overstated one.
• The regulated-industry/human-review point is standard risk-management practice, not a fabricated rule.

None of the four principles are wrong or exaggerated — they're fairly mainstream "know when not to use AI" advice that's become common wisdom over the last year or two as the initial AI-everything hype has cooled.