Most AI projects don’t replace people.
They replace a cheap operator with an expensive supervising engineer.
That’s not automation. That’s expensive supervision – and it’s the most common outcome I see when organizations put AI in the execution path before they’ve thought through what that actually means.
The reason it happens is structural.
When a model sits inside a running process, every decision it makes is non-deterministic, drifts over time as the model updates, and is hard to trust without verification. Nobody is comfortable letting it run unsupervised. So someone has to watch it. A senior engineer reviews every tenth output. A team builds a monitoring dashboard. An escalation path gets designed for when the model gets it wrong.
All of that is real work, performed by expensive people, running continuously.
At small scale, this is manageable. Teams accept it as the cost of getting started. At scale, it breaks the economics entirely – and often quietly, because the cost shows up in headcount and engineering time, not in a line item labeled “AI supervision.”
The reframe I keep coming back to: AI should design the process, not run it.
This isn’t a semantic distinction. It changes the entire architecture.
Use AI upstream – to analyze patterns, surface edge cases, map decision logic, identify the rules that experienced people apply without thinking. That’s where AI’s ability to reason across large amounts of data and text is genuinely valuable. Let it do the hard work of turning operational knowledge into explicit, executable logic.
Then move execution into code.
Code is deterministic. It doesn’t drift. It fails loudly when something is wrong. It scales without supervision. You can audit it, version it, test it, and hand it to a junior engineer without writing a manual on how to interpret its outputs.
The AI did the hard thinking once. The code runs it ten thousand times without anyone watching.
This matters especially for the kinds of processes organizations actually want to automate: approvals, routing, triage, classification, extraction. These look like judgment calls because humans have been making them intuitively for years. But underneath most of them is a decision tree that can be extracted, documented, and encoded – if you take the time to surface it.
AI is unusually good at that extraction step. It can interview subject matter experts, analyze historical decisions, map the exceptions, and draft the logic. That’s a high-value, time-limited use of the model.
Running every instance of the decision in production forever is not.
The test I apply is simple. If your system requires a senior engineer to review a meaningful fraction of its outputs, you haven’t automated the process. You’ve changed who performs it and added a layer of complexity on top.
Real automation means nobody is watching because nobody needs to. The process runs. Exceptions route to humans when genuinely warranted. Everything else completes without intervention.
That’s the bar. Most AI deployments are nowhere near it – not because the models aren’t capable, but because the teams deployed them into execution before extracting the logic that should have become code.
Fix the architecture. Use AI to think through the process. Then let code run it.