What Do We Do With Juniors Now?
Junior engineers aren't obsolete - they're displaced. AI consumed their entry ramp, but not their purpose. We need to rebuild the ladder: new skills, new practice methods, deliberate mentorship. The pipeline doesn't fix itself. No juniors today means no seniors tomorrow.
Software Engineering used to be an almost dream-like profession. It was open for everyone, egalitarian, fairly easy to pick up and start from scratch. You could learn from countless open source projects and learning materials created by the best, most brilliant minds in the world. All for free!
In a recent decade or two, it evolved from a niche, nerdy profession to the widely desired career. Software was eating the world and strong market demand created a real eldorado. Graduates straight from universities, and self-learned passionates were easily landing well-paying jobs in tech companies.
"Learn to code" became a life hack to prosperity. Becoming a software developer was the golden ticket to the middle class. Everyone should become one! Your factory was closed? Job outsourced to China? Stop whining! Learn to code!
People flocked to universities and boot camps. They wanted to hop on the prosperity train.
The problem is, that train is now gone.
The Rise of AI
The AI revolution came, and, ironically, the same traits that made our industry so open and welcoming, made it easy for AI to consume it.
It wreaked chaos in software engineering careers. Mass layoffs dressed as "pivoting to AI" and "efficiency year". CEOs bragging about lines of code generated by AI and evaluating their engineers by the number of tokens they burn every day while relentlessly flattening their organisations.
Tectonic shifts are hitting software engineering jobs one after another, launching our anxiety levels through the roof.
Under all this dust, a bit overlooked, the role of Junior Engineer silently died.
The Death of a Junior Engineer
The number of junior job postings has dropped by 70% since the 2022 peak. More than 90% of software engineers report that finding a job nowadays is significantly harder.
This isn't just a downturn in tech hiring. It's a structural shift. AI has absorbed an entire category of work that once served as the entry point into the profession. The junior software engineer role, defined by bug fixing, boilerplate code or simple features implementation is being systematically automated away. We are all now moving towards the Tech Lead roles.
Why bother hiring a Junior and investing in their training if an AI agent will do the same work faster, reliably and for a few bucks?
As a result, juniors are facing a very dark reality. The unemployment rate among recent computer engineering grads is reaching 7.5% and is higher than fine arts majors. Talk about irony!
The Tree Without The Roots
The thing is, we need juniors. Without them, who will replace senior engineers when they move to more senior positions? Or when they grow old and retire?
Without a clear career path for juniors to grow into seniors, we will soon create a generational gap and eventually go extinct. Yes, maybe AI will do all the coding by then, but what if not?
And it's not only the problem of replacement.
Juniors are much more than a future "cog in the machine". They bring fresh energy to your organisation. Senior engineers, as experienced as they are, tend to be a bit burned, sometimes even grumpy and cynical. They've seen it all, done it all. It's hard for them to get excited about everyday work, or yet another quarterly goal.
Juniors are the opposite. Everything is new for them. Interesting. Everything is an exciting opportunity to learn something new. They are passionate, curious, energetic. They balance the tired senior's experience with the enthusiasm of a young soul. Junior Engineers are a vital, yet often overlooked, part of any healthy engineering culture.
So what do we do with juniors now? Given their miserable position in the raging AI revolution, how can we save them from extinction?
And how can they save themselves?
What Now, Young Padawan?
As a CS graduate or an early-career engineer, you are probably asking yourself right now: Should I even bother?
My answer is yes. But you need to remember that the rules of the game have changed. Following the old learning path will not work anymore. AI is here to stay, it's growing, it's improving. It has permanently consumed junior-level work and altered the way software engineering teams operate. You need to adjust.
But how?
I've seen many people advise juniors to skip the coder level and jump straight into "senior" topics like system design and architecture. I believe it's a bad advice.
It's Not About Coding
Learning how to code, learning actual software engineering, is not just about mastering language quirks, memorising syntax and typing lines of code. It's about training your brain in problem solving. It's about practising logical, iterative problem analysis, dividing a problem into manageable chunks and designing the solution that glues them together. Spotting edge cases and missing details.
The code is just a tool. A trained, engineering mind is what matters, even in the era of AI, as this is exactly what allows you to prompt and instruct AI properly. Besides, high-level system design and architecture are inevitably shaped by low-level constraints. You cannot truly master software architecture if you never felt and learned how low-level systems are actually built. Advising juniors to skip coding and just brute-force their way into system design and AI agent orchestration is a recipe for disaster and broken careers in the long run.
However, things have clearly changed. Some skills are no longer worth the investment. Mastering specific language syntax and its quirks matters far less, AI handles that. Leetcode-style puzzles are largely pointless now. AI knows them all and implements them in a blink of an eye. Narrowly specialised React Developers or Django Engineers are going extinct. AI is handling framework-level implementation details and basic boilerplate. Engineers are evolving towards being generalist problem solvers, not specialised tinkerers.
So what's still important? What's more important than before? What skills should you learn, as a junior, to stay relevant and build a solid foundation for your career? What skills do you need to become an AI-powered engineer, not a sloppy vibe-coder?
I propose three foundational skills: Software Design, Testing and Product Engineering.
If you master these, you will gain the knowledge and skills needed to work efficiently with (or without) AI agents to produce production-grade software. And a solid foundation to grow towards more senior positions.
Software Design
Good Software Design is what separates vibe-coded slop from AI-powered engineering. Applying principles like SOLID, clearly defined domain boundaries, separation of concerns and communication via clear, explicit interfaces. Knowing how and when to apply different data structures. And above all, keeping things simple, rational and pragmatic.
The open secret is that AI amplifies whatever foundation it builds on - good or bad. AI-generated code is only as good as the prompt and context it receives. Run an AI agent on top of badly designed code, let it roam without clear design constraints, and you will soon end up with a codebase that collapses under its own weight. On the other hand, well-designed code, with clear boundaries, well-established modules and communication patterns, is much easier to comprehend, both for humans and for AI.
This makes Software Design skill even more important in the AI era. You are now designing for yourself, for your team and for AI.
Current AI models are not great at Software Design. They are locally reasonable but globally incoherent. They will improve, surely, but good design is not just about generating code that runs. It's about translating product requirements, user expectations, and external constraints into a solid, simple, yet elastic architecture that will be able to evolve and adjust to future needs. AI does not yet operate at that level of thinking and abstraction. That still remains a uniquely human capacity.
Classic books like A Philosophy of Software Design, Clean Code, or The Pragmatic Programmer are a great place to start. The key is not only learning the principles, AI already knows them all, but developing the judgment to know how and when to apply them pragmatically to real problems.
As always, the best way to learn this skill is to feel the pains of bad design yourself. Build something fast and messy, see where it hurts and where it fails. Then go back and redesign it, redraw domain boundaries, eliminate coupling, apply the principles. Redesigning your own mess teaches design faster than any tutorial, because the pain is personal and concrete. Ask an experienced engineer for help and review, if you can.
Testing
Testing is trendy again! Only this time, with an AI twist.
The usual workflow with AI agents is a loop: Input → Work → Verify → Feedback → New Input. Repeat until the goal is achieved. The verification step is the biggest challenge in AI-powered development. How do you make sure that the generated code is not broken? "Don't make any bugs!" doesn't work. I've tried.
To make verification reliable, you need to define what "valid" means by setting expectations on how the implemented feature should behave. Manual verification of those expectations is slow. It makes the entire loop painfully inefficient, defeating the whole purpose of using AI. You can ask AI to do the verification, but if AI were reliable at it, we wouldn't have that problem in the first place. Fortunately, this problem was solved years ago. You verify expectations with a suite of automated, deterministic tests that execute the code and evaluate results against expected outcomes. That's TDD. It's old school.
Nowadays, the AI agent uses this test suite to verify its work. If tests fail, it reiterates until everything is green. A fully automated feedback loop that can run autonomously.
Vibe and Test until it is Done.
And, a cherry on top, a set of solid, automated test suites is the best safety net for any codebase being rapidly iterated on by a swarm of AI agents. Even if AI goes sideways (which happens more often than anyone is willing to admit), the failing tests will quickly push it back on track.
Coincidentally (what a surprise!), writing good tests and good system design go hand in hand. Well-designed code is much easier to test, which makes tests more reliable and robust. The need to write high-quality tests reinforces good design practices in the code you are testing. A powerful reinforcement for the quality of your software.
Juniors who master testing will not only become better engineers, they will have a solid tool to harness the power of AI agents while keeping the steering wheel firmly in their own hands.
Product Engineering
One of the first things I tell junior engineers is: "Your job is not to write code." They are usually baffled. "How so?!"
"Your job is to deliver a product that meets the needs of our users." Code is just a tool to do that.
When the burden of solving coding puzzles shifts to AI, solving real-world problems becomes our main job. Engineers who understand this, who understand business, empathise with customers, and think of themselves as builders rather than puzzle solvers, will be extraordinarily valuable. Learning the basics of product thinking, understanding your users, your business, the why behind specifications and features, is and will remain a genuine differentiator.
You don't have to replace your PM, but befriend him. Talk to your Head of Product. Understand their vision, their goals, how they think. Read Inspired by Marty Cagan or The Lean Startup. Try to understand what makes a good product. Become a partner to your product counterparts, not just someone who executes their roadmap.
An important and often overlooked part of being a product engineer is the ability to translate product requirements, user needs and business context into a coherent, clear, well-written technical specification. In the AI era, that specification becomes your agent's instruction. Low-quality input will always produce poor output, no matter how capable the model. Another important skill to master.
The Compounding Loop
These three pillars - Software Design, Testing, and Product Engineering - are not three separate skills to collect. They are three parts of the same puzzle that multiply each other.
Product Engineering tells you what to build and why. It turns vague requirements into a clear, well-reasoned specification. In the AI era, that specification becomes your agent's instructions. The quality of your thinking and the clarity of your writing directly determine the quality of what the agent produces. Garbage in, garbage out, no matter how capable the model.
Software Design tells you how to build it. And equally importantly, how to structure the codebase so that AI agents can navigate and extend it without producing chaos. A well-designed system has clear boundaries, explicit contracts, and predictable patterns. An AI agent working inside that structure produces coherent, maintainable output. An agent let loose in a poorly structured codebase accelerates the rot.
Testing closes the loop. It takes your product expectations and your design decisions and turns them into a deterministic, automated feedback mechanism. The agent works. The tests run. If something breaks, the agent knows immediately and iterates. Without this, you are manually reviewing every output, and the speed advantage of AI collapses entirely.
Each skill makes the other two more powerful. Good product thinking produces clearer specs, which leads to better design decisions. Good design makes the codebase easier to test. Good tests make it safe to let AI iterate aggressively. The loop compounds. These three skills are precisely what the current AI-driven workflow requires from the human engineer right now. And they create a solid foundation for future career progression.
The junior who masters this loop doesn't just survive the AI era, vibe-coding desperately. They become the engineer who harnesses the power of AI to ship real products with production-grade quality.
You Need to Adapt
Yes, your path is harder now. The easy on-ramp is gone and pretending otherwise helps nobody.
But the fundamentals of good engineering - design, testing, product thinking - haven't changed. What changed is how you build them and how fast you can apply them. In the past, you would spend a fair amount of time tweaking basic coding tasks, getting familiar with the syntax and language fundamentals. Those days are gone. Now you have to quickly jump to a higher level and acquire more advanced skills.
To do that, you need a real problem, an AI collaborator, and someone more experienced willing to review your decisions and guide you. Build something. Design it deliberately. Test it properly. Understand why someone would actually use it. Repeat.
The engineers who will thrive aren't the ones who out-code AI. They are the ones who out-think it - who bring judgment, taste, and context that no model has.
That's learnable.
We Need to Adapt
The "What do we do with Juniors now?" is not a question that Junior Engineers can solve on their own. They need our help.
Our industry built something remarkable. A profession that was genuinely open, learnable and rewarding. That attracted an enormous wave of talent over the last decade or two. An industry where you could reach the top through hard work, sweat and a bit of talent. We got an amazing chance and we took it. Now, it's our turn to return the favour.
The ladder we used to climb has been consumed by AI. We need to build a new one. It needs to be adjusted, surely. With different skills and different practice methods. But the ladder needs to exist.
As leaders, we need to look beyond quarterly cost cutting. Healthy organisations are resilient - they can adapt, survive and thrive over the years. They need a culture that is both grounded in seniors' experience and energised by juniors' dynamism. Juniors are an investment and a value in their own right, not just a cost to cut. We should treat them accordingly.
If we don't rebuild the entry ramp, we don't only get a talent gap in a few years. We get a knowledge gap. We architect our own extinction for the sake of short-term cost saving, leaving behind the people who came to us to learn and grow.
We need to be better than this.
Thanks for reading! Subscribe for more.
Newsletter for Engineering Leaders
Subscribe to ManagerStories Newsletter for real stories behind leadership wins and epic failures. Subscribe for weekly insights that actually help when your carefully laid plans meet the unpredictable reality of managing engineers.