Not hiring junior engineers won't solve the problem you think you have

August 2, 2026

I was listening to a podcast recently where the interviewer asked the CTO of a very large tech company if they were still hiring junior engineers. I cannot get over the fact this was a serious question.

We are certainly still going through the fog of change with AI in software engineering. Companies are experimenting, with some making big claims and most feeling behind in adapting. This anxiety leads to simplistic arguments and decisions (hello tokenmaxxing!) as companies try to find simple bets that they hope will put them ahead of the curve.

“Should we hire junior engineers?” is one of those questions. New entrants are facing a real struggle, with lower growth in tech and tooling that can complete the tasks they would perform. I don’t want to minimize that. But this framing is damaging to the candidates and, more importantly, to companies.

Junior engineers are needed today and will continue to be needed. If your organization has doubts about that, you might be facing a different problem.

This is not a new topic

The motivation to avoid hiring less tenured engineers is not new. Tech companies have for a long time aimed at hiring only more tenured employees, on the theory that individuals need to own their work end to end, making it better to invest in experience.

This was the situation in a company I worked at. As I joined, the policy was to only hire senior engineers and above. The argument was that due to the complexity of our system, junior engineers could be a liability, shipping changes that broke things. One of the visible and ironic consequences of this decision was the struggle that managers would face to get simple tasks done, since everyone felt they were above them.

We changed the policy, first by experimenting with hiring a few less tenured people, and then by setting up an intern program that became an entry point for graduates. A few years later, some of those interns were mid-level engineers outperforming people we had hired as seniors.

The AI version of this argument is not a new insight. It’s an old (and mistaken) preference, wearing new clothes.

The wrong assumptions

The junior engineer question rests on a few assumptions, and all of them are flawed.

The most obvious one is the talent retention problem. You will lose people to attrition. Engineers are going to get more experienced and look for bigger challenges. You will need to hire more people. At that point you either go to the market, paying in time and recruiting cost for someone who needs six months to learn your systems, or you promote someone who already knows them. AI is certainly having an impact on team size, but that size will be greater than zero.

Another core assumption is that the industry is changing so much, and the engineer’s role will be so different, that hiring someone who is not experienced now will be wasteful, as they might not be able to adapt to the change.

A story I usually tell on this topic is that when I started my career as a consultant, we would spend our first week on a project setting up our environments. Clients would pay for a full engineering team at very expensive rates to spend a week getting a source control repository and a CI build running. And that was if we were lucky enough to be where the computers didn’t take weeks to be provisioned. A job that can likely be done with a prompt and 10 minutes of waiting nowadays.

I have survived, but my skills setting up a subversion repository haven’t. If the industry is changing that fast, experience is the depreciating asset, and the people arguing juniors can’t adapt have the most to unlearn.

The last, and likely most ingrained, premise is that if the engineer’s job becomes prompting and managing agents that execute the simple (and complex) tasks, what will a junior engineer do?

The main problem with this thinking is that it reduces the engineering job to delivering code. The role of an engineer pre-AI was to deliver customer value by building software. The role of an engineer post-AI is still to deliver customer value, now through agents that are writing code. The goal is still the same and judgment is still necessary. Right now, technical judgment is still a major part of the role. Maybe that will be minimized in the future (a topic for another post), but it will then be replaced by value-focused judgment. Does this actually solve the problem? Does this change fit the features already there?

Even in a fully AI first world, the engineer’s role will continue to be to deliver value.

And it seems obvious to me that if the role of an engineer is to lead a project solo by orchestrating multiple agents, the job of the junior engineer will be to lead simple projects solo by orchestrating multiple agents. Regardless of what the future holds, there will be simpler and more complex versions of the task to be done.

The hidden problem

The assumptions above highlight how the junior engineer question is often misguided in the current tech industry conversation. But they also expose a deeper problem, which is that technology companies struggle to see a place for juniors because they insist on looking at engineering as an isolated discipline within product development.

We are in 2026, decades after the industry rejected waterfall as a productive method to deliver software, but we keep falling back on it. Software teams still often look like a production line, where requirements coming from product managers working in isolation are then turned into design by designers working in isolation, then given to technical leaders who divide the work into simple tasks that then get assigned to less tenured members of the team. If that is the process, then it’s natural to think that you can replace the last step with agents.

However, the problem here is not the role of junior engineers. It is the system. Product development should be a collaboration between product, design, and engineering in delivering customer value. Engineers are not just writing code, they are providing perspective and alternatives on how to solve a customer problem in the most effective way. A simple task should not be to Add a CSV export endpoint, it should be to Allow a customer to export their billing history, which includes thinking about what belongs on that export, what performance is acceptable given you have 10 years of data, and how it integrates with other exporting features in your product.

And if you frame work like that, even in an AI-forward world, there will be more complex engineering problems, like how to deliver a complex strategic initiative in your company’s technology context. And there will be simpler engineering problems, like the example above.

If your team’s engineers are working on technical tasks, the problem is not about juniors and AI. It is about the effectiveness of your engineering organization. You will have a few engineers managing the complexity (and becoming the bottleneck) for others, while your competitors will have every member contributing customer value. A highly productive team, now and in the future, has room for engineers at all levels, juniors included.