My last few posts leaned on a comfortable assumption: that you already debug, already run root-cause analysis, already treat a post-incident review as second nature. For a lot of developers that simply isn’t true — and I don’t only mean juniors. Debugging is a skill, a genuine and teachable one, and we mostly don’t teach it. We assume it arrives on its own. It doesn’t — and the way most of us now work is quietly making sure it arrives less often.
The instinct nobody was taught
Ask a strong engineer how they found a gnarly bug and they’ll describe something that sounds like intuition: “it smelled like a caching problem.” But unpick it and there’s a method under the magic — form a hypothesis, reproduce the failure, isolate one variable at a time, bisect the space, follow the evidence rather than the hunch, and above all trust the error message over your assumptions. None of that is innate. It’s built, slowly and often painfully, over years of being stuck and clawing your way out.
Which is exactly why it’s so unevenly distributed. It’s tacit knowledge — the kind that transfers by apprenticeship and struggle, not by a lecture or a copied answer. If you came up somewhere with good seniors who made you explain your reasoning, you probably have it. If you didn’t, you might have a decade of experience and still, when something breaks in an unfamiliar way, be reduced to changing things at random and hoping. I’ve worked with seniors like that. It isn’t a character flaw; nobody ever showed them the method, because everyone assumed someone else already had.
What the good version looks like
I’ve written before about proving a failure was the platform’s fault, not ours — and that whole story is really a debugging method in disguise: isolate the variables, reproduce it minimally, rule out your own code, build a case from evidence rather than assertion. That’s the instinct made explicit. The same discipline underpins good observability: you instrument the system precisely so that when it misbehaves you can follow the evidence instead of guessing. Debugging and diagnosis are the same muscle at different scales — one bug, one outage, one architecture.
How AI makes it worse
Here’s the part that’s been nagging at me. A model will hand you a plausible fix in seconds. Paste the stack trace, get a confident answer, apply it, move on. Often it even works. And every time it does, the struggle that would have built the instinct simply doesn’t happen.
That’s the quiet cost. The old, slow, frustrating loop — stuck, hypothesise, test, wrong, try again — was never just overhead. It was the learning. Remove it and you remove the thing that turns a junior into someone with the smell for a caching problem. You get the fix without the lesson, and the lesson was the point.
Then there’s the sharper failure. Sometimes the model is confidently, fluently wrong — it invents a cause, cites a config option that doesn’t exist, “fixes” a symptom while the real fault sits untouched. I’ve caught it doing exactly this in my own work: a wrong root cause stated with total assurance, a fabricated setting, a plausible figure with nothing behind it. Catching that requires the very instinct that leaning on the tool prevents you from building. It’s an old pattern with a name — the irony of automation: automate the easy cases and the human is left to handle only the hard ones, now with less practice than ever. Applied to debugging it’s a trap, because the tool is most helpful where the stakes are lowest and least reliable exactly where you need judgement most — and it erodes that judgement on the way.
Lever, not crutch — for diagnosis specifically
I don’t want this to read as a case against the tools; I use them daily and they genuinely make me faster — this post was drafted with AI assistance, and the about page says how. Note which handoff that is, though: prose, not diagnosis. The distinction is the one that matters everywhere AI touches how we think: is it a lever or a crutch? A lever accelerates a diagnosis you could have reached yourself — you know what you’re looking for and the model gets you there quicker. A crutch replaces reasoning you never learned to do — and every use makes the next one more necessary.
So the decision isn’t whether to use AI to debug. It’s what you hand it and what you keep. Hand off the mechanics — the boilerplate, the syntax, “what’s the flag for this.” Keep the loop: the hypothesis, the “does this actually fit the evidence?”, the verification. And if you’re responsible for people coming up now, protect their struggle a little — have them explain why the fix works rather than just applying it, and let them sit in “stuck” long enough to build the thing that lasts. Reach for the model as a hypothesis generator you then interrogate, not an oracle you obey.
The one to keep
Of all the skills to let quietly atrophy, this is the worst possible choice — because the diagnostic instinct is precisely what you need on the day the tool fails you: when the answer is confidently wrong, or the problem is novel enough that there’s no plausible-looking answer to copy at all. Almost everything else you can look up. The ability to stand in front of a broken system you don’t understand and methodically work out why has to be in your own head. As ever it comes down to what you’re optimising for — and optimising your own speed today by never learning to debug is a spectacularly bad trade.