Three years in. Competent, shipping, well-regarded by the team.
Then the AI tool was unavailable for a day, and a pipeline timeout that should have been routine turned into most of an afternoon. Not because the problem was hard. Because the approach to it was never built.
This is worth taking seriously and worth being careful about, because it is easy to turn into a moral complaint about people who use tools. It isn't that. It's a specific claim about how a specific skill forms, and what happens when the conditions that form it stop occurring.
🔍 What debugging intuition actually is
When an experienced engineer looks at an intermittent pipeline timeout, they don't start from nothing. They start from a ranked list: what usually causes this, what's changed recently, what would explain the intermittency specifically rather than a constant failure.
That list isn't knowledge in the sense of facts they could recite. It's compressed experience. It came from having been wrong about this class of problem enough times that the wrong answers got pruned.
The same thing applies to a silent data quality failure, which is a harder case: no error, no alert, wrong numbers found weeks later by someone in finance. There's no stack trace to paste. The starting question is "where could this have gone wrong without anything complaining," and that question only has a useful answer if you've built a mental model of where your systems fail quietly.
Neither of these is knowledge you can look up. Both are built the same way, and the way they're built matters for what follows.
🧠 Why this is about cohort, not seniority
Research on deliberate practice is consistent on the core mechanism: skills develop through repeated performance with feedback, targeted at things you're currently bad at. Struggle alone doesn't do it, and comfortable repetition doesn't either. You need the attempt, the outcome, and the correction.
Debugging used to supply all three whether you wanted them or not. You formed a hypothesis, you were wrong, you found out you were wrong, you formed a better one. Nobody designed that as a training programme. It was just what debugging was.
An engineer who worked that way for five years before these tools existed has the resulting instinct, and now uses AI on top of it. The tool makes them faster at something they can already do.
An engineer whose entire career has been AI-assisted may not have had those cycles. Not through any choice, and not through working less hard. The hypothesis-and-correction loop simply didn't occur, because the answer arrived before the hypothesis was needed.
That's why this is a cohort effect rather than a seniority one. It doesn't track years on a CV. It tracks how many times you were wrong about something and had to find out why.
Worth noting: the productivity research points the same direction. In a controlled study, developers using Copilot completed a task around 56% faster, with larger gains for less experienced participants. The people helped most are the people whose skills are still forming. That's genuinely good, and it's also exactly where the loop matters most.
✅ The unassisted-first window
The recommendation is small and deliberately limited.
Pick one non-urgent bug per week. Spend a fixed amount of time on it unassisted before reaching for anything.
Three details that make this work rather than just cost you time:
Non-urgent only. This is practice, not principle. If production is down, use every tool available. Nobody benefits from you being slow during an incident.
Fixed and short. Thirty minutes. Set a timer. The point is the attempt, not the completion, and an open-ended commitment gets abandoned within a fortnight.
Check your answer afterwards. This is the part people drop, and it's the part the research says is essential. Deliberate practice requires feedback. After your thirty minutes, whether you solved it or not, ask the AI and compare. The gap between your hypothesis and the actual answer is the whole lesson. Struggling without ever finding out if you were right builds nothing.
Thirty minutes a week is roughly one percent of your working time. That's the price, and it's low enough that the honest cost-benefit argument doesn't really apply.
⚖️ The objection worth taking seriously
Here is the strongest version, and it deserves a real answer rather than a dismissal:
We don't hand-optimise assembly any more, and nobody laments the lost skill. Compilers made it unnecessary, the profession moved up a level, and that was straightforwardly good. Maybe debugging intuition is the same, and preserving it is nostalgia rather than engineering.
That's a serious argument and I think it's partly right. Some of what we currently call debugging skill will look like assembly optimisation in ten years, and time spent preserving it will have been wasted. I can't tell you which parts.
The distinction I'd draw is this. Assembly stopped appearing in the work. You don't encounter it, so not knowing it costs you nothing. Debugging hasn't disappeared. The systems still fail, and a meaningful share of failures are novel: undocumented interactions, a vendor behaving unexpectedly, a silent data corruption with no error attached. Those still require someone to reason from symptoms to cause in a system nobody has written about.
If that changes, this advice expires and it should. Until then, the thing being preserved isn't the manual labour. It's the ability to form a hypothesis about a system you don't fully understand, which is a more general skill than debugging and shows up in design, incident response, and architecture too.
One more honest note: the evidence here is thinner than I'd like. Developers report concern about deskilling in surveys, and the deliberate practice research is solid on how skills form. But I'm not aware of a study that directly measures debugging capability in AI-assisted cohorts against unassisted ones. The mechanism is well-supported. The specific outcome is reasoning, not measurement, and you should weigh it accordingly.
🎯 The takeaway
One non-urgent bug per week. Thirty minutes unassisted. Then check your answer.
The checking is not optional. Practice without feedback isn't practice, it's just slower work.
You're not protecting a craft. You're maintaining the ability to reason about a system nobody has documented, which is still, for now, a thing the job requires.
This is post #5 in a series on AI practice for data engineers. Next up: **Using AI Without Deskilling.**
Top comments (0)