I keep seeing these LinkedIn posts about how we shouldn’t treat AI as our junior developer, how we still need to hire juniors so we have seniors when the current generation retires. And while I agree we absolutely need junior developers, something about this framing sits wrong with me.
It feels like we’re defending junior developers by essentially saying “we need them as human code-writing machines for the future.” But that’s not what made my junior years valuable, and it’s not what made the mentors who supported me so important.
When I think about the people who helped me grow as a developer, they weren’t just teaching me to write code. They were showing me engineering and architectural thinking, how to do competitive analysis, how to gain stakeholder buy-in, how to conduct meaningful code reviews, how to debug complex systems. They walked me through the entire product lifecycle – from competitive analysis and planning, to building and iterating, to testing, reviewing, and releasing.
If we’re only hiring junior developers to write the kind of code that AI can now generate, then we’re not treating them right in the first place.
This reminds me of something that happened in banking decades ago. When ATMs were introduced in the 1970s, everyone assumed bank tellers would disappear. The machines could handle the most common teller tasks – dispensing cash, taking deposits. By the mid-1990s, over 400,000 ATMs were installed across the United States.
But here’s what actually happened: the number of bank teller jobs didn’t decrease. Instead, ATMs made it cheaper to operate bank branches, so banks opened more branches. And the tellers who remained? Their role evolved completely. Cash handling became less important, and human interaction became more valuable. Tellers became part of the “relationship banking team,” helping customers with complex needs that machines couldn’t handle, selling financial products, building personal connections with small business customers.
The skills of the job fundamentally changed. The technology didn’t eliminate the role – it freed tellers from routine tasks so they could focus on work that required human insight, relationship building, and complex problem-solving.
I think we’re facing a similar moment with junior developers. AI can generate code, debug basic issues, even write tests. But if that’s all we expected junior developers to do, then we were underutilizing them from the start.
The junior developers I want to work with aren’t just code writers – they’re learning to think like engineers. They’re asking questions that make our processes better. They’re developing the judgment to know when a technical solution fits the business context. They’re building the communication skills to explain complex problems to stakeholders. They’re learning to see the bigger picture of how their code fits into a product, a user experience, a business strategy.
These skills don’t get automated away. If anything, they become more valuable when routine coding tasks are handled by AI.
But here’s the thing – we have to be intentional about this. We can’t just hire junior developers and hope they’ll magically develop these skills while AI handles the “easy” work. We need to actively mentor them in systems thinking, product sense, architectural decisions, user empathy, and strategic problem-solving.
The conversation shouldn’t be “AI versus junior developers.” It should be “how do we redefine what junior developers learn and do in an AI-augmented world?”
Just like bank tellers evolved from cash handlers to relationship builders, junior developers can evolve from code writers to product thinkers, system designers, and strategic contributors. But only if we’re intentional about what we’re teaching them and what problems we’re asking them to solve.

Leave a Reply