Should You Still Hire Junior Developers?

Last time I asked whether you should hire developers at all in the AI era, and ended on the big unknown of how far one person can scale as a manager of agents. The obvious next question, and the one I got asked on X this week, is: what about juniors?

If an agent can handle most of the beginner tasks a junior developer used to cut their teeth on, how is anyone supposed to get the experience they need to become a senior? And if you’re an employer, why would you hire someone to do work an agent does in seconds?

My short answer is that I’d still hire juniors. But what I’d want to see from them has changed completely.

Why I’d still hire juniors

Every senior developer was a junior once. That sounds obvious, but it’s good to remember that all of our knowledge is learned. If nobody hires juniors for a few years, there won’t be any seniors a few years after that, and the industry will have quietly sawn off the branch it’s sitting on.

The thing that makes a good senior valuable isn’t how fast they type. It’s judgement: knowing which problem is worth solving, spotting when something looks right and isn’t, knowing what to leave out. In part one I said that output is cheap and good decisions aren’t. Agents haven’t changed that. If anything, they’ve made it more true, because an agent will produce a lot of plausible-looking code with no opinion about whether it should exist.

That judgement has to be learned somewhere, and it’s learned by doing real work and living with the consequences. So the question isn’t whether to hire juniors. It’s what you should expect from them, and what they should be doing to get there.

What I’d want to see: something taken from 0 to 1

When I was asked about this on X, my answer was that I’d expect a junior to have taken a project from 0 to 1, iterated on it and maintained it.

Each of those three clauses is doing a job.

0 to 1. They had an idea, or a problem, and turned it into something that works and that someone can actually use. Not a tutorial clone. Not a to-do app built because a course said so.
Iterated. They put it in front of people (even if that’s five friends) and changed it based on what came back. That’s where you learn that your first idea is usually wrong.
Maintained. It’s still running. They’ve fixed bugs in it, upgraded dependencies, dealt with something breaking at an awkward time, and changed code they wrote months ago and no longer remember.

Most of engineering is maintenance and dealing with issues you couldn’t anticipate without real usage. Getting an agent to scaffold a project in an afternoon is easy now. Keeping that project alive for six months, when the codebase has grown and the shortcuts have come back to bite you, is where the learning actually sticks. Bad decisions compound over time and you need to have enough awareness to course correct when that starts to happen. In my experience, the most important lesson in software is that systems have to be changeable, and you only really learn that by trying to change one.

Explain your decisions

The second half of my answer was that I’d ask them to explain their decisions, so I could understand how much of the thinking had been delegated to the LLM.

I wouldn’t set a test. As I said in part one, and before that in testing developers, most assessments can now be passed by the same tools the candidate will use on the job. Instead, the interview would be a walk through their own project:

Why is it structured like this?
What did you try first, and why did you throw it away?
Where did the agent get it wrong, and how did you notice?
What’s the worst bit of the codebase, and what would you change if you started again?

None of these have a right answer. What I’m listening for is whether there’s a person behind the decisions. Someone who leaned on an agent and understood what it produced will have opinions about it. They’ll know which parts they’re proud of and which parts they’d bin. Someone who accepted whatever came back will struggle to say why anything is the way it is.

To be clear, I’m not against juniors using agents. I’d be more worried by a junior who refused to use them. Being comfortable reviewing what an agent produced, and binning it when it’s wrong, is a skill in itself. I just want to see that the thinking stayed with them.

Prove it before hiring, then repeat it on the job

If someone can show me they’ve done all that before I hire them, the job should let them keep doing it.

That means not dropping a new junior into a ticket queue, where they pick up small, disconnected tasks that an agent could do just as well, and never see how any of it fits together. That’s the fastest way to make a junior feel replaceable, and to stop them learning anything an agent can’t already do.

Instead, I’d give them something small to own end to end. A feature, an internal tool, a part of the system nobody else is looking after. Small enough that they can’t do too much damage, real enough that it matters if it breaks. And I’d keep the same expectation as in the interview: be ready to explain your decisions.

Pair that with someone senior who reviews their reasoning, not just their diff. A code review that only says “change this line” teaches very little. One that asks “why did you do it this way?” and “what happens when this changes?” is where the judgement gets passed on.

If you’re a junior, here’s what I’d be doing

If I were starting out now, this is roughly what I’d focus on:

Build something real and keep it running. Pick a problem you or someone you know actually has. Ship it, get people using it, and maintain it for months, not days. Make it something you’re passionate about working on so you don’t lose momentum.
Use agents, but keep a decision log. A plain text file is enough. What you decided, what you rejected and why. It’ll make you think harder, and it’s exactly what you’ll want to have to hand when someone asks you to explain your project.
Read and review more code than you write. Agents will write plenty of code for you. Your job is to understand it, so read it properly, and read other people’s code too.
Get comfortable binning things. If what the agent produced is wrong, or just more than you need, throw it away. Knowing when not to keep something is one of the most underrated skills in this job.

None of this needs anybody’s permission, a degree or a job offer. That’s the genuinely good news for juniors: the tools that make the entry-level tasks easier also make it far easier to build and ship something real on your own.

Engineers have always adapted

I’m optimistic about this, and not because I think it’ll be easy. Software engineers have always had to adapt. Our work has always been the most scrutinised and the most criticised part of any product, and the skillset has changed under our feet every few years. The people who did well were the ones who stayed curious and kept learning.

That’s still the job. The tasks juniors learn on have changed, but the thing that turns a junior into a senior hasn’t: building things, living with them and being able to explain why they are the way they are.

When I started out I was working on a big website but doing simple front-end tasks. I had to wait two years and change jobs before I got to touch back-end logic. Juniors can now build whole projects in their lunchtime. That’s hugely empowering but also raises the bar on the number of things they need to hold in their head.

The game has completely changed, but that is nothing new. As those front-end skills I spent two years refining now atrophy, my advice is clear - if you want to have a long career in software engineering get comfortable with being uncomfortable.

If you’re hiring juniors at the moment, or you’re a junior trying to get hired, I’d genuinely love to hear how it’s going. Drop me a message, especially if you think I’ve got this wrong.