AI Is Quietly Collapsing the Junior Engineer Pipeline
Entry-level engineering roles have dropped significantly since AI tool adoption accelerated. Most engineering leaders are not paying attention to this. They should be.
Entry-level software engineering roles dropped by roughly 60% between 2022 and 2024. That is not a hiring slowdown. It is a structural shift, and it is accelerating.
The reason is straightforward: the work that used to be done by junior engineers is increasingly being done by AI tools. Boilerplate code, simple feature additions, test scaffolding, bug fixes with clear diagnostic information, documentation. These were the tasks that gave junior engineers the repetitions they needed to become senior engineers. Those repetitions are evaporating.
Most engineering leaders I speak with are aware of this as a trend. Far fewer have thought through what it means for their organisation in five years. A team that stops hiring junior engineers today will face a senior engineer shortage by 2030, because today's juniors are tomorrow's seniors. The pipeline runs on lead time that most leadership teams are not accounting for.
What Junior Engineers Were Actually For
There is a common way of thinking about junior engineers that frames them primarily as a cost-saving mechanism: lower-cost labour for lower-complexity work, with the expectation they will grow into higher-complexity work over time.
That framing is both accurate and incomplete. Junior engineers were not just cheaper capacity. They were the mechanism by which organisations renewed their senior engineering capability over time. The tasks they worked on were not just tasks to be completed. They were the training ground where engineers developed the pattern recognition, debugging instincts, and system intuition that define senior capability.
The critical thing about that training is that it cannot be shortcut. A senior engineer with ten years of experience has encountered hundreds of failure modes, debugged hundreds of production issues, made hundreds of architectural decisions and seen which ones held up. That accumulated experience is not transferable by explanation. It is built through doing.
When AI tools absorb the work that builds that experience, the question is not just "who will do the junior work." The question is "how will the next generation of senior engineers develop." That is a harder problem, and most organisations are not yet grappling with it.
The Harvard Data Is Not Ambiguous
A Harvard study published in 2025 found that junior developer employment drops approximately 10% within six quarters of significant AI adoption at a company, while senior employment remains largely stable.
The mechanism is not mysterious. Senior engineers are the ones making decisions about AI tool adoption. They are the ones who can evaluate AI-generated output accurately. They are the ones whose productivity is directly amplified by AI tools because they have the context to direct the tools effectively. Junior engineers lack that context. The tools do not reduce their value by making them faster. The tools reduce their value by absorbing the tasks they were hired to do.
Salesforce's announcement in 2025 that they would stop hiring new software engineers is one of the more visible signals of this dynamic. It is not an isolated decision. Across the companies I have seen adopt AI tools aggressively, the pattern is consistent: headcount decisions increasingly favour senior engineers with demonstrated ability to work effectively with AI tools, at the expense of entry-level roles.
This makes sense in the short term. Senior engineers are more immediately productive, and AI tools amplify that productivity. It creates a structural problem in the medium term that most organisations are not yet modelling.
The Deskilling Risk Is Real and Underappreciated
There is a second-order problem that receives less attention: the deskilling of engineers who learned their craft in the vibe coding era.
Engineers who join organisations where AI tools do the hard work of problem decomposition, debugging, and implementation from day one develop a different capability profile than engineers who did those things manually first. They become effective at directing AI tools, reviewing output, and integrating generated code. They become less effective at the underlying engineering work: reading and understanding a complex system without AI mediation, debugging a problem without a model to generate hypotheses, designing an architecture from first principles.
This is not a critique of AI-native development. It is an observation about skill development. The engineers building the AI tools that everyone is relying on spent years developing deep capability without those tools. The engineers directing those tools without building the underlying capability are in a different position, and the gap will surface in the situations where the tools fail or are unavailable.
The situations where the tools fail are exactly the high-stakes ones: production outages, complex debugging, architectural decisions under uncertainty. These require the kind of deep engineering intuition that has historically been built through deliberate difficulty.
What Good Organisations Are Doing Differently
The organisations navigating this well are not the ones that have stopped hiring junior engineers. They are the ones that have redesigned what junior engineering means in an AI-native context.
Pairing junior engineers with AI tools for acceleration, not replacement. The model that is emerging in the more thoughtful organisations uses AI tools to accelerate junior engineer learning rather than absorb their work. A junior engineer who uses Claude Code to explore an unfamiliar codebase, generate hypotheses about a bug, or prototype three different approaches to a design problem is developing faster than one doing the same work entirely manually, but is still doing the cognitive work of evaluation, decision-making, and verification. That is the training that matters.
Structured review as a learning mechanism. Code review is one of the highest-leverage learning experiences available to a junior engineer. Being the reviewer of AI-generated code at scale is a version of this, but only if the review is rigorous and mentored. Organisations that have introduced a structured apprenticeship model for reviewing AI-generated code, where junior engineers review with a senior engineer alongside them in the early stages, are building capability that the pure efficiency optimisation model does not.
Deliberate difficulty, by design. The most effective organisations at developing junior engineers in the AI era are the ones that have identified specific problem types where junior engineers work without AI assistance. Not as a punishment, and not as a nostalgia exercise. As a deliberate investment in the cognitive capability that AI tools cannot substitute for. The parallel is physical training: you do not avoid difficulty because the machine can do it faster. You embrace difficulty because the difficulty is the point.
Longer hiring horizons. A small number of organisations have started modelling their senior engineering needs out five to seven years and setting junior hiring targets based on that model rather than current headcount efficiency. This is harder to justify in a quarterly-oriented planning process. It is also the only way to avoid the senior shortage that the current trend is creating.
The Leadership Decision Most Teams Are Not Making
The most common leadership response to the junior pipeline problem is to defer it. There is no immediate crisis. The senior engineers are productive. The teams are hitting their targets. The problem is five years away, which means it is someone else's problem.
This is the wrong frame. The lead time for developing a senior engineer is five to seven years. The decision to invest or not invest in the junior pipeline is a decision about your engineering capability in 2030 and 2031. By the time the shortage is visible, the window to address it with pipeline investment has already closed. The only option at that point is external hiring in a market where everyone else is trying to solve the same problem simultaneously.
The organisations that will be best positioned are the ones making that investment now, before it is obviously necessary. That requires modelling the pipeline explicitly, setting hiring targets that reflect long-term needs rather than current efficiency, and redesigning the junior engineer experience for an AI-native context rather than either eliminating it or pretending nothing has changed.
Neither extreme is the answer. Eliminating junior engineering roles optimises for the next two years at the expense of the next decade. Pretending the role is unchanged ignores a genuine shift in what junior engineers need to develop and how. The path that works requires actually thinking through the problem and committing to a deliberate approach before the urgency forces a reactive one.
The engineering leaders who will look smart about this in 2030 are the ones who started thinking about it in 2025 and 2026. Most are not there yet. The window is still open.
I help engineering teams close the gap between "we use AI tools" and "AI actually changed how we deliver." Book a 20-minute call and I'll tell you where the leverage is.
Working on something similar?
I work with founders and engineering leaders who want to close the gap between what their technology can do and what it's actually delivering.