AI for everything is a cannon to kill a mosquito: when to use it, when not to, and when to combine

Last week I saw a LinkedIn post that made me stop scrolling.

A developer was proudly showcasing his “intelligent AI-powered email validator.” The system sent the user-typed email to an LLM, which responded whether the format was valid or not. The post had 200+ likes and comments like “genius!” and “the future is now.”

I stared at my screen. A one-line regular expression does exactly that. In 0.001 seconds. For zero cents. With 100% determinism.

That was a cannon to kill a mosquito.

And this is the problem I see repeating itself every day in the industry: we’re so excited about what AI can do that we forget to ask whether it should. Not because AI is bad. It’s extraordinary for the right problems. But because there’s a fundamental difference between problems that need AI and problems that already have better, faster, and cheaper solutions.

The most valuable skill an engineer can have in the AI era isn’t knowing how to use ChatGPT. It’s knowing when not to use it. And knowing when to combine both approaches into a hybrid solution that gets the best of both worlds.

In this post, I’ll give you a practical framework so you never get this decision wrong again. We’ll talk about determinism, costs, real examples, and a decision matrix you can apply tomorrow at work.

Deterministic vs non-deterministic: the concept that changes everything

If you understand this single concept, you’ll already make better decisions than 90% of engineers working with AI today. No exaggeration.

What deterministic means

A deterministic system is one where the same input always produces the same output. No exceptions. No “it depends.” No “almost always.”

Examples you already know:

• 2 + 2 always equals 4
• An email validation regex always returns true or false for the same string
• A CPF check-digit algorithm always validates or rejects the same number
• sort([3, 1, 2]) always returns [1, 2, 3]
• A tax calculation with the same rates and base always gives the same result

These operations are predictable, testable (a unit test handles it), fast (microseconds), cheap (near-zero compute cost), and auditable (you can trace every step).

What non-deterministic means

A non-deterministic system is one where the same input can produce different outputs, and all of them may be equally valid.

LLMs are inherently non-deterministic. Even with temperature=0, there are subtle variations between calls (due to floating point, batching, and internal optimizations). In practice, if you ask an LLM to summarize the same text 10 times, you’ll get 10 different summaries. All may be correct. None is “the” summary.

Examples of genuinely non-deterministic tasks:

• Summarizing a 50-page document
• Translating text while preserving tone and cultural context
• Classifying customer intent from natural language (“I want to cancel” vs “how do I cancel” vs “cancel this garbage”)
• Generating marketing copy
• Answering open-ended questions about a codebase

These tasks require natural language understanding, contextual judgment, and the ability to handle ambiguity. There’s no deterministic formula that solves them.

The insight most people miss

The question most engineers ask is: “can AI solve this?”

The answer is almost always yes. LLMs are powerful generalists. They can validate an email. They can format a date. They can convert CSV to JSON.

But the right question is different: “does this problem require non-determinism?”

If the answer is no, if the same input should always produce the same output, you’re paying tokens for something a function does for free.

Characteristic	Deterministic	Non-deterministic (LLM)
Same input = same output	Always	Almost never
Cost per execution	Fractions of a cent	Cents to dollars
Latency	< 10ms	500ms to 30s
Testability	Unit test = done	Evals, benchmarks, uncertainty
Auditability	Complete trace	”Depends on the prompt”
Handles ambiguity	No	Yes
Handles novelty	No	Yes

The hype problem: AI in everything

Real examples of overkill

I collect these examples. Not out of malice, but because each one is a learning opportunity. See if you recognize any:

Validating email format with an LLM:

# What they do:
response = llm.chat("Is this a valid email? user@example.com")
# ~500 tokens, ~$0.0015, ~800ms

# What they should do:
import re
is_valid = bool(re.match(r'^[\w.-]+@[\w.-]+\.\w+$', email))
# 0 tokens, $0.00, <1ms

Formatting a date from ISO to dd/mm/yyyy:

# What they do:
response = llm.chat("Convert 2026-03-30 to dd/mm/yyyy format")
# ~200 tokens, ~$0.0006, ~600ms

# What they should do:
from datetime import datetime
formatted = datetime.strptime("2026-03-30", "%Y-%m-%d").strftime("%d/%m/%Y")
# 0 tokens, $0.00, <1ms

Classifying HTTP status as success or error:

# What they do:
response = llm.chat(f"Is HTTP status {status} a success or error?")

# What they should do:
is_error = status >= 400

Converting CSV to JSON:

# What they do:
response = llm.chat(f"Convert this CSV to JSON:\n{csv_data}")

# What they should do:
import pandas as pd
result = pd.read_csv("data.csv").to_json(orient="records")

Every single one of these examples has something in common: the problem is 100% deterministic. No ambiguity. No judgment. No acceptable variation in output. It’s input -> output, always the same.

Why this happens

Four main reasons:

Resume-driven development. “Uses AI” looks great on LinkedIn and your resume. The incentive is to use AI even when it doesn’t make sense.

Investor and management pressure. “We need an AI story.” Startups put AI in everything to justify valuations. Large companies create “AI initiatives” to show innovation.

Ignorance of alternatives. An entire generation of developers learned to code with AI. Many never needed to discover that dateutil parses dates, that Zod validates schemas, that fasttext detects languages. When your only tool is an LLM, every problem looks like a prompt.

The hammer-nail problem. When you’ve just learned to use a powerful tool, the temptation to use it for everything is enormous. LLMs are the most sophisticated hammer ever built, but not every problem is a nail.

The cost of overkill

I’ve already written in detail about the invisible cost of wasted tokens. But it’s worth reinforcing with a quick calculation.

Let’s say your application validates user emails via LLM. That’s 10,000 validations per day. Each call consumes ~500 input + output tokens. With Claude Sonnet at $3/million input tokens and $15/million output:

• Monthly cost with LLM: ~$450
• Monthly cost with regex: $0.00
• Latency with LLM: 500ms to 2s per validation
• Latency with regex: < 1ms per validation

That’s $5,400 per year thrown away. On a deterministic operation. That a regex handles better.

And the cost isn’t just financial. Every LLM call in production adds a non-deterministic dependency to your system. It means your tests become more fragile, your latency SLAs become harder to meet, and your system becomes more complex to debug.

Papers, tools, and solutions that already exist

Before opening ChatGPT to solve a problem, spend 10 minutes searching. The number of “AI problems” that already have deterministic solutions (ready-made, tested, and free) is staggering.

Problem	”AI solution”	Deterministic alternative
Language detection	LLM classification	langdetect, fasttext (99.4% accuracy)
Basic sentiment analysis	LLM prompt	VADER, TextBlob, lightweight HuggingFace models
Named Entity Recognition	LLM extraction	spaCy NER, Stanford NER
Code formatting	”AI code beautifier”	Prettier, Black, gofmt, rustfmt
Data validation	LLM verification	JSON Schema, Zod, Pydantic
Text similarity	LLM comparison	TF-IDF + cosine similarity, Levenshtein
Date parsing	LLM extraction	dateutil, chrono-node
URL extraction	LLM prompt	Regular expressions
Full-text search	”AI-powered semantic search”	PostgreSQL FTS, Elasticsearch, Meilisearch

The Toolformer paper (Schick et al., 2023) demonstrated something fascinating: the language model itself learns to delegate tasks to deterministic tools when those are more efficient. The LLM learns that computing 593 * 847 is better done by a calculator than by itself. If even the model recognizes this, why don’t we?

Use AI to build, not to run

This is the most important distinction in this post.

Using AI to help you find and implement the deterministic solution is excellent. Asking Claude “what’s the best regex to validate Brazilian phone numbers?” is a brilliant use of AI. It helps you write code faster, discovers libraries you didn’t know about, suggests better approaches.

But the production artifact, the code that runs in production serving thousands of requests, should be the regex, the function, the library. Not the API call.

Use AI as a development tool. Not as an execution tool for deterministic problems.

The hybrid approach: the best of both worlds

Not everything is black and white. Many real problems have a deterministic part and a part that requires judgment. That’s where the hybrid approach comes in, and that’s where real engineering lives.

When hybrid makes sense

The most common pattern is what I call the funnel: AI takes the chaos (unstructured input, natural language, ambiguity) and narrows it into structured categories. Then deterministic code takes those categories and executes with precision and speed.

AI turns the nebulous into concrete. Deterministic code executes the concrete with zero margin of error.

Real hybrid architectures

1. Customer support

The customer writes: “I’ve been trying to cancel this thing for two weeks and nobody’s helping.” That’s natural language, full of emotional context and ambiguity.

• AI: classifies intent (cancellation), detects sentiment (frustrated), identifies urgency (high)
• Deterministic: routes to the retention queue, applies SLA rules, triggers the cancellation workflow, logs in the CRM

AI does what only it can do (understand natural language). Code does what it does best (execute business rules without error).

2. Invoice processing

A PDF invoice is a semi-structured document. Fields in variable positions, inconsistent formats across vendors.

• AI: extracts fields from the PDF (OCR + LLM): tax ID, total amount, line items, dates
• Deterministic: validates the tax ID check digit, verifies tax calculations, checks date formats, inserts into the ERP

If you did everything with AI, you’d be paying tokens to verify a check digit, an arithmetic operation. With the hybrid approach, AI only does the extraction (the genuinely hard part), and deterministic code handles validation (the trivial but critical part).

3. Content moderation

• Deterministic first: blocklist of forbidden words, regex for known spam patterns, malicious link verification against database
• AI only for what’s left: text that passed deterministic filters but is ambiguous: sarcasm, cultural context, borderline content

Result: AI is called for only 20-30% of cases. The other 70-80% are resolved by deterministic rules in milliseconds. The token savings are massive.

4. Code review

• Deterministic: ESLint, Prettier, mypy, tsc for formatting, types, and code patterns
• AI: review of business logic, naming quality, architectural decisions, subtle bugs

It makes no sense to spend tokens having an LLM tell you that you forgot a semicolon. ESLint does that in milliseconds. But it makes total sense to use AI to ask “does this abstraction make sense here?”. That requires judgment.

The cost advantage of hybrid

Let’s take the invoice processing example. 10,000 invoices per month:

Approach	Cost/invoice	Monthly cost	Average latency
100% AI (extraction + validation + insertion)	$0.05	$500	8s
Hybrid (AI extracts, code validates/inserts)	$0.015	$150	3s
Savings	70%	$350/month	62%

The hybrid approach is cheaper, faster, and more reliable. The deterministic part (validation, calculations) never makes mistakes. AI is used only where it’s irreplaceable.

Decision framework: AI, no-AI, or hybrid

Now let’s get to the actionable part. A practical framework you can apply tomorrow, in any planning meeting, to choose the right approach.

The five questions

For any task, ask these five questions:

1. Does the same input always require the same output? If yes, strong signal for deterministic. If the output can vary and all variations are acceptable, strong signal for AI.

2. Does a proven open-source solution exist? If yes, use it. Don’t reinvent the wheel with tokens. Use AI to help you implement faster, but the final artifact is the library.

3. Does the task require natural language understanding or ambiguity handling? If yes, AI or hybrid. If not, almost certainly deterministic.

4. Will this run at scale in production (>1,000 calls/day)? If yes, cost and latency matter a lot. Favor deterministic for everything that can be deterministic.

5. Is a wrong answer dangerous or merely inconvenient? If dangerous (financial, medical, legal, security), the critical path should be deterministic. AI can assist, but the final decision needs to be auditable and reproducible.

The decision matrix

Question	If Yes	If No
Same input = same output?	+2 for deterministic	+2 for AI
Open-source solution exists?	+2 for deterministic	+1 for AI
Requires natural language?	+2 for AI	+1 for deterministic
Runs at scale?	+1 for deterministic	Neutral
Wrong answer is dangerous?	+1 for deterministic	Neutral

Interpretation:

• Deterministic score >= 4: go deterministic
• AI score >= 4: go AI
• Mixed scores: hybrid approach. Identify which parts are deterministic and which need AI

The flowchart in practice

When I’m evaluating a problem in my day-to-day work, my mental process is simpler:

1. Can a regex, algorithm, or library solve it? If yes: done, no AI needed. Next problem.
2. Does it need to understand human language or handle ambiguity? If not: probably deterministic. Find the right library.
3. Does it have both? Hybrid: AI for the fuzzy part, deterministic for the rest.
4. Is it purely creative or generative? Full AI.

This flowchart fits on a sticky note. Put it on your desk. Share it with your team. I guarantee it will save money and prevent over-engineering.

Day-to-day examples: each approach in action

To consolidate everything, here’s a quick-reference table with real examples organized by approach:

No-AI (deterministic)

Task	Solution
Input validation (email, tax IDs, phone, URL)	Regex, check-digit algorithms
Format conversion (CSV -> JSON, dates)	Native language libraries
Mathematical calculations (taxes, interest, currency)	Formulas implemented in code
Code formatting and linting	Prettier, ESLint, Black, gofmt
URL routing and HTTP status	Switch/case, lookup tables
Scheduled tasks and cron jobs	crontab, Celery, BullMQ
Exact-match or full-text search	PostgreSQL FTS, Elasticsearch

Full AI

Task	Why AI
Summarizing long documents	Requires comprehension and synthesis
Generating marketing copy	Requires creativity and tone
Translating with cultural context	Goes beyond word-for-word substitution
Answering open-ended questions about code	Requires reasoning over context
Brainstorming and ideation	Requires divergent thinking

Hybrid

Task	AI does	Deterministic does
Customer support	Classifies intent and sentiment	Routes, applies rules, executes workflows
Document processing	Extracts fields from PDFs	Validates data, calculates, inserts into system
Content moderation	Judges ambiguous cases	Filters by blocklist, regex, malicious links
Code review	Analyzes logic and architecture	Linting, types, formatting
Intelligent search	Semantic reranking	Full-text search, structured filters
Data enrichment	Normalizes messy inputs	Validates, deduplicates, stores

Conclusion: the best AI is the one you don’t need to call

Remember the AI email validator from the beginning of this post?

That developer isn’t incompetent. He’s probably good at what he does. The problem is that nobody taught him the right question: “does this problem require non-determinism?”

If the answer is yes, use AI. It’s the best tool humanity has ever created for handling ambiguity, natural language, and contextual judgment.

If the answer is no, use deterministic code. It’s faster, cheaper, more reliable, and easier to test.

If the answer is “partly”, combine both. Let each one do what it does best.

The irony is that this post follows exactly this philosophy. The research, structure, and writing had AI assistance, a creative, non-deterministic task. But the code examples, cost tables, and decision framework are deterministic: facts, numbers, and logic that don’t change between executions.

I’ve previously written about how fundamentals are the foundation of everything in the AI era. Knowing when to use and when not to use AI is a fundamental. Perhaps the most important one of all.

Because at the end of the day, the most senior skill an engineer can have today isn’t mastering prompts or fine-tuning. It’s looking at a problem and recognizing: “this doesn’t need AI. A regex will do.”

Save the cannon for problems that truly need it. For mosquitoes, a fly swatter works perfectly.