The Shift

Tools Change, Concepts Don't

In twenty years of building software, I've watched the same problems get solved over and over with different tools. The variations change -- languages, frameworks, platforms, paradigms -- but the core problems don't. How do you structure a system so it survives change? How do you make something reliable? How do you coordinate work across people and time? These are design problems. The tools are just what you use to express the answers.

I've always been pragmatic about this. Learn the concept of building a bird house and you can build one out of anything. Master woodworking without knowing what to build and you've mastered a tool with nothing to apply it to. The concepts are the valuable part. The tools serve the concepts.

AI is the latest tool. The biggest one yet. But it's still a tool -- and the same principle applies. The concepts remain. The hard parts of software development were never about typing code. They were about understanding the problem, designing the solution, making tradeoffs, and maintaining systems over time.

What AI changes is the mechanical layer. The syntax, the boilerplate, the library lookups, the ceremony of getting code to compile. That was never the valuable part. What remains unchanged is everything that requires judgment: system design, domain knowledge, tradeoff evaluation, knowing when something is wrong.

The Irony

In 1983, Lisanne Bainbridge published "Ironies of Automation." Her observation: when you automate the routine parts of a job, the operator's skills in those areas degrade from disuse. When the automation eventually fails -- and it always does -- the operator faces the hardest possible situation with the least-practiced skills (Bainbridge, 1983).

Strauch (2018) revisited this thirty-four years later and found the ironies entirely unresolved. The same pattern kept repeating across industries despite widespread awareness.

AI-assisted development is the same irony in a new domain. AI handles the routine coding -- syntax, boilerplate, debugging. Those skills degrade. When AI produces something subtly wrong, or when you need to work without it, you're facing the hardest situation with the least practice.

The Evidence

Shen and Tamkin (2026) found that developers using AI assistance scored 17% lower on mastery tests compared to those who coded by hand. The biggest gap was in debugging -- understanding when code is wrong and why.

This is exactly what Bainbridge predicted. But the mechanism goes deeper than "you lose what you don't practice."

Cognitive science has a term for this: desirable difficulties. Conditions that make learning harder in the short term -- struggling through errors, generating answers rather than reading them, testing yourself -- produce stronger long-term retention and transfer. Conditions that feel easy create what Bjork and Bjork (2020) call an "illusion of mastery" -- the learner believes they've learned, but the knowledge isn't durable.

When AI writes the code, it removes the difficulty. The struggle through errors that teaches you how things work -- that is the learning mechanism, and AI bypasses it. The code appears, it works, and it feels like you understand it. But the understanding is shallow because you didn't generate it yourself.

Shen and Tamkin's findings confirm this directly: developers who used AI to generate code and then asked follow-up questions to understand it scored just as well as those who coded by hand. The ones who delegated without engaging scored poorly.

Two different mechanisms explain the two groups. Developers who code by hand benefit from the generation effect -- producing information yourself creates stronger memory traces than receiving it passively (Goldstein, 2019). That's the desirable difficulty at work. But the developers who engaged with AI output through questions and explanations weren't generating code -- they were actively learning from it. Active engagement with material (questioning, elaborating, connecting to what you already know) produces durable encoding even when you didn't generate the material yourself. Passive reception doesn't. The developers who just accepted AI's output and moved on were passive learners -- the code appeared, they used it, and nothing stuck.

The Tradeoff That Doesn't Resolve

So there's a real tradeoff, and it doesn't have a clean answer.

Using AI means you learn less about low-level implementation. The things you learn less of -- syntax, library APIs, debugging internals -- are exactly the things AI handles for you now. The things that still matter -- system design, domain expertise, judgment -- those you still need to develop. This sounds like a clean division: let AI handle the low-level, you handle the high-level.

There's an interesting asymmetry here. The skills AI preserves -- pattern recognition, domain judgment, the ability to look at something and know it's wrong -- are the same skills that survive cognitive degradation under stress and fatigue. They're well-consolidated, deeply practiced, and procedurally encoded. The skills AI erodes -- deliberate debugging, step-by-step reasoning through unfamiliar code, generating solutions from scratch -- are the ones that degrade first when you're tired, stressed, or under pressure. AI removes practice in exactly the cognitive mode that's already most vulnerable.

But Bainbridge's warning doesn't go away just because you've reframed the division of labor. If you never practice the lower-level skills, you won't have them when you need them. And you will need them. Automation always fails eventually. The question isn't whether you'll face a situation where AI can't help -- it's whether you'll have the skills to handle it when that happens.

The debugging gap Shen and Tamkin found is the early signal. Debugging requires understanding how code actually works -- not at the level of "what does this function do" but at the level of "why is this behaving differently than expected." That understanding comes from having written code that didn't work and figuring out why. It comes from the struggle AI removes.

You can stay engaged -- question AI's output, understand what it produces, maintain the struggle artificially. But this requires discipline that works against the grain of the tool. AI's value proposition is speed. Staying engaged slows you down. The effort gradient pushes toward delegation, and the delegation erodes the skills you need to evaluate what you've delegated.

This is the tension. AI amplifies your abilities if you have them. It amplifies your gaps if you don't. And the mechanism by which you'd develop the abilities -- struggling through the hard parts -- is exactly what AI removes.

There's no resolution here. Just a tradeoff you have to manage, knowing that the comfortable path and the safe path point in different directions.

References

Bainbridge, L. (1983). Ironies of automation. Automatica, 19(6), 775--779. https://doi.org/10.1016/0005-1098(83)90046-8

Bjork, R. A., & Bjork, E. L. (2020). Desirable difficulties in theory and practice. Journal of Applied Research in Memory and Cognition, 9(4), 475--479. https://doi.org/10.1016/j.jarmac.2020.09.003

Goldstein, E. B. (2019). Cognitive psychology: Connecting mind, research, and everyday experience (5th ed.). Cengage Learning.

Shen, J. H., & Tamkin, A. (2026). How AI impacts skill formation. arXiv preprint arXiv:2601.20245. https://arxiv.org/abs/2601.20245

Strauch, B. (2018). Ironies of automation: Still unresolved after all these years. IEEE Transactions on Human-Machine Systems, 48(5), 419--433. https://doi.org/10.1109/THMS.2017.2732506