Now booking enterprise content platform builds for 2026. Contact us

All articles Practice 7 min read

The end of junior devs? Why AI makes mentorship more important, not less

Junior hiring has been falling since AI coding tools went mainstream. That logic optimises for current output while quietly eliminating the senior pipeline.


Junior developer hiring has been falling since AI coding tools went mainstream, and some companies have cut entry-level roles entirely. The reasoning looks clean: if AI handles the boilerplate and small-scope tickets that used to keep juniors busy, why pay someone to do it slower?

That reasoning conflates two different things. AI replaces a lot of what juniors used to do day-to-day, but it does not replace the reason you hired them in the first place.

The pipeline nobody is tracking

Mark Russinovich (Microsoft’s Azure CTO) and Scott Hanselman (VP of Developer Community) laid out the argument in an essay on the software engineering profession, drawing on what economists have called “seniority-biased technological change.” Experienced engineers get measurably more productive; early-career developers, still building the systems intuition needed to direct agents and catch their mistakes, often get slower. The authors call this gap “AI drag.” The economic logic is straightforward: keep the engineers whose output is multiplying, stop bringing in people who can’t yet direct the tools effectively.

That approach may optimise short-term output while creating a long-term pipeline problem.

The Harvard numbers tell the story. Employment of 22-25 year olds in AI-exposed jobs fell roughly 13% after GPT-4’s release, even as senior roles grew. The Stanford Digital Economy Study, cited by Stack Overflow, puts the broader decline for software developers in that age range at close to 20% from its 2022 peak. Senior engineers are more productive than ever, and nobody is measuring what happens to the team when they eventually leave. A company that stops hiring juniors today has no mid-level pipeline in three years and no senior pipeline in seven. That is a staffing math problem dressed up as a technology decision.

What mentorship is

A common reading of this situation gets the problem right but draws the wrong conclusion. AI handles the tasks juniors used to own, but those tasks were the training ground, not the end goal.

Russinovich and Hanselman propose a preceptorship model borrowed from medical education. The idea is specific. A senior engineer doesn’t just answer questions; they observe how a junior interacts with AI tools. What does the junior accept without questioning? Where does their reasoning break down? The senior’s role shifts from “person who writes code” to “person who teaches judgment.”

Their paper has a concrete example that’s hard to dismiss. An AI agent inserted a sleep() call to patch what was a race condition. The code compiled, the tests passed, and to anyone without deep knowledge of synchronisation primitives, it looked like the problem was solved. The junior developer had no way to question it because they didn’t yet have the mental model to know what was wrong. The AI couldn’t explain its reasoning when challenged. The only person who can catch that and redirect the agent is someone who already understands how synchronisation works. That is the preceptorship argument in a single incident.

Teaching someone to see that kind of error is what mentorship is. More AI in the codebase changes what that teaching looks like, but it doesn’t make the teaching optional.

What engineers on the ground are saying

The Hacker News thread on the junior hiring crisis ran to 510 comments, most of them from people making real hiring decisions. User strickjb9 described what’s breaking down:

“The whole mentorship thing breaks down when you’re basically collaborating with a model through a proxy. I just assume they’re taking my feedback and feeding it right back to the LLM. Ends up taking more of my time than if I’d done it myself.”

And then:

“maybe we’re not seeing the end of software engineering for those of us already in it — but the door might be closing for anyone trying to come up behind us.”

The feedback loop between senior and junior now has a third party neither of them controls sitting in the middle of it.

The same thread had some of the more grounded optimism you’ll find on this topic. User roadside_picnic:

“While half the juniors I work with are just churning out AI slop, the other half are really interested in the craft of software engineering and understanding computer science better. We’ll need new senior engineers in a few years, and I suspect they will come from a smaller pool of truly engaged juniors today.”

User rozap put it more directly:

“There are still junior engineers out there who have experiments on their GitHubs, who build weird little things because they can. Those people were the best engineers anyway. AI will effectively eliminate junior engineers in the second camp, but absolutely will not those in the first camp.”

The thread wasn’t dominated by junior developers worried about their own prospects. Most of the strongest arguments for keeping junior hiring came from senior engineers who have seen firsthand what happens when the intake stops. Those same engineers are also the ones being asked to change the most: teaching juniors to evaluate AI output, when to trust it and when the fix that passes tests is still wrong. That kind of teaching is something most of them have never had to think about deliberately before.

What this looks like in practice

If you’re a senior dev, the preceptorship model asks something specific. Stop evaluating the output and start observing the process.

When a junior brings you a PR, the old question is “does this code do what it should?” That still matters, but the more useful question is what this person accepted from the AI without questioning, and why.

Ask them to walk you through the AI conversation instead of just showing you the diff. Where did they prompt once and accept the result, and where did they push back? That narration surfaces their judgment faster than any line-by-line review.

Pair on suspicious fixes. The sleep() example from their essay is a real category: the code compiles, the tests pass, but the underlying issue is still there. When you spot one, don’t leave it as a comment in the PR. Sit down and walk through why it looks right and why it isn’t. That’s the transfer that doesn’t happen by osmosis.

Create deliberate failure moments. Give a junior an AI-generated solution you know has a subtle bug and ask them to review it as if they wrote it themselves. Their ability to catch it tells you exactly where their mental model needs work.

Let them teach you the tooling. Juniors who came up with AI tools often have better prompting intuition than seniors who didn’t. If you’re not learning anything from how they use these tools, you’re probably not paying close enough attention.

The preceptorship model replaces the approach of reviewing code output and hoping knowledge transfers by proximity. The explicit work is asking what judgment calls they made with the AI, and whether they can explain them.

What to do with this if you’re building a team now

AI can handle most of what juniors used to do. Where your senior engineers come from in five years is the part nobody’s figured out yet.

The teams that stay technically healthy treat junior development as a structured practice with senior time budgeted for it, not a side effect of shipping features. Juniors still need real exposure to production decisions and to see senior judgment applied to AI output specifically, the kind that looks right but isn’t. They need someone who can explain why the sleep() fix is wrong, not just that it is.

Working on large-scale content platforms like those built on Payload CMS makes this visible quickly. The engineers who can evaluate AI output on those projects are the ones who spent earlier years getting corrected on exactly this kind of problem.

The companies working through this now will have a real talent advantage in five years. The ones cutting junior hiring to optimise for current output will find themselves in 2030 with no one to promote and no institutional knowledge of how to grow people.

If you’re thinking through how to structure mentorship in an AI-assisted engineering team, book a call.

Sources


Author

Paul Utr

Co-founder & Co-CEO

Paul has been launching online platforms since his teens, picking up UX and product design by building them. He led the Mailgun redesign at Netguru and was Principal Designer at Ramp Network through its seed-to-Series-B run. At WAYF he leads design and organisational alignment, and watches how language carries through every product we ship.


We're booking content platform
engagements for 2026.

Twenty-five minutes to walk through the work and decide if we're the right team for it. Scoping and a fixed price come after.