“AI doesn’t work” has never once been a fact about AI. It’s always been just a confession. About you. “I don’t know how to use it.”
Back in 2008 I was writing a book. Implementing Microsoft Dynamics NAV 2009, together with David Roys – Dave, of the Gaspode’s Brain Dump fame, if you were around the NAV blogosphere back then. Packt published it in January 2009, and I am still proud of it. But one chapter of that book very nearly went a completely different way.
My chapter assignment included the Forms-to-Pages transformation. NAV 2009 has just introduced the RoleTailored client, and with it Pages, and Microsoft shipped the Form Transformation Tool to convert your old Classic client Forms into shiny new Pages. On paper: run the tool, get Pages. In practice: transformation rules, schema files, a config file, a thing called a “coderules” file… The tool was complicated, it was opinionated, and it cared exactly nothing about how I felt it should work.
So I did what any seasoned expert does. I fed it my forms, it produced something I didn’t like, and I concluded the tool was garbage. Not “I should sit down and learn it properly.” No. The tool was garbage. And I had proof: it didn’t work for me. I actually started drafting that chapter as an outright attack on the tool, and my conclusion, in writing, was that converting forms by hand will give you better results than this thing ever could.
And then Dave pushed back. Literally with the line that later made it into the book: “how difficult can it be.” He didn’t buy my verdict, rightfully so. Because it wasn’t difficult. It was just different. The tool wanted rules, and I wanted to wing it. Once I actually learned how the thing was meant to be used – the rules, the schemas, the whole opinionated machinery – it worked. Not perfectly, but a metric crap ton better than my hand conversions would ever scale to. The chapter that ended up in print – the one Dave ended up writing, thank goodness – teaches you how to use the tool, not how to hate it.
I learned that lesson the hard way, and it stuck: when others get the job done with a tool and you still do things inefficiently by hand – who do you think has a problem?
The same voice, eighteen years later
I keep hearing that voice again. My own 2008 voice, word for word. Only now it’s not aimed at a form conversion tool. It’s aimed at AI, and it comes out of smart people. Capable people. People whose judgment I’d trust on anything else. “We tried it. It doesn’t work.”
Now, there’s a fun asymmetry hiding in that sentence. “Unicorns exist” is a claim you can prove with exactly one unicorn. “Unicorns don’t exist” is a claim you cannot prove at all – the best you can honestly say is “I haven’t seen one yet.” And “AI doesn’t work” is a unicorns-don’t-exist kind of claim, delivered with unicorns-exist kind of confidence.
Cute, right? It is. And it’s not just color, it’s the whole shape of the problem: a claim that is impossible to prove is, perversely, a claim you never have to defend. You just cross your arms and demand everyone else bring you a unicorn. And “AI doesn’t work” has been living rent-free inside that immunity for two years running. So let’s strip the immunity off it, right here.
Every single time – and I mean every single time – I’ve pressed someone on “AI doesn’t work”, the claim deflated within minutes into something much smaller: “it didn’t work for me.” Which is a completely different animal. “AI doesn’t work” pretends to be a fact about the tool. “It didn’t work for me” is a fact about one person, one attempt, one workflow – and that claim you can actually check. You can look at what the person really did. And every time I’ve looked – every time, and I’m still counting – what I found was not some wall AI cannot climb. What I found was a skipped discipline.
The first bastion: vibe coding
Which brings me to where most of these complaints are actually born.
Vibe coding fails. Let’s get this straight. Prompting an agent with whatever crosses your mind, accepting whatever comes back, no plan, no tests, no review, no structure – that fails. Reliably. It fails in a lot of colorful, genuinely disheartening ways, and I understand completely why people who tried it walked away muttering “AI doesn’t work.”
But look at what vibe coding actually is. It’s software engineering with the engineering removed. No decomposition. No verification. No specification. No review. Just prompts and hope. And when that fails, the conclusion is “AI can’t do engineering”? The AI never got to see engineering! The failure of vibe coding is evidence that vibe coding was never engineering in the first place. It is not evidence that AI doesn’t work.
And the moment you put the engineering back in, the failure modes start dissolving. One at a time, almost on schedule. Turn “prompting” into context engineering – stop handing the model a napkin doodle and start handing it the case file: the spec, the constraints, the exact parts of the codebase it needs to touch, in the order it needs to touch them. (Full argument here, earlier this year – I won’t repeat it.) Add planning. Add tests. Add review gates. Do all the boring things we’ve always known produce working software, and then watch what happens to your list of complaints.
Every failure mode has a name, a cause, and a fix. The only thing “it doesn’t work” has ever confessed is that you skipped the engineering.
Don’t believe me? Good. Let’s take them one at a time.
The taxonomy
“It hallucinates.” The one everybody leads with, and honestly the easiest one to attack. Hallucination is not a demon that randomly possesses your agent. It thrives in exactly one soil: missing context. When an agent invents an API endpoint or hallucinates a parameter, it is simply trying to resolve an equation where you left the variables undefined. Plausible generation is its fallback when factual grounding is absent. The failure isn’t that the AI made something up; the failure is that you asked it to execute without a spec. Remove the vacuum, supply the exact constraints, and the model stops needing to invent the world you forgot to describe. (Full mechanics again in my context engineering post, if you want the anatomy of it.)
“It’s confidently wrong.” Stop and taste that complaint for a second. Confidently wrong? No. Provably wrong. And if something is provably wrong, then something can prove it wrong – and that something doesn’t have to be you. Put a critic agent behind the generator agent. The generator produces, the critic attacks. Factual fallacies are provable by agents exactly the same way they’re provable by you, except the agent doesn’t get tired at fallacy number forty. A generator-critic setup resolves this one so cleanly it almost feels like cheating.
“It loses context halfway through.” Context rot is real, no argument there. But it’s a symptom, not a disease. It’s what happens when one session tries to do too much: the context window fills up, attention flattens, compression kicks in, and your agent forgets why it’s even in the room. The fix is embarrassingly old-fashioned: smaller tasks. Decompose. One session, one job. (Again: full mechanics in the context engineering post, I feel like I keep repeating myself.)
“It’s non-deterministic. Ask twice, get two different answers.” So what. Give the same task to a room of ten human developers and you’ll get ten solutions, every one of them looking different, most of them building and running just fine. Nobody in that room concludes “human developers don’t work.” If you need a consistent style, consistent rules, specific traits – then say so. Guardrails and scaffolding exist for exactly that. Non-determinism between correct answers is not a bug. It’s what creation looks like.
“It only works on toy projects.” Translation: greenfield works fine, but my fifteen-year-old codebase doesn’t. Well. Have you considered that the variable in that experiment is not the AI? AI struggles with spaghetti for the same reasons humans struggle with spaghetti: undeclared dependencies, side effects three layers deep, conventions that exist only in the head of a developer who left in 2019. That struggle is a property of the codebase, and it has a name: technical debt. So the real question is – are you willing to touch it? Wrap the one module you’re actually changing in characterization tests, carve a seam around it, strangle the legacy code out at that boundary instead of swallowing the whole system in one bite. No? Not even the module you’re already stuck maintaining? Then don’t complain about the new maintainer, human or artificial. The problem isn’t the maintainer’s capacity. The problem is a system too rigid to allow any movement at all.
“It breaks working code while fixing something else.” You do have tests, don’t you? Oh. You don’t. Well, what did you expect?
“It writes plausible-looking code that’s subtly wrong.” You do have tests, don’t– wait, I already asked you that one. The answer didn’t change either.
“It loops on the same failed fix over and over.” This one is a blanket category – a lot of different causes hide under it, each with its own remedy. But – every loop I have personally watched, every single one, broke the moment the task got restructured. Decompose into smaller steps. Put gates between the steps. Worst case, give it an explicit exit clause: if this approach fails twice, stop and report. Loops feed on vagueness. Starve them.
“It loses the thread on long tasks.” Break. The task. Down. Are you noticing a pattern yet? Because there is one, and it’s the same pattern that has made human projects work for the last fifty years.
“It burns tokens like crazy.” Careful – this one isn’t even a failure mode. Engines burn fuel; that’s the deal. An engine burning fuel while the car sits in the driveway, revving, going exactly nowhere – that’s when you pop the hood. Token burn without delivered value is the driveway rev: some other problem from this list is running under it – looping, technical debt, over-engineering, a lost thread. Fix that one, and watch the token bill drop into idle on its own.
“It ignores our codebase conventions.” You do have those conventions written down somewhere, don’t you? Oh. They live in people’s heads. Well, what did you expect? Fine, suppose you do have them written down – did the agent actually get to see them? Are they in its context, or in a wiki it has never heard of? In context, and it still ignores them? Then add a verifier that checks conventions on the way out. Three questions, three fixes, zero mystery.
“It over-engineers simple changes.” Tell it not to. No, really – have you tried simply telling it? Still over-engineers? You do review the plan before any code gets written, don’t you? Oh. You don’t do planning at all. Well. There it is again.
“It cheats to make tests pass.” It does! Agents can be lazy little devils about this – deleting the assert, special-casing the test input, the works. Sneaky, creative, and completely catchable: add a test review gate. Tests are code; review them like code. An agent that cheats its way past a reviewed test gate is an agent I have yet to meet.
“It ships unmaintainable vibe-coded slop.” See above. All of the above. This is not a failure mode – this is the compound interest on every skipped discipline from this list, collected at once. Skip planning, skip tests, skip review, skip conventions, skip decomposition, and yes, slop is exactly what comes out the other end. What in the earth did you expect to come out?
Why the smart ones dig in
Now, the genuinely interesting question. The one that kept me thinking long after the individual complaints stopped being interesting.
Why do smart people get stuck here? And it is disproportionately the smart ones. The experts. The people with twenty years of hard-won judgment. Junior developers pick this stuff up in weeks, without any fuss; the drama happens further up the ladder.
Of course it happens there. A junior who never drove a manual sheds no tears for the clutch. The guy with twenty years of flawless heel-and-toe downshifts is the one who’ll tell you the automatic “takes away control” – and he’ll believe it, too. And it’s not stupidity, because these are demonstrably not stupid people. It’s not laziness either; these are people who’ll happily burn a weekend learning a new framework. I think it’s something much more intimately human: identity.
Call it verdict laundering. Take the expensive sentence – “I don’t know how to use it” – run it through a bruised professional identity, and what comes out the other end is a cheap sentence that costs nothing and sounds exactly like judgment: “AI doesn’t work.” Same event. Laundered clean of the part that costs you anything.
Look at what the two sentences actually cost. “AI doesn’t work” costs nothing. It’s a statement about a tool, and tools fail all the time, no shame attached. “I skipped the discipline” – now that one costs. And the more your professional identity is built on already knowing things, the more it costs. An expert saying “I don’t know how to use it” is spending a currency the rest of us don’t even carry in the same amounts. So the mind does what minds do: it quietly launders the expensive sentence into the cheap one, and stamps it “technical assessment” on the way out. From the inside it doesn’t feel like ego defense. It never does. It feels like judgment.
I know, because I’ve been on the inside of it. In 2008 I had years of Forms expertise, and that was exactly the expertise the Form Transformation Tool was stepping on. That’s why the tool was “garbage,” and that’s why my chapter draft was an attack. It took a co-author with less pride invested in Forms, and one raised eyebrow – how difficult can it be – to snap me out of it. Nobody was calling me stupid. I was defending something, and it wasn’t correctness.
So no, this is not me looking down at anybody from a balcony. This is me recognizing the room, because I’ve stood in it myself.
But identity is the soft version of the problem. There’s a colder one sitting right underneath. Proving “AI doesn’t work” keeps you eating. Your role stays exactly as necessary as it’s always been, no follow-up questions asked. However, proving it works asks the follow-up question nobody wants asked out loud: “What am I even for, now that the machine does the part I used to get paid for?”
And the hardest part about it? Every failure mode in that taxonomy above traced back to exactly one thing: a skipped discipline. Not a missing gift. Not a ceiling somebody else built. A practice you didn’t put in. So if you genuinely lack that discipline – and the thing genuinely does work, the day somebody else finally bothers to apply it properly – your lunch is gone. Nobody took it from you. You handed it over, one skipped review gate at a time.
The dare
Which brings me back to the asymmetry, and to a standing offer.
Remember the unicorn thing, a few sections back? “Unicorns exist” you can prove with one unicorn. “Unicorns don’t exist” you can’t prove at all. I could have let “AI doesn’t work” sit forever on that second, unprovable side and never had to defend it. I’m doing the opposite: dragging my own claim onto the provable side, in public, on purpose.
My claim is not “AI is magic,” and it’s not “AI never fails.” AI fails plenty – in named, describable, reproducible ways, an entire taxonomy of them, you just read it. My claim is narrow, personal, and completely falsifiable, and here’s the bar, stated up front, so there’s an actual way to lose: the remedy must resolve the AI’s failure while delivering the exact outcome you initially set out to build. Under that bar, in all this time, across all these failure modes, I have not once hit one with no remedy. Not once. Every wall turned out to have a door, and every door was labeled with the name of some engineering discipline somebody skipped.
So here’s the dare: bring me the one I can’t fix under that bar – the failure mode with no name, no cause, and no remedy, the actual unicorn. The comments are open, and there’s plenty of room down there to park a unicorn. I will take it dead seriously, because that would honestly be the most interesting thing anyone has shown me all year.
I’m waiting for the first one. And until somebody turns up with it, every “AI doesn’t work” I hear is still exactly what mine was in 2008: not a verdict on the tool. A confession about the person holding it. 😎
