Why I'm Optimistic About Junior Engineers

If AI can write junior-level code, why would anyone hire juniors?

Spend five minutes on LinkedIn and you’ll find someone asking whether AI has killed the career ladder. I think it’s the wrong question.

It looks from the outside that the assumption is we hire junior engineers because they can write simple code cheaply. I don’t think that’s ever really been true. We hire someone knowing they’ll make mistakes, expect they’ll need help, and know they’ll ask questions that interrupt your day. In return, you’re hoping they become the engineer who answers those questions a few years later. That hasn’t changed for me.

What has changed is what a junior engineer can build in their first afternoon.

Typing was never the job

Five years ago, a junior might spend half a day wrestling with a regex, trying to understand an unfamiliar API, or piecing together a React component from Stack Overflow posts. The afternoon was gone before they’d shipped anything meaningful. Today they can ask an AI for a first pass and spend that same afternoon iterating on something that actually runs.

That shift is easy to misread. Junior engineers can experiment more now. They can try ideas that would have been too frustrating or time-consuming before, and explore unfamiliar technologies without feeling completely blocked at the first syntax error. The ceiling moved.

So did the floor.

A junior with Cursor can produce a working endpoint, a plausible test suite, and a confident explanation of why both are correct. None of that makes them senior. The hard part of software engineering was never typing. It was deciding.

Most of the time, that decision isn’t yours to make alone. The requirement usually arrives from a product manager, a stakeholder, or someone in management who has already decided what problem is worth solving. Your job is to implement it well, and to push back when the approach doesn’t fit the system you’re actually maintaining.

Within that constraint, the questions that matter are still technical. Is this abstraction helping or just making me feel clever? What happens when this code has to change six months from now? Does this actually satisfy what was asked for, or only what sounded good in the ticket?

AI can suggest answers. It can’t know your product, your team, your customers, or the trade-off someone made in a meeting you weren’t in. Judgment is still stubbornly human.

Ten approaches, nine to discard

When generating code is almost free, you’re no longer limited by how quickly you can try a solution. You’re limited by how quickly you can tell a good one from a plausible one.

That’s rarely about choosing between ten product ideas. The ticket is usually already written. A junior engineer with AI might produce ten ways to satisfy the same requirement: ten different abstractions, ten folder structures, ten patterns copied from ten blog posts. An experienced engineer knows which nine to discard before they ever reach review. Too clever. Too brittle. Wrong for how this team ships.

That’s the skill worth learning. It’s also harder to teach than syntax ever was. You can’t memorise your way to good judgment. You have to see systems fail, watch shortcuts turn into maintenance debt, and learn which questions to ask before the code exists. Syntax had cheat sheets. Judgment mostly has scars.

I think AI makes that gap more visible, not less. When the diff looks finished on the first pass, review stops being about formatting and starts being about intent. That’s closer to what good senior engineers were already doing. The juniors who learn to ask “why this approach?” early will compound faster than the ones who learn to ask “why won’t this compile?”

There’s a downside I’m not going to gloss over. Faster tools also mean you can ship confidently wrong code faster. Polished diffs, green tests, and a fundamentally bad approach are not a new combination. AI just makes the first draft look more convincing. That puts more pressure on review and mentorship, not less.

There’s a quieter risk too: code that works and you don’t understand. Accept enough suggestions without stopping to trace what they did and you inherit a system in a language you don’t speak. Debugging becomes guesswork. Refactoring becomes risky. In review you nod along because the diff looks fine. Six months later someone asks why it works this way and you have no answer. That’s always been the trap of copy-paste engineering. AI just makes the copy-paste a lot faster, and the copy a lot more convincing.

Building things is still the best teacher

The best way to learn has always been by building things. The other half used to be just as slow: getting up to speed on a codebase, a language, or a pattern you’d never touched. You’d grep around an unfamiliar repo and hope someone patient had a free afternoon to walk you through the auth flow.

That’s more accessible than it’s ever been. Ask an AI to explain a module in plain English, trace how data flows through a service, or compare two approaches side by side, and you can build a mental model before you’ve memorised every file. It doesn’t replace reading the code yourself. It lowers the cost of the first pass.

Building things used to be slow for a different reason. Every roadblock was another evening digging through documentation or trying random fixes copied from forum posts. Sometimes that struggle taught you something. Sometimes it just burned time.

Now those roadblocks disappear much faster. Instead of spending three hours figuring out why your build won’t compile, you might spend those three hours improving the product instead. I’d happily take that trade, with one caveat: the compile error sometimes was the lesson. If AI always patches around the error without explaining it, you can end up with working code and a shallow mental model. You can ship a feature you couldn’t rewrite from scratch. That’s where a patient reviewer still earns their keep.

None of this means juniors can skip the fundamentals. Understanding how systems work still matters. Knowing how to debug still matters. Being curious still matters. Learning to communicate with your team still matters. If anything, those skills become more important because they’re the parts AI can’t quietly absorb for you while you’re accepting suggestions.

We’ve said this before

Every generation of engineers has worried that the next one has it too easy. We said it when Stack Overflow arrived. We said it about modern frameworks that hid the messy parts. We said it about GitHub Copilot. Now we’re saying it about large language models.

The tools keep changing. The job keeps changing. But the core of engineering hasn’t. It’s still about understanding problems, making trade-offs, and building software that helps people.

AI hasn’t removed the need for junior engineers. It’s given them better tools. What it hasn’t done is remove the need for people who can tell a good approach from a plausible one.

---

That’s the bet I’m making: not that juniors need less mentorship, but that the mentorship can finally focus on the parts that were always the job.