Delegation Without Atrophy

Anthropic — a company whose revenue depends on you using AI coding tools — published a randomized controlled trial this year showing those tools can hurt developer learning. In the study, 52 professional developers learned a new library either with AI assistance or without. The AI-assisted group scored 17% lower on comprehension tests, with debugging skills taking the biggest hit.

I keep hearing two bad responses to findings like this. The first: "See? Ban the tools, real engineers write their own code." The second: "Comprehension doesn't matter anymore; the agent comprehends for you." Both are wrong, and both dodge the actual leadership problem: you are now managing a workforce whose core skills can quietly decay while their output goes up.

Why this is a management problem, not a tooling debate

The scary part of the study isn't the 17%. It's which skills degraded most: debugging, code reading, conceptual understanding. Those are precisely the skills your whole agent workflow depends on. The agent writes; humans verify. Verification is reading, judging, and debugging. So heavy, careless AI use erodes exactly the capability that makes heavy AI use safe. That's a feedback loop with one stable endpoint: a team that ships code nobody on the team could fix at 2 a.m.

If that sounds theoretical, run this drill: pick a service your team shipped last quarter with substantial agent involvement, take away the AI tools, and ask an engineer to walk you through why a specific function works the way it does. I've watched this go badly. Not because anyone is lazy — because comprehension was never load-bearing during development, so it never got built.

The parallel that helps me think about it: aviation. Autopilot made flying safer and created a documented problem of manual-flying skill decay — which is why airlines mandate hand-flying practice and simulator time. They didn't ban autopilot. They stopped assuming skills maintain themselves.

What deliberate practice looks like on an engineering team

The Anthropic study's most useful finding was that outcomes depended less on whether AI was used and more on how. Developers who interrogated the output — asked why, requested explanations, challenged approaches — retained far more than those who accepted and moved on. That's a coachable behavior, which means it's your job. Here's what I'd actually implement:

Make debugging a human-first activity. When production breaks on agent-written code, the on-call engineer forms their own hypothesis before asking an agent to investigate. Use AI to accelerate the search, not to replace the diagnostic reasoning. Debugging is where the study showed the worst decay, and it's also the skill you can least afford to lose — so it's where you protect the reps.

Institute teach-backs on significant merges. For any substantial agent-authored change, the sponsoring engineer explains it to a teammate — design choices, tradeoffs, where it would break under load — without the diff open. Fifteen minutes. If they can't do it, the review wasn't real, and better to learn that in a conference room than an incident channel. This one practice converts "I skimmed it and the tests passed" into actual comprehension, because everyone knows the teach-back is coming.

Keep some work hand-built on purpose. Not arbitrary "no-AI Fridays" — targeted reps. New library the team will depend on? First integration gets written by hand, because that's where the learning compounds. Novel algorithmic core of the product? Hand-built, agent-reviewed, not the reverse. I'd spend maybe 10-15% of the team's coding time here. Call it what it is: training budget that happens to produce code.

Watch for the tell in code review. Review comments are your atrophy dashboard. When an engineer's comments shift from "this locking approach will deadlock under X" to "LGTM, tests pass," comprehension is going soft. That's a 1:1 conversation, the same as any other skill regression — caught early it's a nudge, caught late it's a performance problem.

The uncomfortable budget conversation

All of this costs throughput. Teach-backs, hand-built integrations, human-first debugging — each one is slower than letting the agent rip. I think you should pay it anyway, and say so explicitly, because the alternative cost is deferred and compounding: a team that's fast today and helpless the day the agent's output is subtly wrong in a domain nobody understands anymore. You already accept this logic for tests and documentation. Skill maintenance is the same category — invisible when healthy, catastrophic when neglected.

Takeaway: AI delegation and skill decay come from the same behavior — accepting output without interrogating it. So manage the behavior: protect debugging reps, require teach-backs on big agent-authored merges, keep strategically chosen work hand-built, and read code review comments as your early-warning system. The teams that win this era won't be the ones using AI most — they'll be the ones still capable of doing the job when it matters, precisely because they delegated deliberately.