GPT-5 shipped and my team asked if we still need junior engineers
The answer is yes, but for reasons that forced us to articulate what junior engineers actually contribute beyond lines of code.
The week GPT-5 launched, Marcus walked into our Monday standup and asked the question half the industry was thinking: “If GPT-5 can write code at a mid-level, do we still need to hire junior engineers?” The room went quiet. Not because the question was offensive. Because nobody had a confident answer.
GPT-5 shipped with a 400K token context window and a measurable improvement in code generation. It could take a well-specified ticket and produce a working implementation, including tests, faster than most junior engineers. The code was not always great, but it was functional. The question was legitimate.
I write these AI posts from the far side of the honeymoon phase. It also builds on what I learned earlier in “Why I stopped asking candidates to whiteboard and started asking them to review pull requests.” The interesting question is no longer whether the models are impressive. It is where they meaningfully improve decision quality across real systems like portfolio search, aigw, jarvis, and the review loops around everyday engineering work.
The Wrong Answer
The easy answer is to dismiss the question. Of course we need junior engineers. That is how the pipeline works. Juniors become seniors. If you stop hiring juniors, you have no senior pipeline in five years. This argument is true but insufficient. It explains why the industry needs juniors. It does not explain why your team needs juniors right now, this quarter, spending this budget.
The harder answer requires being honest about what junior engineers actually contribute to a team, beyond the code they write.
What Juniors Do That AI Cannot
After a two-hour discussion with the team, we identified four things that junior engineers provide that no AI model replaces:
- Fresh perspectives on system complexity. When a junior asks “why is this so complicated?” they are often identifying real accidental complexity that senior engineers have normalized. Every codebase needs someone who has not yet learned to tolerate its worst patterns.
- Institutional learning and documentation pressure. Juniors force the team to document what works, write onboarding guides, and explain decisions. This documentation benefits everyone, including future AI tools. Teams without juniors stop documenting because everyone “just knows.”
- Pipeline sustainability. An organization that only hires seniors is competing for the same small talent pool as every other company. The cost-per-hire is enormous, the culture becomes homogeneous, and there is no internal growth path that retains mid-level engineers.
- Mentorship development for seniors. Senior engineers who mentor juniors become better leaders, better communicators, and better architects. The act of explaining a system to someone new forces clarity that solo senior work does not.
What We Actually Changed
The conversation did change our approach, but not in the direction Marcus expected. We did not stop hiring juniors. We changed what we ask juniors to do.
Before GPT-5, a junior’s first six months involved a lot of implementation work: building features from specs, writing CRUD endpoints, fixing straightforward bugs. That work is now faster and often better done with AI assistance. So we shifted junior responsibilities toward work that benefits from human judgment and fresh eyes:
- Code review rotation, because juniors catch different things than seniors
- Documentation ownership, because the person learning the system writes the best docs
- Test coverage expansion, because understanding what to test requires understanding the domain
- On-call shadowing earlier, because incident response is a skill that cannot be AI-generated
- Customer support rotation, because understanding user pain directly improves engineering decisions
The implementation work did not disappear from their plates. It just became AI-assisted. Juniors now write the prompt, review the output, and learn from the delta between what the AI produces and what production actually needs. This is a better learning experience than writing boilerplate from scratch.
The Real Question
This is the phase where individual scars finally turned into repeatable operating principles. I cared less about sounding clever and more about leaving behind a system that stayed sane without me in the room. That is how I build jarvis, alfred, and the portfolio RAG stack too.
The question is not whether AI replaces junior engineers. The question is whether your organization uses junior engineers as code-producing machines or as developing professionals. If the former, AI is a threat. If the latter, AI is a tool that accelerates their growth.
We hired two junior engineers this quarter. Their onboarding includes AI tools from day one. They are producing more than our juniors from two years ago produced in their first quarter. They are also learning faster, because the AI handles the mechanical work and frees them to focus on understanding the system, the domain, and the craft.
The answer to Marcus’s question was yes, we still need junior engineers. But the question itself was valuable because it forced us to be precise about why. Any team that cannot articulate why it hires juniors beyond “that is how the industry works” should be worried. Not about AI. About whether they are developing engineers or just consuming them.
The question of whether we still need junior engineers misses the actual function they serve on a team. Juniors are not just cheaper labor for simple tasks. They are the forcing function that makes senior engineers articulate their reasoning, document their decisions, and maintain systems that are understandable to someone who did not build them. A team without juniors accumulates tacit knowledge faster than it documents it. AI can write code, but it cannot replace the organizational pressure that junior engineers create to keep systems comprehensible and decisions explicit. The best teams I have seen treat mentorship as a senior engineering responsibility, not a management overhead.