The best AI strategy is sometimes no AI
A client wanted AI in a workflow with fixed rules. We told them not to: ordinary code was cheaper, faster and easier to audit.
- The point
- Fixed rules need ordinary code, not a model
- When AI helps
- Ambiguity, context, or a rule nobody has written down yet
- When it doesn’t
- Exact answers from known rules, where a model adds cost, delay and doubt
Sometimes the right AI strategy is to leave AI out.
A client asked us to add AI to one of their workflows. We sat down and mapped it out: the inputs, the rules and the exact shape the output had to take.
The workflow had no judgement in it
About halfway through, we knew what we were going to tell them. The rules were fixed and nothing in the workflow needed judgement, so the same input always had the same correct output. It was a simple conditional that nobody had got round to writing yet.
“Don’t use AI here.”
It was the opposite of what we had been brought in to say. But a few lines of ordinary code would be faster, cheaper and more reliable than a frontier model in the middle of the workflow. A function never decides to get creative when nobody asked it to.
Where a model earns its place
Models are very good now, and we think that is the cause of the problem. When a tool can plausibly do anything, the instinct is to run everything through it. A better hammer makes everything look like a nail.
A model earns its cost when there is ambiguity to resolve, context to weigh, or a rule nobody has written down yet. Where the right answer depends on reading the situation, a model is the right tool.
When the rules are known and the answer has to be exact, the model is overhead. It is slower, more expensive and less predictable than the few lines it replaced, and much harder to debug. The old code either worked or it did not. The model version mostly works, and cannot always tell you why.
Keeping code deterministic
Plenty of problems need good engineering and nothing else. It is tempting to treat determinism as a limitation you grow out of once the model is big enough. We would protect it. A function that returns the same answer every time is working correctly.
Audit trails, exact reproduction and failures you can trace all disappear the moment a model enters the loop. Sometimes that is a fair price, but it should be paid on purpose, for something you actually need.
Our job is also to say no
For us, most of the work is deciding which problems need a model, and saying so when one does not.