Over the years leading engineering teams, I have watched engineers become senior in a fairly unglamorous way.
They fix bugs. They misunderstand systems. They get things wrong in code reviews. They debug production incidents. They discover that a perfectly reasonable design falls apart when it meets reality.
Eventually, something changes.
They stop merely knowing how to build something and start knowing what to question.
That distinction has been on my mind as AI gets dramatically better at software development.
The question is not simply whether AI will reduce the number of junior engineering jobs. We don't have enough evidence to make that claim universally.
The question I find more interesting is this:
If AI removes much of the work through which engineers historically developed judgment, what replaces the apprenticeship?
The labor-market signal is worth watching
The evidence is evolving, and causality is contested.
In an August 2026 revision of a working paper using payroll data from millions of US workers at ADP client firms, Stanford's Digital Economy Lab reported that employment among 22–25-year-olds in highly AI-exposed occupations (including, but not limited to, software development) was about 19% below where it would have been had it kept pace with less-exposed occupations. The divergence appears primarily in hiring rather than layoffs. The researchers are equally clear that they do not see widespread economy-wide displacement.
Other research is less convinced that AI is driving even the changes we are seeing. The Budget Lab at Yale, working with Brookings researchers, has found no clear relationship so far between AI exposure and changes in employment or unemployment at the broader labor-market level.
And geography matters. India's technology labor market, for example, still has large fresher-hiring pipelines through IT services firms, while global capability centers are becoming increasingly important campus recruiters. The path may therefore look quite different outside the US.
So I would not describe the junior pipeline as already collapsing.
But I do think there is enough signal for engineering leaders to ask whether short-term headcount economics could eventually collide with long-term talent development.
Productivity and learning are not the same thing
This is where the problem becomes more interesting.
A peer-reviewed Management Science study combined three randomized field experiments covering 4,867 developers at Microsoft, Accenture and a Fortune 100 company. Developers given an AI coding assistant completed roughly a quarter more tasks, although the estimate was noisy. More importantly, less-experienced developers experienced larger productivity gains. Two of the study's six authors were Microsoft researchers, and the experiments evaluated GitHub Copilot, a Microsoft-owned product.
That challenges the simplistic idea that AI primarily benefits senior engineers.
But another experiment exposes the other side of the equation.
Anthropic's own researchers ran a randomized trial with 52 mostly junior software engineers learning an unfamiliar Python library. The AI-assisted group completed the exercise slightly faster, although not by a statistically significant amount. Immediately afterwards, however, they averaged 50% on a comprehension and debugging assessment versus 67% for engineers who coded manually. The largest gap was in debugging.
This was a small, short-horizon experiment conducted by an AI vendor. It tells us nothing yet about what happens over months or years.
But it highlights a distinction I think organizations should take seriously:
AI may raise an engineer's productivity faster than it raises their capability.
Those two curves are easy to confuse.
The same Anthropic study also suggests this outcome isn't inevitable. Participants who used AI to ask conceptual questions, request explanations and build understanding tended to score markedly higher. That was an observed pattern rather than a randomized comparison.
The problem may not be AI use.
It may be cognitive delegation without learning design.
Junior work was an accidental apprenticeship
I don't romanticize grunt work.
Nobody needs to preserve boilerplate coding because previous generations suffered through it.
But I think we have underestimated what some of that work was doing.
A junior engineer fixing a seemingly trivial production bug might have had to trace a request across services, understand a deployment pipeline, read unfamiliar code, interpret logs and discover why an architectural decision had been made three years earlier.
The ticket might take two days when a senior engineer could solve it in twenty minutes.
Measured purely as delivery efficiency, that looks terrible.
Measured as capability building, it looks very different.
The old model was inefficient and inconsistent. But everyday engineering work repeatedly exposed people to the systems from which judgment eventually emerged.
If AI compresses that journey into “describe problem → receive solution → validate tests → merge,” we shouldn't assume the missing experience reconstructs itself later.
The scarce skill may move from creation to judgment
As generating an implementation becomes cheaper, deciding whether it is actually correct becomes relatively more important.
I've seen this throughout my career even without AI. The hardest engineering conversations are rarely about syntax. They are about assumptions, failure modes, trade-offs, operational consequences and whether we're solving the right problem.
AI magnifies that distinction.
And even its productivity benefits depend heavily on context.
METR, an independent research nonprofit, initially ran an RCT with 16 experienced open-source developers working in mature repositories they knew well. With early-2025 AI tools, those developers were 19% slower, despite believing AI was making them faster.
Its subsequent experiment, involving 57 developers and more than 800 tasks, produced smaller negative estimates that were statistically indistinguishable from zero. But METR itself considers that evidence unreliable because developers increasingly declined tasks when they could not use AI, creating substantial selection effects. It has since redesigned its experiments.
The lesson isn't that AI makes juniors faster and seniors slower.
It is that code-generation speed is an increasingly poor proxy for engineering capability.
So how do we build that capability?
Microsoft leaders Mark Russinovich and Scott Hanselman have proposed borrowing an idea from medicine: preceptorship. Russinovich is Microsoft's Azure CTO; Hanselman is Microsoft's Vice President of Developer Community. Their model is a proposal, not a proven software-engineering intervention.
The idea is to pair early-career engineers deliberately with experienced engineers while they use AI. The senior's job becomes less about supplying answers and more about examining reasoning: Why did you decompose the problem this way? What did the agent assume? Why do you trust the result? What would failure look like?
I don't know whether that particular model will scale.
But I think the principle is right.
Engineering organizations can no longer assume talent development will remain an automatic by-product of delivery.
I would make three changes.
First, treat junior hiring partly as succession planning, not simply near-term capacity.
Second, evaluate early-career engineers not only on how much they ship, but on whether their system understanding, debugging ability and technical judgment are improving.
Third, make developing other engineers a real expectation of senior technical leadership rather than invisible work performed by the conscientious few.
None of this means keeping engineers artificially inefficient.
It means being deliberate about which friction AI should remove, and which friction was actually doing valuable educational work.
The risk is not that juniors disappear
Perhaps AI-native engineers will develop judgment faster than previous generations.
Perhaps agent orchestration, evaluation, observability and system-level reasoning will become better apprenticeships than writing boilerplate ever was.
I hope they do.
But that outcome isn't automatic.
For most of my career, we could largely rely on the work itself to help turn junior engineers into senior ones.
AI is removing parts of that mechanism before we have designed its replacement.
That, rather than the disappearance of junior engineering, is the risk technology leaders should be paying attention to.
Because producing code may increasingly be easy.
Producing the people capable of knowing when that code is wrong may become much harder.