When not to reach for an AI agent

Figuring out when not to use AI has saved me more grief than almost any prompt trick. Right now the reflex on a lot of teams is to point a model at any problem that involves text or decisions, then act surprised when the result is slower, pricier, and less reliable than the boring thing it replaced. An agent is a tool with a specific shape. It is brilliant for some jobs and actively wrong for others, and a senior engineer earns their keep partly by knowing the difference before the company finds out the hard way.

When the answer is deterministic, do not guess at it

If a task has one correct answer that you can compute, compute it. Parsing a structured file, doing arithmetic, validating a format against a known schema, transforming data with clear rules: these have exact solutions, and a model only introduces a chance of being subtly wrong where a normal function would be right every time. I have watched people wrap a regular expression's worth of work in a language model call and then wonder why it occasionally produces nonsense at scale. The nonsense is the model doing exactly what it does, which is approximate.

The tell is simple. If you could write the rules down and a junior could implement them in an afternoon, write the rules. Save the model for the genuinely fuzzy parts where rules run out.

When errors are expensive and you cannot check them

Models are probabilistic, which means they are wrong some percentage of the time, and that percentage is rarely zero. So the real question for any task is what happens when it is wrong. If a mistake is cheap to catch and cheap to fix, fine. If a mistake moves money, deletes data, sends something irreversible, or makes a legal or medical claim, the bar is much higher, and you need either a deterministic path or a human firmly in the loop.

What makes this dangerous is that models fail confidently. They do not flag their own uncertainty in a way you can trust. So 'we will catch the bad ones' only works if you actually have a reliable way to catch them, and very often the reason you wanted the model in the first place is that you did not. That circular trap is where a lot of AI projects quietly go wrong.

When latency or cost will not survive contact with reality

An agent that takes several seconds and a model call to do something a lookup table does in a millisecond is a bad trade in any hot path. I think about this constantly for anything user-facing. People forgive a lot, but they do not forgive an interface that got slower and more expensive to run so it could be powered by something fashionable.

A rough filter I apply before reaching for a model:

• Is there a clear, correct, computable answer? If yes, skip the model.
• Is a wrong answer cheap to detect and undo? If no, be very careful.
• Does the path have a tight latency or cost budget? If yes, a model call may not fit.
• Would a lookup, a rule, or a small classifier do the job? If yes, use that first.

When a simpler tool already exists

A surprising amount of work that gets handed to agents is solved better by tools that have existed for decades. Full-text search, a recommendation rule, a state machine, a well-tuned database query. These are fast, debuggable, and predictable. A model is none of those by default. I am not against using AI here, I use it daily, but I have stopped treating it as the first answer. It is the answer for problems that genuinely resist structure, and reaching for it on problems that have plenty of structure is just expensive overengineering with extra failure modes.

Where it does earn its place

To be clear, I reach for models often, and they are genuinely good at certain things. Open-ended language work, summarizing messy text, drafting, classifying inputs that resist hard rules, and acting as a flexible glue layer between systems that were never designed to talk. The common thread is that the task is inherently fuzzy and a roughly-right answer is useful. When the task is fuzzy and approximation helps, an agent shines. When the task is exact and approximation hurts, it is the wrong tool no matter how impressive the demo looked.

The skill here is not anti-AI and it is not pro-AI. It is matching the tool to the shape of the problem, and being willing to say no to the trendy option when a plain function would be faster, cheaper, and correct every time. The best engineers I know reach for models constantly and also know exactly when to put them down.