The Problem: A Generational Skills Debt Being Taken Out in Slow Motion

Something is going wrong in software engineering, and it is happening quietly enough that most people are not noticing until it is too late.

An entire cohort of developers is entering the industry during the most aggressive AI adoption period in software history. They are being told by influencers, by conference keynotes, and increasingly by their own employers that the future of engineering is orchestration, prompting, and review. Write less code. Direct more. Let the AI handle implementation. Your job now is to be the architect, the curator, the reviewer.

It sounds like a promotion. It is actually a trap.

The engineers receiving this advice are optimizing for exactly what they are being told to optimize for. They are shipping features. They are hitting deadlines. They look productive on every metric their companies measure. But underneath the output, a deficit is accumulating in what they cannot do — debug a subtle race condition, spot a security flaw buried three abstraction layers deep, make the right architectural call because they have felt the pain of the wrong one.

That reckoning comes later. In the production incident nobody can diagnose. In the rewrite that becomes necessary because nobody truly understood the system they inherited. In the security breach that a more experienced team would have caught in code review.

By then, the people who gave the advice have moved on. The influencer has a new take. The conference has a new theme. And a generation of developers is left holding a gap in their foundational knowledge with no clean way to fill it.


The Evidence: What the Research Actually Shows

The concerns above are not theoretical. In the past two years, a body of research has accumulated that gives the argument an empirical foundation. Readers who want to verify the claims in this essay do not need to take the author's word for it.

Skill atrophy is measurable, not anecdotal. In January 2026, Anthropic published a randomized controlled trial (Shen & Tamkin, arXiv 2601.20245) in which 52 junior software engineers were split into two groups to learn an unfamiliar Python library. One group had access to an AI assistant capable of generating complete solutions. The other worked with documentation only. The AI-assisted group scored 17% lower on a subsequent comprehension quiz — nearly two letter grades worse — despite finishing only marginally faster, a difference that did not reach statistical significance. Debugging skills showed the steepest decline. The researchers concluded that while AI can accelerate tasks where skills are already established, it appears to hinder their formation during acquisition. Critically, the study found that how developers used AI predicted outcomes more than whether they used it: those who delegated code generation scored below 40%, while those who used AI only for conceptual questions and coded independently scored above 65%.

The security implications are concrete. A 2024 report from Georgetown University's Center for Security and Emerging Technology evaluated code generated by five major language models and found that nearly half of all output contained bugs that were often impactful and potentially exploitable. A separate large-scale comparison of LLMs (arXiv 2404.18353) found that at least 62% of AI-generated programs were vulnerable. Veracode's analysis of 80 coding tasks across four programming languages found only 55% of AI-generated code was secure, and noted that this security failure rate has remained largely unchanged even as models have improved functionally. An analysis of over 7,700 files explicitly attributed to AI tools in public GitHub repositories identified 4,241 vulnerability instances across 77 distinct types (arXiv 2510.26103). These are not edge cases. They represent the baseline output quality of the tools that millions of developers are now treating as a ground truth.

Industry sentiment is shifting, and experienced engineers are driving it. The Stack Overflow 2025 Developer Survey, drawing on nearly 49,000 respondents, found that developer trust in AI output dropped from 43% in 2024 to 33% in 2025. Active distrust rose from 31% to 46%. Experienced developers showed the highest skepticism — and the data shows why: they have the implementation depth to recognize when AI output is wrong in ways that are not immediately obvious. The Techreviewer 2025 global survey found that skill atrophy and junior developer over-reliance on AI are now cited as mainstream strategic concerns by organizations, not fringe ones.

The labor market is already reacting. Stanford University payroll data tracking millions of workers found that employment for software developers aged 22 to 25 has fallen nearly 20% since late 2022 — a decline that coincides precisely with the mainstream adoption of AI coding tools. Employment for developers over 26 has held steady or grown over the same period. Companies are not simply replacing junior developers with AI. They are eliminating the positions that were traditionally the proving ground where foundational skills were built.

None of this evidence resolves every question. The Anthropic study measured immediate comprehension, not long-term career outcomes. The security studies capture output quality at a point in time. Causality is always harder to establish than correlation. But the pattern across independent sources points consistently in one direction: the costs of passive AI use are real, they are already being measured, and they fall disproportionately on developers who are early in their careers.


What Is Actually Being Lost

To understand the danger, you have to understand what deep engineering knowledge actually is and how it is built.

It is not a collection of facts you can look up. It is closer to athletic conditioning — a set of finely calibrated instincts built through sustained, effortful repetition over years. When an experienced engineer reviews code, they are not consciously running through a checklist. They feel something is wrong before they can articulate why. That sense — that pattern recognition — is built by writing code, debugging it when it breaks, reasoning through why it breaks, and repeating that cycle thousands of times.