Rules first, then the model

I build AI agents and LLM pipelines for a living, and I start almost every one of them with no model at all. Most teams in 2026 do the opposite: a model in front of every form before anyone has read a single one.

Google's own machine-learning guide is on my side, which is an odd place for a company that sells machine learning to stand. Rule #1 is don't be afraid to launch a product without machine learning.

---

Martin Zinkevich wrote that guide as 43 rules to pass on Google's best practices, and the first one has aged better than most of what's been written about AI since. The argument is short. Machine learning needs data. Until you have it, a simple heuristic, which is a rule a person can read, gets you a good part of the way there. In his words: "If machine learning is not absolutely required for your product, don't use it until you have data."

He's honest about the other half too. Rule #3 says to choose machine learning over a complex heuristic, because "a complex heuristic is unmaintainable." Rules lose eventually. I'm not going to pretend they don't.

I'm arguing about the order.

---

Say you run finance at a company of a few hundred people. Expense reports arrive as card exports, PDFs and phone photos of crumpled receipts. Every line needs a category: travel, meals, lodging, software. The category decides which budget pays and how the books report it.

The pitch writes itself. Call it the LLM reflex: upload the receipts, ask a model for the category, pick the three where it looks right, demo on Friday. Why write rules when the model can read the receipt?

It can read it. Who checks it?

A guessed category is a guessed number on somebody's budget report. So finance still reads every line. The hours stay exactly where they were, and now there's a bill for every receipt the model reads and a new kind of error that sounds sure of itself.

And the error moves around. In September 2025, Thinking Machines Lab, Mira Murati's research company, sent one open model the same prompt 1,000 times at temperature 0, the setting that's supposed to make output repeatable, and got 80 different completions back. The cause was mundane: the server packs your request into a batch with whatever else is running, and the size of that batch nudges the arithmetic. Stack the ordinary wobble of a model squinting at a blurry photo on top of that, and you get a system that files a taxi receipt under travel on Monday and under client entertainment on the re-run, with nothing changed but the day.

Those were thousand-token answers, and a one-word category flips far less often. Less often is still a number you can't predict.

Build the boring thing

Card payments already carry half the answer. They come with a merchant category code, a four-digit number from a standard called ISO 18245 that says what kind of business took the money. 5812 is restaurants. 4121 is taxis and limousines. 7011 is hotels. It tells you the kind of shop, not what you bought there, which is why it's half the answer and not all of it.

So version one is a lookup table and a few dozen lines of code. 5812 maps to meals. 7011 maps to lodging. A short list of known vendors maps to software. And here's the part that matters: anything the table doesn't cover doesn't get a category. It gets a note.

"No merchant code: cash receipt."

"Amount on the photo doesn't match the card charge."

"Hotel bill with a restaurant line inside it."

No model fallback. The tool refuses to guess.

That refusal is the whole design. A wrong rule is wrong the same way every time it fires. Say the table maps 4121 to travel, and it turns out the sales team books cars for clients, which finance wants under entertainment. Every one of those rides lands in the same wrong bucket. Someone notices once, you add one line for the sales team's cards, and it's fixed for every receipt from then on. Re-run last quarter and the old ones move too.

When a model is wrong, it's wrong somewhere new. You can't fix it once, because there is no once. There's a prompt tweak, and a hope.

"Rules don't scale"

The people who say this are right. Every card provider exports a different file. Every new country brings receipts you've never seen. The table grows, the exceptions grow, and somewhere around the fortieth special case you're writing the complex heuristic Zinkevich warned you about.

I still want them first.

Look at what the boring tool produces besides categories. Every "needs review" note is a question the rules couldn't answer, and a person in finance answers it. After a few months that pile turns into something nobody set out to build: a list of exactly the cases the rules can't handle, each with an answer a human checked.

That's a job list for a model. It's also the exam you'll give it.

The LLM reflex skips that list. It runs every receipt through a model on day one, pays a person to check every receipt after that, and learns nothing about the work in between.

Rules first learns the work by force. You can't write a rule for a case you don't understand, so you have to walk over and ask the person who handles it. They know why the hotel bill has a dinner on it. They know which vendor bills twice for one purchase. None of that is in a prompt, and all of it ends up in your table.

The week the model earns its turn

So when does the model come in?

The week a new case costs more to write a rule for than a model's answer costs to check. Nothing else decides it. "The model can do it" was never the question; models can do lots of things. The question is what it costs to know whether it did.

By that week you have everything the reflex never had. You know which cases are hard, because the queue told you. You can score a model against a few hundred answers people already checked, before it touches a live receipt. And you keep the rules.

Zinkevich has a rule for this too, Rule #7: turn heuristics into features, or handle them externally. In plain words, feed the old rules to the model as inputs, or keep them outside it as a check. I take the second. The table that maps 5812 to meals doesn't retire. It becomes the check on the model. If the model calls a restaurant charge "software," the rule flags the conflict and sends it to a person before anything reaches the books, and code too dumb to be persuaded gets the last word.

The model takes the long tail. The rules take everything else, and they watch the model.

The labs paid for the chair

The model companies came to the same place in May, and they did it with money.

On May 4, Anthropic announced a new enterprise AI services company with Blackstone, Hellman & Friedman and Goldman Sachs. Its own example of how an engagement starts is the company's engineers "sitting down with clinicians and IT staff." A week later, OpenAI launched the Deployment Company, a majority-owned unit with more than $4 billion from 19 partner firms, and agreed to buy the consultancy Tomoro so it starts with about 150 forward deployed engineers and deployment specialists. Forward deployed engineer is the job title for people who sit inside a customer's business until the thing actually works.

Two of the best-funded model companies on earth are building consulting firms. Neither is telling anyone to write rules. They're paying for what rules are made of: the model doesn't deploy itself, so somebody has to sit next to the people who do the work and write down what they already know.

The rules are the notes. It's the same arc I see in agents: the model explores, and whatever you learn hardens into plain code.

The LLM reflex puts the new tool as far from the people who do the work as the building allows. Rules first puts you at their desk, because that's the only place the rules come from.

Pull up a chair. Bring a notebook.