Careers When the Junior Work Is Automated

Entry-level developer postings dropped roughly 60% between 2022 and 2024. Entry-level employment for people aged 22 to 25 fell around 16% in the fields most exposed to AI. Senior engineers at Microsoft, including Mark Russinovich and Scott Hanselman, have publicly warned that the junior pipeline is being hollowed out.

Now put that next to a number that hasn't changed: it takes somewhere between five and nine years to grow a graduate into a genuine senior engineer.

Stop hiring juniors for three years and you haven't saved money. You've scheduled a senior shortage for five to ten years out, and you've scheduled it for an industry that will still need seniors, because the one thing AI has unambiguously increased demand for is people who can evaluate whether generated work is correct.

The training vanished, the exam stayed

Here's the mechanism, and it's worth stating precisely because it's easy to get wrong.

Juniors never learned primarily from being taught. They learned from doing the unglamorous work: the small bug fix that forced them to read an unfamiliar module, the boilerplate that taught them the codebase's conventions by repetition, the tedious refactor that revealed why the architecture was shaped that way. That work was economically marginal, which is exactly why it was safe to hand to someone junior.

That work is now the work AI does best.

The uncomfortable framing that's been circulating in the field: automation deleted the curriculum and kept the exam. We removed the tasks people learned from and left intact the expectation that they arrive competent. Meanwhile the junior's actual job has shifted to reviewing, validating, and integrating AI-generated work, which is a harder skill than writing the original code was. Judgment is what you develop last, and we've made it the entry requirement.

Why this lands on you and not on HR

It's tempting to file this under industry trends, or hiring policy, or somebody else's problem. Two reasons it isn't.

The pipeline is a local decision. Some large enterprises have quietly increased junior hiring precisely because they did this arithmetic and concluded future seniors have to come from somewhere. Others cut. Both are choices being made by engineering leaders about their own teams, and the consequences land on whoever is running the team in five years.

Nobody else can fix the learning part. Even organizations that keep hiring juniors have to answer a question their old apprenticeship model answered automatically: if the entry-level work is gone, how does anyone actually develop judgment now? That's a management design problem. It won't be solved by a hiring requisition.

What the alternative looks like

The most promising model being tried, including in proposals from Microsoft, is essentially a preceptorship: pair an early-career engineer directly with an experienced one on real production work, and have them use AI tools together, with the senior watching how the junior works.

The critical detail is what the senior is watching for. Not whether the code is right. Whether the junior's evaluation is right. What did they accept, what did they reject, and why? Where did their understanding quietly break down while the output still looked plausible?

That's a fundamentally different mentoring activity than reviewing a finished pull request, and it maps directly onto the delegation material earlier in this curriculum. You're not delegating a task. You're building the judgment that lets someone eventually be delegated to.

There's a genuinely encouraging finding alongside this. IBM's research suggests juniors may benefit more from AI tools than seniors do, in both productivity and learning velocity, provided they get proper guidance. The technology isn't inherently hostile to developing people. Unsupervised use is. The variable, again, is whether a leader designed the situation.

The self-interested case, for whoever needs it

If the developmental argument doesn't move your organization, the operational one might.

Teams composed entirely of seniors have a specific pathology: nobody asks the naive question. Juniors surface the assumptions everyone else stopped noticing, and in an AI-assisted codebase, unexamined assumptions are exactly what accumulates. Senior engineers also develop most through teaching. Explaining an architectural decision forces you to actually understand it, which is why removing juniors quietly stops seniors growing too.

And there's the hiring math. If the whole industry under-invests in juniors for several years, seniors get scarcer and more expensive at exactly the moment demand for judgment peaks. Being one of the few organizations that still knows how to grow them stops being a cost centre and starts being a considerable advantage.