AI Ate the Apprenticeship

There is a specific kind of quiet failure that is hard to see in real time. It does not show up in your sprint velocity. It does not trigger an alert in your observability stack. It emerges slowly, over quarters, when the developers who joined your team eighteen months ago still cannot reason about asynchronous code without reaching for a prompt box first.

In February 2026, Anthropic published research that put a number on something many of us have been sensing: developers who used AI assistance while learning a new coding library scored 17% lower on comprehension tests than those who worked through the material manually. The study was tightly controlled — 52 mostly junior software engineers, each with at least a year of weekly Python experience, all learning Trio (a Python async library none of them had encountered before), split into AI-assisted and non-assisted groups. The tasks were real. The quiz afterward measured debugging, code reading, and conceptual understanding. The gap was not subtle.

The researchers’ own framing deserves quoting directly: “It is possible that AI both accelerates productivity on well-developed skills and hinders the acquisition of new ones.” That sentence is doing a lot of work. Read it again.

The same tool, two different outcomes

The distinction the Anthropic team draws is the crux of the whole debate. If you are a senior engineer who already understands concurrency, event loops, and the failure modes of async code, an AI assistant is a force multiplier. You are outsourcing typing, not thinking. You can spot when the generated code is wrong, and you know what question to ask next. The model is a very fast intern who does exactly what you say — and you happen to be good at saying the right things.

But if you are a junior engineer who has never wrestled with async race conditions at 2 am, who has not yet built the mental model through pain and repetition, the AI assistant does something different. It removes the very friction that would have built that model. You get working code. You do not get understanding. And when something breaks in production — as async code reliably does — you are left with a result you cannot reason about.

The same study makes this concrete. Developers who used AI to ask conceptual questions scored 65% or higher on comprehension. Those who delegated code generation to the model scored below 40%. The tool is identical. The way you engage with it makes all the difference — and junior engineers, almost by definition, do not yet know what they do not know.

The pipeline problem nobody is solving

Managing a team of over eighty .NET developers, this is not an abstract research concern. It is a staffing and craft question I think about constantly.

Closer to home, the numbers are just as pointed. Agoria reported over 5,000 tech jobs cut in Belgium in the first nine months of 2024 — the highest loss in twelve years — while the ICT sector simultaneously maintained a vacancy rate of nearly 5% for senior and specialist profiles it could not fill. The sector shed the roles it could automate or consolidate, while keeping the ones it could not. In February 2026, Agoria’s own AI Skill Shift report named the junior pipeline as a critical vulnerability, calling for a fundamental rethink of how entry-level talent is trained and onboarded. The problem has a name now, but no clear owner.

The shape of that problem matters. Entry-level roles compressed first, not because junior developers became less valuable in any absolute sense, but because AI absorbed the apprenticeship tasks — boilerplate generation, basic scaffolding, routine documentation — that used to be how junior developers earned their way into harder problems. Without those tasks, the path from graduate to capable mid-level engineer is shorter on the surface and hollower underneath.

The cohort currently developing their skills under AI guidance will become our mid-level engineers in 2027 and our seniors by 2031. If that cohort has structural gaps in their ability to reason through unfamiliar problems, we hit a capability cliff precisely when we need reliable senior judgment most. Stack Overflow’s 2025 Developer Survey found that 84% of developers now use AI tools during development. AI tool trust, however, is at an all-time low. Developers have used the tools long enough to sense that something is off, but the daily output keeps looking fine, which makes the problem easy to defer and hard to name until it is too late.

What this means in practice

The practical implication is not complicated, even if it is uncomfortable. In the early stages of learning something unfamiliar — a new framework, an architectural pattern, a part of the stack a developer has not touched — the friction is the lesson. An AI that removes that friction too early is not helping the developer; it is borrowing against their future capability. Which means the task for anyone managing or coaching developers right now is to be deliberate about when AI enters the learning loop, and to test comprehension separately from output. A developer who produces working code with AI assistance and a developer who understands that code are not interchangeable — and treating them as if they are is how the capability cliff gets built, one sprint at a time.

Across the teams I work with, the pattern is consistent: hiring for engineers with less than a year of experience has quietly stopped. Not because junior developers lack value, but because the market stopped asking for them. Clients want engineers who can reason independently, and right now, that signal arrives with a seniority floor attached. The commercial reality has made the decision for them. What that means for the pipeline, though, is that the problem moves upstream. If teams like these are not onboarding juniors, schools become the last place where proper foundations can be built.

Where the fix has to start

That is why I have been talking to curriculum leads at several Belgian universities and colleges about how AI tooling gets introduced in their programmes. My position is straightforward: AI should be in the classroom, but the way it is used needs to be governed by a formal requirement. A student should be able to explain every line of code they submit — what it does, and why it is written the way it is, not as a vague aspiration, but as an assessment criterion. If a student cannot do that, the code does not count. That single requirement forces a different relationship with the tool. You stop using it to skip the thinking and start using it to support the thinking.

The answer is not to pull the tools away. The productivity gains on established skills are real, and the tooling is not going anywhere. What it demands is a deliberate approach to when AI enters the learning loop — and a willingness to hold the line on comprehension even when output looks fine.

The craft of asking good questions also has to be explicitly taught. The developers in the Anthropic study who scored well were using AI for conceptual clarification, not code generation. That is a skill in itself — knowing when to ask “explain this to me” versus “write this for me.” Right now, most teams are not teaching it. They are handing over the tools and hoping comprehension follows from output. The research says it does not.

The question I keep returning to: are we building engineers who can think, or engineers who can prompt? The answer will shape the industry — and not in two or three years. In ten.

AI Ate the Apprenticeship

The same tool, two different outcomes

The pipeline problem nobody is solving

What this means in practice

Where the fix has to start

Sources

AI Ate the Apprenticeship

You Don’t Have a Coding Problem. You Have an Engineering Problem.

The Developer Skill That AI Can’t Fake

Stay in the loop.