Using AI coding tools without letting your skills atrophy
Published 2026-05-18 by Owner
Anthropic’s own study found a 47% drop in debugging skill among its heaviest AI users. This is the practical companion to The supervision paradox: not whether to use agents, but how to use them daily without dulling the judgment that makes them safe to use.
Know where the erosion happens first
The decay is not uniform. Three skills go before the others, and naming them tells you where to spend effort:
- Debugging an unfamiliar failure. The Anthropic number names this one explicitly. It goes first because it is the easiest to hand off — the agent is genuinely good at it, so you stop doing it without noticing you stopped.
- Architectural judgment. Deciding what shape a change should take. Agents propose a shape; if you only ever react to their proposal, you stop generating your own, and reacting is a weaker skill than generating.
- Reading unfamiliar code. Fluency at holding a strange codebase in your head decays when the agent always summarizes it for you. The summary is usually right, which is exactly why the skill rots quietly.
Reserve a no-delegation category
Pick one category of work the agent never does, chosen to match the skill you most want to keep. For most engineers that is the first pass on a confusing bug — the skill the data says goes first.
The rule has to be categorical, not situational. “I’ll debug it myself when I have time” collapses under deadline pressure every single time, because there is always a deadline and the agent is always faster this afternoon. “The agent does not get the first debugging pass” survives, because there is nothing to negotiate in the moment. A rule you re-decide under pressure is not a rule.
Read before you accept — as practice, not process
Read every diff you apply, line by line, before it lands. The framing matters more than it sounds: this is not a compliance step, it is the cheapest deliberate practice available to you. You are reading correct, idiomatic, working code written to solve a problem you already understand. That is close to an ideal training set, and it is free every time you would otherwise have rubber-stamped it.
Concretely: open the full diff, not the summary. Predict what the next hunk will do before you scroll to it. When the diff surprises you, stop and work out why before applying it — the surprise is the entire lesson, and skimming past it is the moment the practice value evaporates.
Schedule unaided work
Keep one recurring slot — a few hours a week, or one task per sprint — where you write without an agent. Not because the unaided code is better; it usually is not, and that is the point. The slot is a measurement instrument, not a productivity tactic. If unaided work has become painful in a way it was not six months ago, that is the atrophy showing up while it is still cheap to reverse. Catching it at “uncomfortable” is much cheaper than catching it at “I can no longer do this.”
Do not let juniors skip the rung
The team-level version is sharper, and it is the one worth arguing about in planning. A senior engineer with ten years of debugging behind them can lean on agents and coast on existing skill for a while — they have a reservoir to draw down. A junior who starts on agent-first workflows never fills the reservoir in the first place. There is nothing to draw down, and the gap does not show until something breaks that the agent cannot fix and neither can they.
If you lead a team: give junior engineers a protected category of unaided work, and review that work as deliberately as you review their agent-assisted output. The goal is not slower onboarding for its own sake. It is making sure the person who will be supervising agents in three years has the judgment that supervision requires — because by then the agents will be better, the temptation to defer will be stronger, and the paradox will not have gone away. It will have moved up the seniority ladder.
