AI as a solution, not the goal
Most failed AI projects didn't fail because the model was bad. They failed because nobody asked what challenge it was for. A case for challenge-first development.
There’s a question I’ve started asking in every project kickoff, and it makes some rooms uncomfortable: “What’s the challenge this solves if we delete the AI?”
If the answer is “there isn’t one,” that’s not a red flag about the idea. It’s a red flag about the framing. We’ve spent two years treating “use AI” as the objective, when it was only ever a means. The objective is, and always was, a challenge worth solving.
The tell
You can usually spot a goal-first AI project within five minutes. It’s described in terms of the technology — “an AI agent that…”, “an LLM-powered…” — rather than the pain. Nobody in the room can tell you, in plain language, who is suffering and how much. The demo is gorgeous. The retention is zero.
Challenge-first projects sound different. They start with a person and a cost: three hours every morning, gone. The technology is an implementation detail you argue about later — and sometimes the honest answer is that you don’t need a model at all.
The 95/5 rule I keep rediscovering
In practice, most “AI challenges” are mostly not AI challenges. Take messy data: the vast majority of the mess is mechanical and deterministic — formats, whitespace, null tokens — and a regular expression beats a language model on every axis that matters: speed, cost, and trust. The model earns its keep on the genuinely ambiguous slice, the part where judgement is actually required.
Drawing that line — this is a rule, this is a judgement call — is the real development work. It’s less impressive in a demo and far more valuable in production.
Why “where AI is NOT used” belongs in the case study
I write up my projects with an explicit section on where I chose not to use AI. Not as false modesty — as the most honest signal of judgement I can offer. Anyone can bolt a model onto a challenge. Knowing where it would make things slower, costlier, or less trustworthy is the harder, more valuable skill.
Restraint is a feature. The discipline to leave the model out of the 95% is what makes the 5% trustworthy.
What this looks like in practice
- Start from the cost, not the capability. Name the hours, the errors, the money. If you can’t, stop.
- Default to deterministic. Reach for a model only where rules genuinely can’t reach. Let it propose, keep a human to decide, on anything that’s hard to reverse.
- Make the boundary legible. Users trust a system whose behaviour they can predict. “Here’s exactly what the AI did and how to undo it” beats magic.
None of this is anti-AI. I build with these models constantly, and they’re extraordinary. It’s anti-aimless. The most impressive thing you can do with a powerful tool is know precisely when not to use it.