Most of your automation does not need an LLM

A founder hired me last year to build an AI agent that would categorize incoming leads by industry. I built a regex.

I charged for the full engagement, because the value I delivered was "your problem is solved reliably for close to zero tokens, in a way that will never hallucinate, and that you can debug in thirty seconds if it ever breaks." But the conversation to get the founder to accept that outcome was the hardest part of the entire project. The right answer to their "build me an AI agent" request was fifteen lines of Python that will outlive any model they could have paid for, and I want to talk about why that sentence was so hard to land.

The current default in 2026 is to reach for an LLM first. Every problem looks like it wants one. Founders post on Twitter about "using Claude to parse CSVs" as if the CSV parsing is the hard part. AI consultants I respect reach for an agent before they reach for a function. There is an entire category of "AI automations" being sold right now that are worse, slower, more expensive, and less reliable than the deterministic code they are replacing. The people building them do not notice, because they got to put "AI-powered" in the headline and the invoice.

Here it is: the LLM is the right answer when the input is natural language and the output requires judgment. That is the whole sentence. If the input is structured, or the output is deterministic, or both, you do not need a model. You need code. The code will be cheaper, faster, more reliable, more debuggable, and will not cost you money every time it runs.

Let me make this concrete. The rule sounds obvious in the abstract and gets violated constantly in practice.

Categorizing a lead by the domain of their email address? A lookup table. A text file with 2,000 lines mapping domains to industries, and twenty lines of Python. It will run in microseconds, cost nothing, and never get it wrong in a way you do not see coming.

Extracting an order number from an email? A regex. Order numbers have a format, and regex is the tool built specifically for extracting things with formats. The model will do it 97% of the time. The 3% will ruin your week and be impossible to explain to the client.

Deduping a contact list against a database? Normalize the fields, hash them, compare the hashes. This is a solved problem. It was solved in 1985. The model does not know more about it than the 1985 algorithm, and the 1985 algorithm is a million times faster and free.

Converting a structured form submission into a row in a spreadsheet? It is a map. A literal dictionary, one line of code. If your answer is "let's have the model do it so it is flexible," your answer is wrong. Flexibility in a pipeline is a liability, not a feature. You want pipelines to be rigid, so that when they break they break loudly, and rigidity is the exact property LLMs do not give you.

In fairness, here are the places the LLM is the right tool, and where I happily reach for it first.

Classifying the tone of a customer message. There is no regex for "is this customer annoyed." Use the model.

Summarizing a 20-email support thread into a two-sentence status update. Natural language in, natural language out, judgment required. Use the model.

Deciding whether two differently-worded bug reports are actually about the same underlying issue. Semantic equivalence on unstructured text, which was intractable before 2022 and is trivial now. Use the model.

Writing the first draft of an outbound email personalized to a specific person based on their LinkedIn. Generative, natural-language, judgment-heavy. Use the model, and then have a human or a rule-based checker review it before it goes out, because "first draft" is not the same as "final draft." That is the topic of another essay.

The pattern is consistent: the model goes where the structure gives out. It does not go where the structure is already there.

Two reasons, and they are worth naming because they are the reasons you are going to feel the pull even after reading this.

1. 1.Marketing. "AI-powered" sells. "Regex-powered" does not. If you are building a product, you feel real pressure to use the model for things it is not suited for, so you can tell your investors (and your landing page) that you are using the model. This is a real pressure and I am not dismissing it. The answer is to quietly use the right tool for each step and market the overall system as AI. As long as the hard parts actually are AI, that is honest.
2. 2.It feels like leverage. When you are a founder who has just learned how to use an LLM for the first time, everything looks like an LLM problem. The model seems to be able to do anything, and compared to writing code for each case, it feels like a shortcut. And for the first prototype, sometimes it is.

But the prototype is not the system. The system is the thing that runs ten thousand times a month. Ten thousand LLM calls is ten thousand opportunities to be non-deterministically wrong, ten thousand dollars of inference costs, and ten thousand rows in a trace log you are going to scroll through when something finally breaks. Ten thousand regex calls is zero opportunities, zero dollars, and one line of code you never have to think about again.

I mean that literally. On most calls, one of the top three recommendations is "this step does not need the model; replace it with a function." Clients are usually surprised, then relieved, then visibly lighter. Their infra cost goes down. Their reliability goes up. Their debugging time collapses. The part of the system that is an LLM becomes small enough that they can actually reason about it, which is the precondition for trusting it.

The real AI skill in 2026 is not "use the model everywhere." It is knowing where the model starts and stops.

Go through every step of your current system and ask the two-question test: does this input require understanding natural language, and does this output require judgment? If both answers are yes, use the model. If either is no, use code. If you are not sure, write the non-AI version first. It will be faster than you expect and will tell you within an hour whether the model is actually needed.

Measure your per-step LLM cost on a monthly basis. If any single step is more than 30% of your total AI budget and is not doing natural-language judgment, it is a candidate for replacement. Most of my clients find one of these within the first week of looking.

When a client asks for "more AI," ask them what problem it would solve. "More AI" is not a problem. "Our ops team spends eleven hours a week manually classifying lead emails, and we want to get that to under one" is a problem. The answer to it might not involve AI at all.

And the hardest one: when you reach the decision to replace an AI step with a function, do it, even if it means losing the bragging rights. The goal is not to use AI. The goal is to ship systems that work. Most of the time those are not the same thing, and the people who learn to tell them apart are the ones whose systems are still running a year after launch.