Junior engineers aren't going away. The bottom rung is moving

I disagree with the idea that AI has killed the junior developer. The story is always the same tidy one: agents write the boilerplate now, so nobody needs the people who used to write it. The data doesn't say that. What it does say is less dramatic and, for anyone running an engineering team, more worrying, because the work hasn't disappeared, the way people get into it is changing.

Fortune, citing Indeed data, reports that US postings for software developers of all levels are down 29% from Indeed's pre-pandemic benchmark. That is a real drop and I won't pretend otherwise. But the same piece describes something more specific. Between mid-2022 and mid-2025 the share of postings asking for two to four years of experience fell, while the share asking for at least five years rose from 37% to 42%.

Put those numbers side by side and you get fewer jobs, and the ones left want more experience. That isn't machines pushing juniors off the ladder, it's employers pulling the ladder up a few rungs. Laura Ullrich, Indeed's director of economic research, calls this experience creep. It is a good name for it.

The mechanism matters because it decides who gets hurt. A layoff hits people who already have a job, a CV and a network. Experience creep hits the people who don't have any of those yet. When a role a two-year engineer could do carries a five-year requirement, that is not a quality bar, it's a filter, and it filters out exactly the people who would otherwise become your seniors.

IBM went the other way. In February its chief human resources officer, Nickle LaMoreaux, told Fortune the company is tripling its entry-level hiring, and that this includes software developers. IBM didn't just put more people into the old jobs. It redesigned the roles around AI fluency, so its software engineers spend less time on routine coding and more of it with customers.

There is a caveat, and Fortune reports it too. About a week after CEO Arvind Krishna said IBM would probably hire more people out of college, the company announced it would cut thousands of workers by the end of the year, which a spokesperson put at "a relatively low single-digit percentage" of the global workforce. So this isn't charity, and IBM isn't immune to the pressures everyone else is under, but it is a bet on where future experience comes from. I think it's the right bet. You can't keep buying engineers with ten years behind them if nobody is making them.

How juniors use the tools is what matters

The evidence I find more important is about learning, not hiring. Anthropic ran a randomized trial with 52 software engineers, mostly junior, who had to learn Trio, a Python library for asynchronous programming. Half could use an AI assistant, the other half coded by hand, and afterwards everyone took a quiz on the material.

The AI group averaged 50% and the hand-coding group averaged 67%. Yes, the AI group finished about two minutes faster, but the study says that difference was not statistically significant. In practice they learned less and saved no meaningful time.

The key result is inside those averages, because Anthropic also grouped participants by how they used the assistant. The people who handed the work over, leaned on it more and more as the task went on, or kept asking it to fix their bugs averaged under 40%. The people who generated code and then worked to understand it, asked for explanations alongside the code, or asked conceptual questions averaged 65% or higher, close to the people who didn't use AI at all.

The largest gap between those two groups was on the debugging questions, which doesn't surprise me. Debugging is mostly knowing what the code should be doing and noticing where it isn't. You only build that by holding the program in your own head for a while, and that is exactly the step delegation lets you skip.

These tools do make me faster, but that's because I've spent more than twenty years learning what wrong code looks like. A junior who delegates gets the same output without ever building that picture. In the moment it looks like the same productivity, but a year later you don't end up with the same engineer.

What I'd change

If I were interviewing a junior candidate now, I wouldn't waste time asking whether they use AI, everyone does. I'd ask what they ask it. I'd hand them a short piece of generated code with a subtle bug and ask them to explain what it does before they touch anything. Someone who reads first and asks why is someone I can teach.

For their first few months I'd want them debugging without an agent, i.e. reading the stack trace, adding the print statements, forming a guess and checking it. The agent is still allowed, but as a tutor: explain a concept, explain why a pattern exists, generate something and then take it apart, etc. That is close to the behaviour that scored well in Anthropic's study, and it costs very little. I'd also want reviewers to ask juniors to explain their pull requests instead of just approving them. If they can't explain a change, it isn't really theirs yet.

None of this is complicated. The hard part is the incentive, not the practice. Skipping the junior hire saves money this year and the cost doesn't show up on anyone's dashboard, but it does show up later, as the senior engineer you can't find in 2030 who was the junior nobody hired in 2026.

If you want seniors in five years, hire juniors now.