The impressive but unreliable new hire
Large Language Models, or LLMs — the AI systems behind tools like ChatGPT — have become the default choice for almost any job involving unstructured text: summarizing meetings, writing code, answering support tickets, filling out forms. They're genuinely good at this. But that competence hides a trade-off that many teams don't notice until something breaks in production.
An LLM is a probabilistic system. That means, at its core, it doesn't calculate an answer the way a calculator does — it makes a highly educated guess, based on patterns learned from enormous amounts of text, about what the most likely correct answer looks like. This makes it flexible and often startlingly capable. It also means it is never 100% reliable. For many tasks, "right almost all the time" is a huge improvement over what came before. For others, it's a serious liability.
You can't fix this with a better model or a smarter prompt. It's not a flaw in any particular AI system — it's how the technology fundamentally works. The practical result is a new kind of bug: a failure that only shows up 1 time in 100, or 1 time in 1,000, so it sails through testing and then shows up unpredictably once real users are relying on it. Before you build a feature around an LLM, it's worth asking whether a plainer tool — a database lookup, a bit of ordinary code, a simple form — would actually do the job better. Knowing when to say "no" to the AI is one of the most important skills in software design right now.
The siren song of the universal tool
It's easy to see why LLMs became the first tool engineers reach for. The last few years have seen an explosion in agentic frameworks that promise to automate entire job functions. Platforms like AutoGPT let you describe a high-level goal, and the agent will figure out the steps to achieve it. As Andrej Karpathy, a founding member of OpenAI, noted, these autonomous systems felt like the "next frontier." They can browse the web, operate applications, and complete multi-step tasks, blurring the line between software and a human assistant.
This vision of a universal problem-solver is incredibly compelling. Tools like browser-use make websites accessible to AI agents, allowing them to perform tasks a human would, like booking flights or filling out forms. The promise, as Replit CEO Amjad Masad said of AutoGPT, is that "You don't even need to learn how to code." You just state your intent.
When you have a hammer that can seemingly hit any nail, every problem starts to look like one. Need to extract a date from an invoice? LLM. Need to categorize a support ticket? LLM. Need to check if a user's input is "yes" or "no"? LLM. This approach delivers impressive demos but often creates brittle, expensive, and dangerously unpredictable systems in production. The key is to recognize the categories of problems where an LLM is not just overkill, but the wrong tool entirely.
Five signs you're using the wrong tool
The decision to use an LLM should be a deliberate one, made after ruling out simpler, more robust alternatives. Here is a five-point framework for identifying tasks where an LLM is a liability, not an asset.
1. The task is deterministic
A deterministic task is one where the same input must always produce the same output. There is one, and only one, correct answer.
Consider formatting a date. A user gives you 2026-05-14, and you need to display it as "May 14, 2026". An LLM can do this flawlessly thousands of times. But on the thousand-and-first try, it might output "14 May 2026" or "May 14th, 2026". This isn't a bug in the model; it's a feature of its statistical nature. It has learned dozens of valid ways to represent that date and picks the most probable one.
For a deterministic task, this is unacceptable. The correct tool here is decades old: a date-formatting library that uses a format string like %B %d, %Y. It is mathematically incapable of getting it wrong.
The Test: Is there only one correct output for a given input? Can the logic be expressed as a set of unambiguous rules? If yes, do not use an LLM. Use a function, a library, or a template.
2. The decision requires a perfect audit trail
In regulated industries like finance, healthcare, or law, you don't just need the right answer; you need to prove how you got it. If a system denies a loan application, a regulator will want to see the exact logic that led to that decision.
An LLM cannot provide this. Its "reasoning" is a path through billions of parameters in a neural network, a process that is fundamentally opaque. While projects like Google's LangExtract work to ground an LLM's output in specific source text, providing citations for its claims, this is not the same as a logical audit trail. It shows you what information it used, but not the repeatable, step-by-step logic of how it made its decision.
A simple SQL query, by contrast, is a perfect, auditable record of the logic used to pull a set of records. A decision tree from a classical machine learning model is similarly transparent; you can trace the exact path from input features to final classification.
The Test: If this system makes a mistake, would you need to explain its internal logic to a regulator, a customer, or a court? If yes, do not use an LLM. Use a database query, a rule engine, or an interpretable classical model.
3. Latency must be low and predictable
LLMs are slow. Even with dedicated hardware, a complex query to a large model can take several seconds. This latency is also highly variable, depending on the model's load and the complexity of your request.
This makes LLMs unsuitable for any real-time or interactive application. If you are building an autocomplete feature, a user expects a response in milliseconds, not seconds. If you are processing transactions in a high-frequency trading system, a two-second delay is an eternity.
Many tasks currently being handed to LLMs can be done almost instantly with other methods. For example, routing an incoming support ticket based on keywords can be handled by a few if/else statements or a regular expression in microseconds. A Naive Bayes classifier, a staple of classical machine learning, can be trained to do the same thing with latency measured in single-digit milliseconds. Even running models locally with a framework like GPT4All, which removes network latency, still requires significant computation on a local CPU. It's faster than an API call, but still orders of magnitude slower than a simple algorithm.
The Test: Does this task need to complete in under a second? Is it part of a user-facing loop where responsiveness is critical? If yes, do not use an LLM. Use a purpose-built algorithm, a regex, or a fast classical ML model.
4. The output is a choice from a small, fixed set
A common use case for LLMs is classification. For example, determining the sentiment of a customer review: is it "Positive," "Negative," or "Neutral"? Or assigning an incoming email to one of five departments: "Sales," "Support," "Billing," "Engineering," or "HR."
While a powerful LLM can do this, it is massive overkill. You are using a tool that can write a sonnet to solve a multiple-choice question. The space of possible correct answers is tiny and known in advance.
This is a classic machine learning task. A far better solution is to use a smaller, more specialized model like a fine-tuned BERT-style classifier or even simpler methods. These models are smaller, faster, and cheaper to run. More importantly, because their scope is limited to the predefined labels, they are less likely to produce unexpected or nonsensical outputs. An LLM, asked to classify a review, might decide the sentiment is "Slightly Disappointed with a hint of Optimism," which, while perhaps more nuanced, is not one of your valid categories and will break your downstream code.
The Test: Is the desired output one of a small, predefined set of labels (e.g., fewer than 100)? If yes, do not use a general-purpose LLM. Use a dedicated classification model.
5. The cost of being wrong is too high
For some tasks, an error rate of 1% is a minor annoyance. For others, it's a catastrophe. LLMs are probabilistic and will always have a non-zero error rate. You can reduce it, but you can never eliminate it.
If a system is summarizing articles for internal research, an occasional error is acceptable. If it's generating a medical diagnosis, calculating a dosage, executing a financial trade, or controlling a physical system, any error is unacceptable. The "human-in-the-loop" pattern is often proposed as a solution, but this breaks down when the volume of decisions is too high for a person to review every single one.
When correctness is an absolute requirement, you need a system that is provably correct. This means relying on tools that are deterministic and transparent. The logic must be simple enough to be formally verified or exhaustively tested. This is the domain of traditional software, not generative AI.
The Test: What is the business or human impact of this system making a mistake 2% of the time? 1%? 0.1%? If the answer is anything more than "a minor inconvenience," do not use an LLM as the final decision-maker.
A worked example: Extracting lab results
Let's make this concrete. Imagine your task is to extract a patient's white blood cell (WBC) count from a text-based lab report. The report format is consistent.
PATIENT ID: 12345
REPORT DATE: 2026-05-14
...
WBC Count: 8.4 x 10^9/L (Normal: 4.5-11.0)
...
The LLM approach
You could write a prompt:
"From the following lab report, extract the WBC Count value as a float. The report is: {report_text}"
This will work most of the time. But it has several failure modes:
Hallucination: The model might invent a value if the line is missing or malformed.
Misinterpretation: It might return
9.0(the midpoint of the normal range) instead of the actual value8.4.Formatting Errors: It might return the string
"8.4 x 10^9/L"instead of the float8.4.Cost and Latency: Each extraction requires a round-trip to an API, incurring cost and a multi-second delay. Even with optimization tools like Caveman, which can reduce input token counts by over 33% on certain benchmarks, the fundamental per-call cost remains.
The classical approach
The lab report has a fixed structure. The line always starts with "WBC Count:". The number is always a float. This is a perfect job for a regular expression.
import re
report_text = """
PATIENT ID: 12345
...
WBC Count: 8.4 x 10^9/L (Normal: 4.5-11.0)
...
"""
match = re.search(r"WBC Count:\s*(\d+\.\d+)", report_text)
if match:
wbc_count = float(match.group(1))
print(wbc_count) # Output: 8.4This code is less glamorous. It's harder to write and more brittle if the report format changes unexpectedly. But for a known format, it is:
Deterministic: It will work correctly every single time.
Auditable: The logic is explicit in the code.
Fast: It executes in microseconds.
Free: It has zero marginal cost per execution.
The hybrid approach: The best of both worlds
A robust system often uses both. It starts with the most reliable, cheapest tool and escalates to more powerful, expensive tools only when necessary.
Try Rules First: Attempt to extract the data using one or more regular expressions designed for known report formats.
Check for Success: If a regex finds a plausible value, use it. The process is complete.
Escalate to LLM: If, and only if, all rules fail, send the text to an LLM as a fallback.
Log and Alert: Log the failure of the rules-based system. This alerts your team that a new or unexpected format has appeared, which can be used to improve the rules for next time.
This hybrid pattern gives you the speed and reliability of classical methods for the 99% case, with the flexibility of an LLM as a safety net for the 1% you haven't seen before.
Your decision test
Before you assign a task to an LLM, run it through this checklist.
Is there only one right answer?
Yes: Don't use an LLM. Use code.
Do you need to prove how the decision was made?
Yes: Don't use an LLM. Use a rule engine or interpretable model.
Does it need to be faster than a human typing?
Yes: Don't use an LLM. Use a compiled algorithm or classical ML.
Is the output a choice from a short, fixed list?
Yes: Don't use an LLM. Use a dedicated classifier.
Is a 1-in-1000 error rate unacceptable?
Yes: Don't use an LLM. Use a deterministic system.
If you answered "No" to all five, you likely have a genuine fit for a Large Language Model — a task that's fuzzy, creative, or depends on understanding language in all its messiness, which is exactly what these models are built for. If you answered "Yes" to even one, reaching for an LLM anyway won't just be inefficient; it will plant a bug in your system that passes every demo and every test run, and then fails in front of a real user at a moment you didn't choose. The fix isn't a better prompt or a bigger model — it's picking the plainer tool: the regex, the lookup table, the rule engine, the classifier trained for exactly one job. None of that is glamorous. It's also the difference between a system you can trust and one that merely looks impressive until it doesn't.