The AI work I trust most is the work that looks boring. There's no clever prompt, no amazing inspiration, no surprises. It does the same boring thing every time, and that is exactly why I trust it.
Most people reach for AI's cleverness first and its dependability second. I strongly believe you need it the other way round.
There are two kinds of work in software and AI: work that runs on rules, and work that runs on the AI's "best guess".
A rule does the same thing every time. That's how traditional automations and software run - and you get repeatable consistency. There's no judgement call being made - so you can trust it. Where there's no rule, the AI falls back to its best guess - which is exactly why we need to verify it.
"Guess" can sound derogatory, and that isn't my point. In fact the AI's "best guess" is "pretty damn good, and getting better, and better". But when I say best guess, the word just means the answer isn't guaranteed and won't be identical every time, so a human should still check it. A guess you can rely on most of the time is a remarkably useful thing to have.
"Rules before guesses"
When I build anything with AI, I work software-first - rules before guesses. If I can write a rule for something, I write the rule, and then I never have to ask the AI again.
"Use AI to create the rules"
One of the best ways to use AI is to use it to help us build the rules, not to have AI make a judgement call every single time.
The decision making runs through a cascade:
- Simple rules first. If there's an exact rule - "if the filename contains 'invoice', move it to Finance" - use it. It does the same thing every time.
- Pattern rules next. No exact rule, but a reliable pattern you can describe? Use that. I like to use scoring systems for this (give each attribute a value).
- AI guess last. Only when there's no rule and no pattern do you fall back to asking the AI to make a judgement call.
For a while I described this as two steps - rules, then AI. That skipped something. Patterns belong in the middle, if they're created correctly. They're a predictable step that sits between an exact rule and a guess, and they catch a surprising amount before you ever reach the AI.
The effort goes in up front, building the rules, usually with the AI's help. Most of the work then runs on plain, predictable software, and the AI only handles the ambiguous edges. You've shrunk the part that can surprise you down to the smallest possible corner.
You've also shrunk the checking. Every case a rule handles is a case nobody has to verify - the person doing the checking is usually the most expensive part of the whole system. That's the verification tax, and it's why a clever AI system can end up costing more to run than the manual process it replaced.
"Use stochastic systems to build deterministic systems"
This is the technical terminology for what I'm talking about here but it's simple to translate: "Use AI to build traditional rules-based automations and software".
Often people find it hard to figure out where AI belongs, and where it doesn't. My suggestions:
- Use deterministic software as much as you possibly can, because it doesn't make judgement calls.
- Bring AI in only where you can't write a rule and you actually need one made.
- And keep it well away from high-stakes work where a wrong guess could do real damage.
Here's a small simple example of something I built for myself.
It's called TidyBot, and all it does is tidy my files on my PC - you know how your desktop files, your documents and your downloads, they all get messy and you have duplicates and stuff you don't need any more. TidyBot solves that problem for me.
It runs rules first - a filename with "invoice" in it goes to Finance. Then patterns, for the files that don't match an exact rule but clearly belong somewhere. Then, only for the stragglers it can't place any other way, it asks the AI to analyse and classify them. Most files never reach the AI at all, and the ones that do are the odd ones - the handful where a judgement call was always going to be needed.
A year-old startup let an AI agent loose on their own systems, and it wiped nine months of customer data, backups included. The lesson people take is that the AI made a mistake, and it did. A guess was allowed to run with nothing deterministic standing between it and the damage. Rules aren't only how you get consistency. They're the guardrail that stops a bad guess becoming a catastrophe.
Wrapping the unpredictable part in predictable checks - validate the input, reject anything malformed, refuse the destructive action outright, hand the uncertain cases to a person - is defensive programming. It's what makes a best guess safe to rely on inside a live system.
Rules go stale. Your approval threshold changes and the rule doesn't. A product line gets renamed and the pattern stops matching. Someone reorganises the folder structure and TidyBot files three months of invoices into the wrong place, every time.
A guess that goes wrong tends to go wrong visibly and differently each time, and somebody notices. A rule that goes wrong goes wrong silently and identically, and it can run for months before anyone looks.
So "test it once, trust it after" comes with a condition attached: somebody owns the rules, and something tells you when reality has moved on. That might be a review in the calendar, a count of how often the fallback is firing, or just a person who notices the numbers look odd. Build that in at the start, rather than at the point you find the problem in an audit.
I'll add one more caveat. Everything above is about the task in front of you this month - reliability now, in the system you're shipping this quarter. It is not advice about where AI is heading over the next few YEARS.
Those are different questions, and I'm writing about the second one in a companion piece.
So if you're building anything with AI, or paying someone to, here's the test I'd apply. Look at how much of it runs on traditional rules and how much runs on AI judgement. The more that runs on rules, the more you can trust it, the less you have to check, and the less it can surprise you on a bad day.
A quick glossary
You don't need any of this to put the idea to work, but it might help to know some technical terms for these concepts:
- Deterministic: rules-based work: traditional software and automation that does the same thing every time.
- Stochastic: the best guess: a prediction or answer drawn from probability - it is NOT guaranteed to be identical each time. Context changes it.
- Deterministic-first cascade with stochastic fallback: the technical name for the three-step order above - rules, then patterns, then the AI's best guess.
- "Stochastic parrots": a famous 2021 paper by Bender, Gebru and colleagues that is the academic grounding for why these systems guess rather than know.
If you're looking at a process in your own business and you can't tell which parts should be rules and which actually need a guess, that sorting question is one of the most useful things you can do before you automate anything, and it's one I'm happy to help with.
P.S. Working out which parts of a process run on rules, which need the AI's best guess, and where AI has no business being at all, is a lot of what I do. Book a Focus Call - twenty-five minutes to start sorting it together.