Ian Malcolm delivers the most quoted line in Jurassic Park over lunch, before anything has gone wrong: your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should.
It lands because of who he is arguing with. Hammond is not stupid. His team has done something astonishing, and everything in the park works, right up until it does not. The failure was never the technology. It was that nobody in the building had the job of asking whether the technology belonged there.
Somewhere in your company, someone is currently proposing a language model for a task a script could do. This post is the lunch argument.
The Wrong Tool, With Enthusiasm
Real examples we have seen in the wild, names withheld.
A team using a frontier model to convert dates between formats, per row, at API prices. A pipeline asking an LLM to check whether numbers fall inside fixed thresholds, a task an if statement has handled flawlessly since 1957. A workflow where a model reformats CSVs whose columns never change, and occasionally, delightfully, renames one.
Each of these worked in the demo. Each shipped. And each replaced something free, instant, and correct with something slow, metered, and mostly correct.
That trade is the tell. A script gives the same answer every time, in milliseconds, for nothing. A model call takes seconds, costs money on every single execution forever, and is probabilistic by nature, which means that at sufficient volume the weird variant answer is not a risk but a schedule. You will meet it. Usually downstream, in a system that trusted the output.
And the meter is the smaller cost. The larger one is operational: the moment a model enters a workflow, you inherit prompt maintenance, evals, output validation, and monitoring for the life of the feature. We have written about why evals are non-negotiable for AI systems. That obligation is worth carrying when the model does something code cannot. Carrying it to reformat a CSV is paying dinosaur-park insurance on a petting zoo.
The Boring Script Test
One question separates the two categories: can you write down the rules?
Sit down and try to spec the task as ordinary code. Enumerate the inputs. Enumerate the transformations. If you can finish that document, the task is deterministic, and deterministic tasks belong to deterministic tools. Ship the boring script. It will outperform the model on speed, cost, and correctness simultaneously, and it will never have a creative day.
The interesting outcome is when you cannot finish the document. You start writing rules and they multiply. "Extract the vendor name from the invoice" becomes forty edge cases before lunch: sometimes it is in the header, sometimes the footer, sometimes it is a subsidiary name, sometimes the document is a photo of a fax. When the rules explode, or the input is human language rather than structured data, or the task is judgment ("is this complaint angry enough to escalate?"), you have found actual AI territory.
The test also reveals a third and most common category: mixed tasks. Most real workflows are 90% mechanical with one genuinely fuzzy step in the middle. The mature design is not "AI system." It is a boring pipeline with one narrow model call where the fuzz lives, wrapped in code on both sides: deterministic preprocessing in, schema-validated output out.
The narrower the model's job, the better every part of the system gets. Cheaper, because the model handles one step instead of ten. Easier to evaluate, because a narrow task has checkable answers. Easier to debug, because when something breaks you know which stage is probabilistic. Our own production systems follow this shape everywhere: models handle the language, code handles everything else, and the boundary between them is a schema.
Why Smart Teams Get This Wrong
Nobody over-applies AI out of ignorance. They do it because the incentives point that way.
"AI-powered" gets a feature onto the roadmap. It gets budget. It gets the demo slot at the all-hands. A cron job that does the same work better gets none of those things. So the model goes in, not because the problem demanded it but because the organization rewards its presence.
There is also a quieter force: with a capable model one API call away, reaching for it is now easier than thinking. Writing the boring script requires understanding the problem well enough to enumerate its rules. Prompting a model lets you skip that understanding and ship anyway. Sometimes that is a legitimate trade. But be honest that it is the trade being made, because the understanding you skipped does not disappear. It comes back as an incident.
Hammond's park had the same dynamic. Spared no expense on the genetics. The door locks ran on one underpaid guy's spaghetti code. The glamorous technology got the investment; the boring infrastructure got Nedry.
The Malcolm Question
None of this is an argument against AI. We build AI systems for a living, and the technology is the most useful thing to happen to unstructured data in decades. The argument is against skipping the question.
So institutionalize the question. Somewhere in your process, before a model call ships, one person should have to answer in writing: what does this task need that deterministic code cannot provide? If the answer is real (messy inputs, language, judgment), build it, eval it, ship it proudly. If the answer is a shrug, you have just been handed a faster, cheaper, correct-every-time design for free.
Whether you could was settled the day you got an API key. Whether you should is a per-task question, and it is cheap to ask. Audit your existing model calls this quarter and ask it retroactively. Most teams find at least one dinosaur that should have been a cron job.
