Stop Hiring a Rocket Scientist to Check If a Box Is Empty

One thing I've been thinking about lately is what companies are willing to sacrifice just to have in their title "AI-powered" Let's take one very simple problem that's been solved for decades.

A tale as old as 2023

A team needs to validate an email address. Someone asks, "What if we used AI?" Five minutes later there's a model call, an API key, a loading spinner, a monthly bill and somehow Kubernetes got involved. Congratulations, you've successfully turned O(1) into "please wait while we contact the cloud."

I want to be clear: this isn't a "AI bad" post. AI is genuinely excellent at some kind of problems. The problem isn't the tool. It's reaching for it on tasks that never needed it in the first place, because it's new and shiny and everyone is doing it.

The actual difference, side by side

Here's the unglamorous truth: an if statement and an LLM call are not doing the same job. They're built for genuinely different kinds of problems, and the gap between them is bigger than people give it credit for.

An if statement runs in a fraction of a millisecond, costs nothing per call, and gives you the exact same answer every single time for the same input (deterministic). An LLM call, by comparison, takes real time, costs real money, and can give you a slightly different answer to the exact same question depending on the day, the model version, or the wind direction.

A rough field guide: if-statement or AI?

Reach for an if statement (or a regex, or .. or ..) when:

• The rule is genuinely simple and doesn't change on context. "Is this a valid email format?" "Is the cart total over $50?" "Is the field empty?"


• You need the same input to always produce the same output. Billing logic, permission checks, form validation. No your users don't want their invoice total to vary by mood.


• Speed actually matters and there's no ambiguity to resolve. A password strength check doesn't need to "think" about it.

Reach for AI when:

• The task genuinely requires judgement. Summarise an article, classifying open-ended free text into fuzzy categories.


• The input space is too vast or unpredictable. You can't write an if statement for "understand what this customer is actually frustrated about" from a paragraph of free text.


• Some variability in output is fine, or even desirable. A creative writing assistant that gives the exact same suggestion every time isn't actually that useful.

More examples than you asked for, because this pattern is everywhere

Password strength meter. "At least 8 characters, one number, one symbol" is a rule. Come on. We've been solving this since MySpace was a thing. No model needed, no matter how tempting "AI-powered password feedback" sounds on a feature list.

Flagging a support ticket as urgent. If "urgent" just means "contains the word 'urgent' or 'down' or 'broken'," that's a keyword check. If "urgent" means genuinely understanding tone, context, and severity from a rambling paragraph a frustrated customer wrote at 2am, that's no longer a keyword problem. That's a language understanding problem.

Discount code validation. "Is this code in our database and not expired?" is a lookup, full stop. Please don't ask a model to check a database for you; that's what the database is for.

Sorting a list by price. Please don't spend $0.002 to rediscover ascending order.

Summarizing 200 pages of meeting notes into three takeaways. Genuinely hard to write a rule for. This is a real, appropriate use of a model's judgement.

Writing a product description from a spec sheet. Turning structured facts into natural, readable list is a language task. This is AI doing what it's actually good at.

The real cost of getting this wrong

This isn't just a complaint about over-engineering. Reaching for AI on an if-statement problem has real costs:

1. Latency you didn't need to add. A synchronous, instant check just became a network round trip with a real wait time, on something that used to be free.


2. Money you didn't need to spend. Every one of those calls costs something, and at scale, "just use AI for validation" turns into a big cost in something that used to cost literally nothing. We've somehow managed to invent a subscription for if.


3. Unpredictability you didn't ask for. If your business logic can quietly behave differently for the exact same input, you've turned a deterministic system into a probabilistic one. Now you get to debug "why did this work yesterday and not today" for a rule that used to just... work.


4. A dependency you didn't need. Your feature now depends on a third-party API being up, fast, and within budget, for something that used to depend on nothing but your own server running.

Reflect on our choices

Before reaching for AI, ask: could I write this rule down in a sentence, and would that sentence still be true tomorrow? If yes, you probably want an if statement, not a model call. If the honest answer is "well, it depends, there's a lot of nuance, it's hard to actually pin down," that's usually the signal that you've found a problem AI is actually good at.

AI earning its place in a product should feel like reaching for a tool that's uniquely suited to a genuinely hard problem, not like a reflex applied to everything because it's the exciting new thing to reach for.

Sometimes the most sophisticated piece of technology in the room is the engineer who knew not to call the model.

Resources

• Google's guidance on when to use ML — from Google's own People + AI Guidebook, on evaluating whether a problem genuinely needs machine learning: pair.withgoogle.com/guidebook


• Martin Fowler on YAGNI ("You Aren't Gonna Need It") — not AI-specific, but the classic engineering principle behind not reaching for more power than a problem actually needs: martinfowler.com/bliki/Yagni.html


• Anthropic's guide to when (and when not) to use agents/LLMs — practical framing for deciding where a model call is actually justified: docs.claude.com