Interactive lab · Practical AI
AI or Plain Logic? When Not to Use AI
Sometimes AI is the answer. Often, a single line of plain code does the job better, cheaper, with zero surprises.
Plain-language AI
In plain logic
No real AI runs on this page. Everything is explained and illustrated in your browser — no model calls, no accounts, nothing sent anywhere.
Adding an LLM introduces uncertainty, cost, and extra failure modes: it can be wrong in fluent prose, it costs money per call, it is slower than code, and its output must be validated. Plain code — a comparison, a filter, a lookup — is deterministic, instant, and free to run. The question is never “can AI do this?” but “does this job need judgment about ambiguous language?”
Reach for plain code when…
- The right answer follows a clear, testable rule (“flag invoices over $500”)
- The job is arithmetic, sorting, filtering, or routing
- A wrong answer would be expensive and the rule is known
- You need the same input to always give the same output
Reach for AI when…
- The input is ambiguous human language (“summarize these varied customer messages”)
- The task needs drafting, rephrasing, or open-ended classification
- You can tolerate and validate imperfect output
- Writing explicit rules would take longer than checking AI's work
The hybrid pattern
The strongest systems use both: AI suggests, rules decide. An LLM reads a customer message and suggests a category; plain code routes it, enforces permissions, and controls what actions actually happen. The AI handles the ambiguity it is good at; the code handles the consequences it is good at. That division of labor is the whole game.
Hands-on
Try this
Two jobs, side by side. Job one: route every invoice over $500 to a manager for approval. That is one comparison — if amount > 500 — and an LLM would only add latency, cost, and a small chance of misreading the number.
Job two: summarize fifty varied customer messages into themes. No comparison can do that; the input is messy human language. Here the LLM earns its place — and then plain code takes over again: it caps the summary length, strips formatting, and logs the result. AI for the ambiguity, rules for the guardrails.
Before your next “let's add AI” decision, ask the blunt question: does a simpler solution already meet the requirement? If yes, ship the simple thing.
Honest boundaries
What this leaves out
This guide is a decision framework, not a proof — and it deliberately understates one thing: even “AI-appropriate” tasks need validation. A summary can omit the one complaint that mattered; a classification can be confidently wrong. “The AI handles language” does not mean “the AI handles it correctly.”
Also: never let a plausible sentence substitute for a verified payment amount, permission check, or safety decision. If the output moves money, grants access, or affects safety, a deterministic check must stand between the model's words and the action. That rule has no exceptions.
Honest answers
Questions people ask
Isn't AI always better if it can do the task?
No — “can” is not “should.” If plain code does the job deterministically, AI adds cost per call, latency, and a non-zero chance of a fluent wrong answer, in exchange for nothing. Better is measured in reliability and cost, not impressiveness.
What about using AI to write the plain code?
That is the sweet spot: use the LLM at build time to write and explain the rule, then run the deterministic rule at runtime. You get AI's flexibility during development and code's reliability in production.
When does the hybrid pattern break down?
When the boundary is fuzzy — if you cannot cleanly separate “AI suggests” from “rules decide,” the AI's uncertainty leaks into the consequences. Draw the line explicitly: list exactly which actions require deterministic checks, and enforce it in code.