For decades, the path was obvious. A junior engineer joined a team, got handed a bug nobody else wanted, fixed it, broke something else, fixed that too, and over a few years accumulated the scar tissue that turned into judgment. Senior engineers were not trained; they were grown, slowly, by the system itself.
That system has stopped working at both ends.
At the entry point, juniors aren’t being hired. AI makes a senior dramatically more productive and a junior only marginally so, which makes the rational move, for any single team, in any single quarter, to skip the junior hire and let an experienced engineer with AI do the work two juniors used to do. Industry-wide, the pipeline is being shut off before it starts.
For the juniors who do get hired, the curriculum has been quietly canceled. The bugs they used to fix are closed by an agent before standup. The CRUD endpoints they used to wire up are scaffolded in a single prompt. The boilerplate that taught them how a framework actually thinks is generated and forgotten. The work hasn’t disappeared. It’s been absorbed.
This is the part the productivity narrative misses. When you remove the grunt work, you don’t just remove low-value labor. You remove the teaching surface that the industry has relied on for forty years. Combine that with a hiring market that has stopped producing the input, and the math becomes unforgiving. Nobody has built a replacement for either side.
The early data lines up. Stanford’s analysis of US labor data shows that employment of software developers aged 22–25 dropped roughly 20% from its peak in late 2022 through mid-2025, while employment of developers aged 35–49 grew by 9% over the same period. LeadDev’s 2025 survey found 54% of engineering leaders plan to reduce junior hiring over the next year. An Anthropic study of junior engineers learning a new library found that those who used AI scored 17 percentage points lower on comprehension tests than those who didn’t, with the largest gaps in debugging. GitHub’s own studies show that senior developers code 22% faster with AI assistance, while juniors only 4% faster. AI is not lifting all boats. It’s lifting the boats that already had captains.
Now look five to seven years out. Today’s seniors move into architecture, management, or retirement. The juniors who would have replaced them mostly weren’t hired, and the few who were never accumulated the judgment that makes someone senior. The agents will still be writing code. There will be nobody left who can tell whether the code is right.
This is what I argued previously: senior engineers know things AI doesn’t, and that knowledge comes from having been burned. The question this post answers is the obvious follow-up. If the burns aren’t happening on their own, and if the people who would have been burned aren’t being hired in the first place, how do you cause both deliberately?
The reframe: this is not a productivity problem
Most conversations about AI and junior developers get stuck on the wrong question. Leaders ask: How do we make our juniors more productive with AI? The answer to that question is what’s killing the pipeline. Productive juniors who never learn to think are not juniors. They are very fast typists with credentials.
The right question is: how do we make our juniors learn, given that AI has absorbed the work they used to learn from? And before that: how do we make sure juniors are hired in the first place?
Both are teaching questions, not productivity questions. And teaching, done properly, is structurally inefficient. It always has been. A senior who walks a junior through a debugging session is producing nothing for the duration of that session except a future senior. That was acceptable when the grunt work existed because it paid for the inefficiency. The grunt work is gone. The inefficiency now has to be funded directly, on purpose, as a line item.
Most organizations are not willing to do this. They tell themselves that AI plus a junior equals a productive junior, the same way previous generations told themselves that an IDE plus a junior equaled a productive junior. The difference is that the IDE was a leaky teacher. Natural language is opaque. There is no incidental learning happening behind the prompt. If you don’t deliberately build the teaching in, no teaching occurs.
What follows is a framework for doing that. It is a framework for teaching, not for productivity. Productivity will come later, when the juniors who go through it become the seniors the next decade will need. The industry’s job right now is to pay that price.
A framework in three tiers
The mistake people make when listing mechanisms for developing juniors in the AI era is treating them as a menu. Pick three, see what works. That fails because the mechanisms only work in the right order, with the right organizational support behind them. The framework below is structured as three tiers, escalating in commitment. Each tier requires the one below it. Skipping tiers is the failure mode.
Tier 1: Organizational commitment — the hiring fight comes first
The order matters. Tasks and pairing don’t matter if there are no juniors to do them, so the framework starts where the pipeline starts: with the decision to hire. Three commitments, in declining order of how comfortable they will be:
Senior ICs and EMs lobby for the junior hiring budget. This is the political point, and it leads because nothing else works without it. Finance will not fund deliberate inefficiency. Executives chasing AI productivity narratives will not fund it either. The only people who reliably argue for hiring juniors are the senior engineers who remember being one. Charity Majors has been making this argument for years, and it has not become any less true: at every organization that maintained a healthy junior pipeline over the last two years, that pipeline existed because senior engineers fought for it.
Mentorship is a measured, compensated, promotable deliverable. Senior ICs are evaluated on the trajectory of the juniors they pair with. Not on whether the juniors shipped fast, but on whether the juniors became seniors. Promotion criteria for staff and principal levels include observable mentorship outcomes. This is the only signal that will get senior engineers to spend the time, and without it, the pairing structures in Tier 3 collapse on contact with quarterly reviews.
Junior performance is decoupled from velocity for the first two years. Juniors are managed for learning, not for output. Their assessment is based on growth in understanding, quality of design documents, depth of investigation in postmortems. The output question is deferred. Kent Beck has written about this as managing juniors “for learning, not production,” and it is the single hardest cultural shift on this list, because it requires managers to defend two-year investments to executives who want quarterly outputs.
Tier 2: Task design — what juniors actually do
Once juniors are in the door and the organization has agreed not to evaluate them on velocity, the work itself has to change. The old work is gone. Four task types, designed deliberately:
Code review of AI-generated PRs, with comprehension as the bar. A junior reviewing AI-generated code is not asking “does this work?” They are asking “do I understand why this is the way it is, and would I have written it this way if I were the one thinking?” The senior reviewing the junior’s review is checking the second question, not the first. This is the inversion: the PR is not the artifact being assessed. The junior’s understanding of the PR is.
Design documents, written before any code is generated. A junior who can write a one-pager that explains the problem, the constraints, the proposed approach, the failure modes, and the open questions has done the cognitive work that used to happen accidentally during implementation. The doc is the substitute for the implementation as a learning activity. This is also the place where juniors learn to argue with seniors, which is half of what makes a senior.
Bug investigation, decoupled from bug fixing. The fixing is the part AI does well. The investigating, narrowing, hypothesizing, reproducing — the part where you build a mental model of a system you didn’t write — is the part that builds judgment. Have juniors run the investigation, write up the diagnosis, propose the fix. Whether AI types the fix is irrelevant. The diagnosis is the deliverable.
Small features, implemented end to end with explicit articulation. If natural language is the new programming language, then juniors still need to learn what to say to the machine. That requires understanding networks, memory, concurrency, data structures, deployment topology — the substrate the prompts sit on top of. The way you build that understanding is by having juniors implement small features and explain, in writing or to a senior, why their prompts produced the code they did.
These are not new ideas. What’s new is doing them on purpose, as the primary output of a junior’s first two years, and not as a side effect of shipping features.
Tier 3: Pairing structure - what seniors actually do
Tier 2 collapses into nothing if the senior is not present at the right moments. The wrong moments are after the fact, in PR review, when the junior has already shipped something that mostly works. The right moments are during prompting, during investigation, during the design conversation, when the thinking is happening.
Three concrete patterns:
Steering sessions. A senior and a junior, one hour a week, working on a real problem from the junior’s queue. They open the AI tool together. The senior describes the problem out loud. The junior writes the prompt. They watch the output together, and the senior explains in real time why the generated code is or isn’t right. The senior’s tacit judgment — the part nobody can write down — becomes externalized. Three months in, juniors start catching the same architectural drift independently. This is the closest thing to an apprenticeship the AI era has produced, and it costs the senior an hour a week.
Trio programming. Pair programming, with AI as the third participant. The senior and junior sit together. The junior drives the AI. The senior interrupts when the AI proposes something the junior would otherwise accept. Addy Osmani has written extensively on this pattern, and the version that works in practice is one where the senior is preserved in the loop during execution, not just at review time.
Chat-log review. The transcript of a junior’s session with the AI is a richer artifact than the resulting code. It shows what the junior asked, what they accepted, what they rejected, and where they got confused. Reviewing the chat log with the junior, weekly, surfaces gaps that the merged code would never reveal. This is the practice Russinovich and Hanselman propose at Microsoft, and it is the cheapest piece of pedagogy in the framework.
The deliberate inefficiency is concentrated here. A senior spending three hours a week on one junior produces less code that week than a senior spending three hours a week on two juniors. That is the cost. There is no way around it. If your organization can’t tolerate that cost — and Tier 1 is what makes that tolerance possible — it’s not going to produce seniors.
The contrarian case, and why it doesn’t change the answer
Some thoughtful voices argue that this whole framing is overblown. The bet on juniors, they claim, has actually gotten better: AI compresses the ramp from years to months for juniors who use it well. AI-native graduates, they argue, are more fluent than the seniors above them. Some companies are experimenting with hiring “super juniors” — entry-level engineers paired with extremely senior architects — and reporting strong results.
These are honest arguments, and the data behind them is real. They are also not arguments against this framework. They are arguments for it.
The compressed-ramp claim holds only when juniors use AI for conceptual inquiry rather than for delegation. The same study that shows the 17-point comprehension gap also shows that juniors who ask AI to explain things score above 65%, while juniors who ask AI to do things score below 40%. The difference is in teaching. Without it, “AI compresses the ramp” becomes “AI compresses the time it takes to fail.”
The super-junior model works because of the deliberate pairing with super-seniors. Take away the senior architects, and the model is just unsupervised AI use with a different job title. The contrarians are not arguing for laissez-faire. They are arguing for a different shape of structured intervention. This is the same argument as this post, with different vocabulary.
What does this cost, and why pay it
A team of ten engineers, with one senior spending three hours a week on each of two juniors, loses six senior-hours of weekly throughput. Across a year, that’s roughly 300 hours, or about 8 weeks of senior work that doesn’t go into shipping. For two juniors. That is the price.
It is also a bargain. In five to seven years, those two juniors will be seniors, and the alternative is that nobody will be. The organizations that pay this price now will be the ones with engineering leadership in 2032. The ones that don’t will be hiring frantically from a pool that doesn’t exist, paying premiums for the few seniors who survived the gap, and discovering — too late — that the AI agents they built their strategy on are very fast and very confident and have nobody left who can tell when they’re wrong.
The grunt work is gone. The teaching surface is gone with it. The hiring market that fed the pipeline has shut off at the top. What remains is a choice: build the replacement deliberately, on purpose, while accepting the cost, or pretend the problem doesn’t exist and find out what an industry without seniors looks like.
We already know what it looks like. We’ve been describing it the whole time. It looks like an AI agent shipping code with confidence, and nobody in the room has the judgment to stop it.