AI Won't Kill Junior Devs – But Your Hiring Strategy Might

Only non-engineers listening to VC-hype on podcasts think that AI can replace fully junior engineers. Here is a problem I recently asked a junior dev to solve:

Our service occasionally gets especially expensive requests that amplify to our dependencies, one of those dependencies have started complaining that our bursts of traffic are impacting other users, talk to them and propose a solution that aligns with our different requirements. Possible directions are X, Y, Z.

AI is pretty far from able to do this. A cracked out vibe coder maybe could have just added a one-off naive rate limit algorithm pulled from stack overflow or maybe pulled in an unmaintained 3rd party 'rate-limit' package and called it a day. And that would be fine for a MVP but in large organizations figuring out what to build, how to build it, and getting agreement with stakeholders is way, way more work that doing than actual implementation (which still rarely can be one-shotted and needs a lot of hand-holding and iteration to get decent solutions).

Hiring a junior dev is a luxury for big companies that can afford to tie up senior devs tandem coding with a junior for months, then giving easy projects to the junior dev with extensive code review and hand-holding for another year.

I don’t think anyone has the budget for that anymore - not even the big companies. It’s two years of negative $ output for the $ you put in and after those two years the junior dev leaves anyway for a more senior position.

>As Camille Fournier bluntly put it, many tech managers who shifted to "senior-only" hiring are asking for trouble: "How do people ever become 'senior engineers' if they don't start out as junior ones?"

If I were a betting man, I would wager that those managers either don't care, or are gambling that by the time senior engineers are in short supply, AI will be good enough to replace them as well.

The legal industry has already figured out that LLMs can draft routine documents (and make massive mistakes) as well as a graduate lawyer, but that’s not the point.

That industry has properly recognised that this is where people learn the skills to do more complex, higher value work.

> Indeed, companies that try to staff only with experienced devs face a pipeline problem. Without juniors today, there are no seniors tomorrow.

This one seems like a classic Prisoner's Dilemma. Defecting (hiring only seniors) is rational in isolation, but if everyone defects, everyone loses. What incentive for a smaller company to hire and invest in training the junior if in two years they'll leave for a larger company anyway.

This aligns with my thinking that juniors can leverage AI to become seniors much faster than people without AI but there are important concepts about learning debugging, learning how the underlying technologies work, etc. that is crucial to becoming a senior dev. Just using AI to pump out code without knowing the details of how it works will not end up going well for the long haul.

> Traditionally, new developers cut their teeth on small, repetitive tasks – fixing simple bugs, writing unit tests, churning through minor feature tweaks. These tasks were mundane but crucial for skill-building. Now, a lot of that grunt work can be handled by generative AI.

To me, this is the salient point. There are more juniors coming through now who aren't learning the fundamentals, because there is a ready shortcut around the mundane tedious work. Which means they're trying to move onto higher value, higher risk areas without understanding the foundations

Using AI certainly isn't expected in any teams I'm leading; not that I'm going to forbid anyone to use a tool, but I will warn everyone about depending on it and the requirement for verification/understanding.

It won't just kill junior devs - it's killing senior roles as well - right now. Of course, developers are still needed, but the people who are doing the hiring and firing don't really care about that, they just expect more productivity with a smaller workforce, something that's been pretty common even prior to the advent of LLMs.

This has led me to wonder if this is the last generation of "senior" devs. The thinking goes, if it takes a couple of years to educate and train a junior dev on average and LLMs can increasingly replace junior devs... There is no need for a company to hire junior devs, starving the ecosystem of talent that would have otherwise gone onto becoming senior.

In a world where the average work is the first to be displaced (due to training data availability), the last to be replaced are the ones furthest from distribution mean...

I find it quite naive that senior devs think this will stop with juniors. TFA says "No juniors today means no seniors tomorrow ... juniors must focus on higher-level skills like debugging, system design, and effective collaboration" and yet he believes AI won’t be doing all of that by the time those juniors somehow upskill on their own.

I was just testing the newly released Copilot Agent Mode in VS, and it already looks quite capable of debugging things independently (actually, it's not much different from VS Code Agent Mode, which came out a couple of weeks earlier).

System design? Not all seniors need Google-scale design skills. Most systems designed by seniors are either overdesigned, badly designed, or copied from an article or a case study anyway. There are plenty of seniors whose only real qualification is the number of years they've been working.

The author is from Google. I’m not sure if effective collaboration is something given there, but in many companies, especially outside of tech, it's not something you see often. And it's usually inversely proportional to the company’s age.

What seniors learned by doing is now written down and available to LLMs, often in multiple sources, explained by some of the best minds in the field. Any given senior likely knows only a fraction of a domain, and even less when you start combining domains. LLMs probably already there for some of the seniors, only they never checked.

We have one junior dev in a team about a dozen. They have had other roles with us, both at the current job and previous ones. We know they are smart, reliable, and motivated. It's a no brainer to spend time on training because, combined with the skills from other roles, they are likely to have a lot of leverage.

But it's hard to imagine committing to the training without the history.