Everyone’s talking about what AI is going to take from developers. I want to talk about what it’s exposing.
Over the past few months, I’ve had a front-row seat to three very different experiences with AI-assisted development. A business owner building his first app. Me, vibe-coding a WordPress plugin on a weekend. And one of my teams is running a project where AI agents write roughly 70% of the code. The outcomes were wildly different — and the reason comes down to a single skill that has nothing to do with knowing the right framework or the right prompt.
The business owner is sharp. He’s not a developer, but he understood the idea well enough to describe what he wanted, and the AI ran with it. The app came together faster than anyone would have expected five years ago. Then things started breaking. Not catastrophically — just the quiet, frustrating kind of broken where something doesn’t work and you don’t know why.
That’s where he hit a wall. Hard.
The AI would suggest a fix. He’d apply it. Something else would break, or the same thing would still be broken in a slightly different way. Rinse and repeat. No progress, just churn. He described it as feeling like he was going in circles.
What he’s missing isn’t technical knowledge in the traditional sense. He’s missing the ability to read a situation analytically — to identify what’s failing, hypothesize why, test it deliberately, and use the result to narrow down the problem. That’s debugging. And it turns out, it’s not a skill you pick up by accident.
A few weeks ago, I built a WordPress plugin. No prior WordPress experience, no plan to develop one — I just needed something specific and decided to see how far I could get with an AI agent doing the heavy lifting. Pretty far, it turned out. The plugin came together quickly.
And then it didn’t work.
Here’s the thing: finding out why wasn’t particularly hard for me. Not because I know WordPress internals, but because I know how to debug. I could look at what was happening, make a reasonable guess about where the problem was, ask the agent to investigate that specific area, evaluate what it found, and steer from there. The AI did the legwork. I provided the direction.
That felt like the natural division of labour. The agent is fast, tireless, and has seen a lot of code. But it doesn’t actually understand the problem — it responds to prompts. If you can’t give it a useful prompt because you don’t know what you’re looking for, it’ll spin its wheels as fast as you let it.
The clearest illustration I’ve seen of this is my own team running an AI-heavy project. These are experienced developers. AI agents handle the bulk of the code generation — that part really does run on autopilot most of the time. But when something breaks, watch what happens: the human is back in the driver’s seat immediately.
They’re not asking the agent, “Why is this broken?” and waiting. They’re reading logs, forming hypotheses, checking assumptions, and then using the agent as a tool to test their thinking — not as an oracle to deliver answers. The agent helps. But the analytical work, the actual problem-solving, is happening in the developer’s head.
That distinction matters more than anything else I’ve observed about how AI changes the job.
There’s a seductive idea floating around that AI raises the bar for everyone — that a junior developer with good prompts can produce senior-level output. And there’s something to that, up to a point. AI has genuinely raised the floor. Tasks that used to take days take hours. Boilerplate is dead. Getting a working prototype no longer requires deep expertise.
But the ceiling hasn’t moved. When things go wrong — and they always go wrong — the person who can think analytically about a broken system is still the most valuable person in the room. AI doesn’t change that. If anything, it makes it more visible because the gap between “writing code” and “understanding code” has never been wider.
A developer who can generate code but can’t debug it is building on sand. They’ll get far faster than before, right up until they hit a problem they can’t reason through — and then they’ll be stuck in the same loop as my business-owner friend, applying fixes without understanding the system.
So if I had to tell a developer what to actually invest in right now, it’s this: get good at debugging. Not as a technique, but as a mindset. Learn to read a failing system and form a hypothesis. Learn to test that hypothesis in isolation. Learn to look at a stack trace and ask “what does this actually tell me?” before jumping to solutions.
None of that is flashy. It won’t make a great LinkedIn post about your AI workflow. But it’s the skill that determines whether you’re steering the AI or being steered by it.
The developers I see thriving with these tools aren’t the ones with the most sophisticated prompts. They’re the ones who know what they’re looking at when something breaks.
