The Debugger Who Forgot How to Debug
You used to read a stack trace and know where to look. Now you paste it into AI before you've finished reading it. Here's what's happening to your debugging instincts — and how to get them back.
There was a time — maybe 18 months ago, maybe two years — when a cryptic stack trace was a puzzle. Not a pleasant one, exactly. But it was yours to solve. You'd read the line numbers, cross-reference the variable state, follow the logic backward until something clicked.
It might take 20 minutes. Sometimes an hour. But you always got there.
Now try this: open a bug report. Before you do anything else, notice what your hands do. Do they reach for the error message? Do they open a chat window? Do you even finish reading the stack trace before you're asking something to explain it for you?
If that felt uncomfortable to admit, that's this week's dispatch.
What debugging used to build
Here's what nobody talks about when they talk about AI replacing junior developers: debugging is not just a skill. It's a surveillance system. When you trace a bug to its source, you're not just fixing the bug. You're building an increasingly detailed mental model of how the system actually works — versus how you think it works.
Every bug you chase down is a data point. It tells you where the seams are. It reveals which parts of the system are brittle, which abstractions are leaky, which behaviors nobody documented. Experienced engineers have a kind of spidey sense for bugs: they look at a code change and can feel where it's going to break, before they've run a single test.
That sense doesn't come from reading documentation. It comes from years of following bugs to ground.
When you hand the debugging to AI, you don't just get the solution. You get a solution with no accompanying understanding. The bug is fixed. The model is not updated. And next time, you're still dependent on the tool to find the problem.
The four stages of debugging atrophy
It doesn't happen overnight. It's more like erosion:
- Stage 1 — Habitual offloading. You start using AI for "hard" bugs. Then medium ones. Then small ones. The threshold for "I should solve this myself" keeps moving up.
- Stage 2 — Tolerance for confusion drops. You become less willing to sit with an unfamiliar error. The moment something doesn't make immediate sense, you reach for AI. The natural frustration of debugging — which is just your brain's way of saying "this is new territory" — starts to feel unbearable.
- Stage 3 — Pattern recognition fades. You've stopped building the library. You no longer see a class of errors and think "I've seen this before." Every bug starts to feel like the first bug.
- Stage 4 — Loss of the startle reflex. The experienced engineer's superpower: reading a code change and having a physical reaction to something that looks wrong. That reflex is built from hundreds of hours of debugging. Remove those hours, and the reflex goes quiet.
One practice: The 20-Minute Rule
Before you ask AI anything about a bug, give yourself 20 minutes of genuine, unaided debugging. Read the stack trace. Add logging. Trace the data. Draw the flow on paper. If you still have nothing after 20 minutes, then ask AI — but bring your partial understanding with you.
The point isn't to suffer. The point is to finish the thought before reaching for the tool. That's where the learning happens.
What this costs you
The irony is that debugging is the one skill that AI is arguably worst at. AI will confidently suggest fixes that introduce new bugs. It will solve the symptom, not the cause. It will give you the equivalent of turning it off and on again — sometimes that's right, but often it papers over something real.
When you rely on AI to debug, you become dependent on a system that:
- Doesn't understand your codebase in the way you do
- Will confidently suggest wrong solutions
- Solves problems without teaching you anything
- Needs you to validate every answer anyway
At which point: what were you saving, exactly?
How to rebuild
The good news: debugging instinct is not gone. It's atrophied, like any muscle. You can rebuild it.
- No-AI debug sessions. Once a week, try to fix a bug without AI. Any bug. Start with something small. Write down what you learn.
- Debug by walking backward. Start at the error. Trace each step backward until you hit a point you recognize. Then ask "how did it get here?" — often the answer is the actual bug.
- Rubber duck with paper. Before you paste anything into AI, write one paragraph explaining the bug in your own words. Not for AI. For you.
- Compare notes. After AI fixes a bug, ask yourself: would I have found this? What was the clue I missed?
- Protect the boring bugs. The easy, repetitive bugs are the most valuable learning opportunities. They seem beneath you. They're not. They're how you build the library.
New on The Clearing This Week
The Middleman Problem
Last week's essay on how AI inserted itself between you and your own judgment — and what to do about it. One of our most-read pieces this week.
Read the full essay →AI Fatigue Severity Index
Not sure how severe your AI fatigue is? Take the 12-question severity index — built from 10,000+ engineer responses. Get a calibrated score and a personalized recommendation.
Take the severity index →Where The Clearing Community Is
Over 10,800 engineers have taken the AI Fatigue Quiz. Here's the distribution:
If you're in Tier 3 or 4: you are not broken. The system around you changed. Your instincts are still worth trusting.
"When was the last time you tracked down a bug without asking AI for help — and how did it feel?"
— Reply to this email. We read everything.