The AI conversation right now is split down the middle, and I think many people on both sides are way off the mark.
On one side, you've got people who think AI is the answer to everything - the hype, the breathless benchmarks.
On the other, you've got people who've decided it's all slop and nonsense - overhyped, unreliable, not worth their time.
And I think that second group, the ones who've written it off entirely, are going to get a rude awakening. They don't understand exponential improvement, and non-adoption doesn't slow down the technology - it just means they won't have a voice when the decisions get made.
But I also understand where some of that negativity comes from. If you've only seen AI used badly - generic chatbots spitting out waffle, "AI-powered" products that are just a thin wrapper around an API call with no guardrails - then of course you'd be sceptical. I'd be sceptical too. The problem is that a lot of people are deploying it without thinking about what happens when it gets things wrong.
I'm building tools with AI right now that genuinely surprise me with what they can do. But the part that makes them reliable enough that I'd trust them with real data is almost always the most boring piece of the system.
I'm talking about rules-based code - if-then logic, pattern matching, lookup tables. The kind of software that's been around since before most of us started our careers, and that nobody has ever described as exciting. But in the age of AI, it turns out to be more valuable than ever.
AI is probabilistic.
Large language models handle ambiguity, interpret messy natural language, and make judgement calls that rigid rules would never manage. That's their strength. But they're fundamentally probabilistic - they work with probability and uncertainty. They will hallucinate, miscategorise, and produce unexpected output. Not as rare edge cases, but as a basic property of how they work. That's fine when you understand it. It's what makes them good at the hard stuff.
Most tasks aren't the hard stuff. Most of the inputs flowing through your system have predictable, known answers. A recurring payment from the same supplier every month doesn't need an AI to categorise it. A customer enquiry that matches one of your twelve standard request types doesn't need a language model to route it.
And yet I keep seeing teams route everything through the AI, paying the full cost on every single request - latency, token spend, and unpredictability - even for inputs that a lookup table would handle perfectly. It's a bit like hiring a brilliant consultant to sort your post. They can do it, but you're wasting their strengths on work that doesn't need them.
This is where old-school rules-based software comes in.
Rules handle the predictable. AI handles the rest.
The principle I follow in everything we build at HumanSpark AI is straightforward: let deterministic, rules-based code handle everything it can. Only call the AI for the stuff that rules can't reach. And when the AI does run, never trust its output until a separate piece of predictable code has checked it.
This is what Boring AI looks like at the level of actual system design - an architecture that works when real data is flowing through it.
I talk a lot about "start boring" when I'm advising organisations on their first AI projects - pick the unglamorous, repetitive process, not the ambitious moonshot. The same principle applies when you're building the system itself. The boring rules engine is your foundation. The AI is the exception handler, brought in only when the predictable path runs out of answers.
In practice, this means a three-stage pipeline.
- Stage 1 - The rules engine. Pattern matching, lookup tables, simple heuristics. If the rules can handle the input, they do. Only inputs that don't match any rule move forward.
- Stage 2 - The AI fallback. The language model proposes a suggestion. The AI suggests; it does not decide.
- Stage 3 - The hard gate. A separate piece of rules-based code validates the AI's suggestion against an authoritative source of truth. If the suggestion checks out, it's accepted. If not, it's rejected and flagged for human review.
That third stage is where we can easily go wrong.
Checking the AI's output
A hard gate is not a prompt instruction. It's not asking the AI to "please only pick from this list." Prompt instructions are still merely suggestions to a probabilistic system - they work most of the time, which isn't good enough when you're writing to a database or changing someone's financial records.
A hard gate is a completely separate piece of traditional code that checks the AI's output against a known-good source. Is the suggested category actually in the valid category list? Does the output conform to the expected format? Is the value within the allowed range?
The check runs against data from an authoritative source - an API, a database, a configuration file - not from the AI itself.
Rules-based software handles the predictable inputs up front (Stage 1) and checks the AI's output at the back (Stage 3).
The simplest hard gate you'll ever build
Say you've put an AI chatbot on your company website. You absolutely, under no circumstances, want it to swear at your customers. You can tell the AI in the prompt to be polite, and it will be - almost all of the time. But "almost all of the time" is a terrible standard when you're talking to customers.
So you build a hard gate. You give it a list of words the chatbot is never allowed to say - including, let's say, a particular four-letter word that rhymes with "duck." Before any AI response reaches the customer, the gate scans it. If the word appears, the response gets blocked entirely, and the customer sees something like "I'm sorry, I wasn't able to answer that. Can I help you with something else?"
It's simple, it's boring, and it's completely reliable.
Now, you will get edge cases. A customer types in "My name is John Motherducker" and the chatbot, being ever so helpful, tries to respond with "Hello Mr Motherducker, how can I help?" The hard gate catches it, and the response never reaches the customer. Is that an over-correction? Probably. Mr Motherducker is going to have a slightly confusing experience. But I'd much rather have a chatbot that occasionally can't respond than one that swears at a customer because the AI thought it was just being polite.
You can build more sophisticated rules too. A few years ago, a Chevy dealership in the US put an AI chatbot on their website without any hard gates. Someone talked it into agreeing to sell them a car for a dollar. A binding offer, confirmed in writing, by a bot that had no business making pricing decisions. A simple rule - "if the conversation involves pricing, do not confirm any amount below X" - would have prevented the whole thing. It's an if-then statement - the kind of code we've been writing for decades.
These are deliberately simple examples. Hard gates don't need to be clever - they just need to exist.
A more technical example: Booky
Our bookkeeping tool Booky follows this pattern for transaction categorisation. SparkCore (our integration layer) connects to the accounting software and pulls back the list of transactions and the valid chart of accounts. SparkCore moves data - nothing more.
Booky's rules engine (Stage 1) tries to match each transaction using deterministic rules - payee patterns, amount ranges, recurring transaction signatures. For the transactions that don't match any rule, Booky's AI (Stage 2) suggests a category. Then Booky's hard gate (Stage 3) checks: is that suggestion actually in the valid category list that SparkCore pulled from the accounting software?
If yes, accept. If no, reject and flag for human review.
In this system, roughly 80% of transactions match deterministic rules. That means we've cut AI costs by 80% and eliminated 80% of potential hallucination incidents.
Rejections become rules
When the hard gate rejects an AI suggestion, we don't automatically retry. An AI that miscategorises a transaction will often be wrong in the same way on a second attempt - you'd just burn tokens in a loop.
Instead, we log the suggestion and the reason it was rejected.
Those logs are training data for us, not for the AI. If we see the same rejection pattern showing up repeatedly, that's a clear signal to write a new deterministic rule. Every rejection is an opportunity to expand the rules engine, which means the AI fires less often over time.
The system gets more predictable and cheaper as it matures. The AI gradually works itself out of a job as we learn enough from watching it to write better rules. (The recovering software engineer in me finds this satisfying.)
How you know it's working
The metric that matters most is your rules-to-AI ratio: what percentage of inputs are handled by deterministic rules versus the AI fallback? If that ratio is climbing, the system is maturing exactly as it should. If it drops, your rules probably need updating.
Beyond that, a few non-negotiables: every AI suggestion passes through the hard gate before any system state changes. Every rejection produces a structured log entry. And there's always a clear path to human review - built in from day one.
Beyond bookkeeping
The same three-stage pattern applies anywhere you're integrating AI output into a system that needs to be reliable. We use the same architecture in SessionPilot (which monitors live workshop delivery), in our tender response tools, and it'll be the foundation for whatever we build next.
If you're building anything that puts AI output into a production workflow - or you're overseeing people who are - the question worth asking is: where do the rules sit?
P.S. If you want more on the philosophy behind this approach, I've written about it in the Boring AI Manifesto.
Checking the output is how you keep the risk in bounds. I set out the sampling approach in the Verification Dial.
