Don’t let AI erase the next generation of dev leaders

I was wrong — AI has had a serious impact on engineering hiring.

We’ve seen it everywhere: big layoffs, reduced hiring, and teams cut in half on the promise that AI will double every developer’s productivity. It’s a line bought into by companies that should know better.

Now, as hiring slowly picks back up, there’s one group still left behind: junior engineers.

That’s not good, because the senior engineers of tomorrow are the junior engineers of today. If AI snaps up all of their opportunities to learn, junior engineers can never grow into senior roles. Then who’s left to lead the engineering teams of the future?

Dev leaders can’t fall into the trap of letting AI take the place of junior engineers. AI has changed the game, but it hasn’t changed the fact that we need on-ramps for the next generation — and that means rethinking what the junior engineer looks like in an AI-powered world.

And here’s the thing: in applied AI, we’re all junior engineers. Even the most experienced devs are figuring out the rules as they’re being written — the best practices, the limits, and the long-term impacts.

That’s exactly why it’s so risky to eliminate entry-level roles. If no one has mastered the new landscape, we need more hands and perspectives, not fewer.

The emerging AI trap: Fewer junior devs, and an uncertain future

When I look at the AI landscape, I’ve noticed a troubling trend. What many of these AI tools are trying to do is perform the routine tasks of a junior engineer. You know: those manual tasks that helped us all get early experience in our careers.

We’re on a path where the engineering team of the future looks like a handful of senior and lead engineers accelerated by AI. That’s worrisome to me.

If we’re removing roles for junior devs, who’s going to step into the senior engineering roles when the current generation ages out?

I don’t think we’re at a place now – or ever – where we can completely remove junior engineers from the equation. We’ve tried that with tools like Devin AI. Anecdotally, I’m not sure that works; I’ve heard of many teams implementing this “AI software engineer” only to remove it a few months later. And that’s not even a specific comment on Devin – it’s an overarching point about the value of a junior dev in their role.

At the same time, we can’t expect the junior developer role to remain exactly the same as it was 10 years ago. AI has completely changed the game.

So let’s define what the Junior Engineer 2.0 looks like.

The Junior Engineer 2.0: How to help junior developers thrive alongside AI

Why do we need junior engineers?

In short, their job is to help handle smaller tasks so that senior engineers can save their energy for bigger ones.

AI is clearly a threat to that. But it’s also not going anywhere. So succeeding as a junior dev means working alongside AI. And sure – junior developers need to embrace new skills on their own. But it’s also up to dev leaders to continue developing the next generation so they can succeed in an AI-charged future.

How do we do that? Here are some thoughts:

The first step: Knowing the ‘enemy’

The days of being able to say “I’m not going to use AI to code” are over. Big companies are now signing large contracts with agentic IDE vendors and requiring that their engineers use them.

Is this a good thing? There are good arguments on either side of that. But what I can personally say with confidence is that when LLMs are “in their comfort zone,” they are a huge accelerant to development.

And that’s what junior developers really need to know: when are LLMs “in the zone?”

Because LLMs are good at regurgitating what they have been trained on (with alterations of course). And what they’ve been trained on is primarily frontend and full-stack code in a variety of different languages and platforms. Particularly for web developers, this means JavaScript/TypeScript, React, Next.js, PHP, Rails, etc. If it’s open source or on GitHub, then the LLM will have trained on it.

So, a junior engineer who is writing CRUD code for Next.js might have a problem, because the LLM is really good at writing that reliably and fast.

Their task is to be good at knowing what the LLMs are good at and what they aren’t. They’ll learn that by becoming fluent with the AI in the IDE. They can use it to their advantage to build out scaffolding code quickly, and then use the autocompletion in small doses to help build out the bespoke code that the AI doesn’t understand because it’s unique.

That’s how senior developers use AI tools to write code. They let the AI handle the grunt work of creating the API endpoints, database calls, forms, field validations, etc. while they work on the unique parts of the application. You know – the cool stuff.

So if you’re a junior dev and you haven’t tried an “agentic” IDE yet, download VS Code, sign in to get free Copilot access, and give it a go. Check out the autocompletion. Try out the agent by letting it loose on a feature.

Worst case, you understand more about why you don’t like it or why it’s not helpful. Best case you have a new, well, Copilot. Either way, you’ll be a more informed candidate and developer.

Becoming more than ‘just a dev’

Building software has always been more than just about the mechanical act of writing code. There is a reason why we say “the hardest problem in computer science is people.” Being an effective developer has always been about communication: with the other developers on your team, with your customers, and with your real customers, your product manager, and your engineering manager.

Moving up from being a junior developer to a mid-level developer isn’t just about coding proficiency. Certainly, writing better code is an aspect of it. But what really differentiates a good developer from a great one is communication: the ability to talk with your stakeholders in a language they can understand. And debugging skills; seriously, junior devs need to learn how to debug code effectively.

Advancing to the principal and architect level means primarily talking with folks. The next generation of developers will be constantly working with leads and engineering managers to set overall technical direction, and talking with the product folks to see where they are taking the product so they can help engineers make better technical choices.

But how can junior engineers practice communication if it’s not part of their role?

My advice: write articles. They are straightforward to write, and they are the easiest way to get noticed by other developers or recruiters. This goes for senior engineers as well!

Let’s say you are stuck on how to get a streaming AI response out of an API endpoint in your pet project. You do some LLM work, do some coding, and you finally get it to work. Maybe you’ve been keeping some notes in Markdown along the way.

Good for you! Well, take those notes, add a little text (maybe even let the LLM help you with that) and you’ve got yourself an article. Now publish it to Medium or Dev.to, or both. And now the next time that someone needs to know how to stream responses, they’ll see your article and your name, and now you are “the go-to for AI streaming.”

Seriously, if there is one piece of advice you take away from this article, it’s write articles. They have opened a lot of doors for folks over the years. Ask around.

Embracing the future

Over the next couple of years, businesses are going to be trying to capitalize on the AI revolution. But nobody really knows what that means yet. How will these AI features work? What models will we use? How can we keep costs down?

New interaction models will be needed. New standards invented. New frameworks designed, built, documented and deployed. There is only one thing that’s for certain and it’s that major changes are coming.

What junior devs need to do is capitalize on this by trying out new things as they see them come up in their feed.

What is MCP? Don’t know? Google it (or, even better, read our comprehensive guide) and find out. Try a couple of experiments with it. Add it to an application. Write and publish an article on it. If it’s wrong, you can just unpublish it. If it’s right, then you’re ahead of the curve.

Change as a constant: The shifting role of junior engineers

This is certainly a challenging time for everyone in software engineering. Nothing is guaranteed. But I’ve been doing this a long time, and I have to tell you that nothing has ever been guaranteed.

I can’t think of a time when there hasn’t been an existential threat that would mean that “in five years all the coding jobs will be gone”. But we are still here, and each time through the cycle, there are more of us.

The jobs do change, though, and the definitions of roles like “junior developer” change along with them. A couple of years ago, you’d expect a junior engineer to be able to add fields to some forms and tweak some API endpoints.

Today, the expectations are different, but they are still achievable. Maybe even more so because of the free AI tools that you have available to you. Junior engineers have to embrace this 2.0 version. Engineering leaders need to recognize their role in all of this; completely replacing junior devs with AI could jeopardize the future of our entire field.

Much of the day-to-day work of a junior engineer in 2035 won’t be too different from 2025. The job is to offload smaller tasks from the senior engineers to enable them to focus on the big-ticket items (big new features, refactorings, structural changes, etc.) And being successful as a junior engineer is about helping your senior developers to be as productive as possible while growing into a leadership role yourself.

What I can say is that I’ve never seen more potential for growth in our industry. Software engineering has always been defined by constant change, and today is no different. Those who adapt will do well, those who don’t adapt will struggle.

That was true when I started, it’s true today, and it will be true when and if I ever retire from this crazy profession, and well after.

The path to senior leadership starts with opportunity. Let’s make sure AI adds to it, not takes it away.