The industry is going to wake up in five to seven years to a shortage of senior engineers, and it will not be because we fired any of them. The current cohort of senior engineers is, by most measures, more valuable in 2026 than it was in 2022. The fired-them-all reading is wrong. The harder reading is that the system that produces senior engineers takes a decade to run and is being quietly drained at the front, and the people on the receiving end of the drain have not yet figured out how much they are losing.
I wrote a week ago about the junior-developer problem — the closing of the entry tier of the pipeline, the way the question-and-answer archives that taught a generation have been quietly drying up, the way apprenticeship has been disappearing in favor of fast-shipping output. That piece was about the input. This piece is about the output, five to seven years from now, when the cohort that did not get apprenticeship would have been the next batch of senior engineers and is not.
The numbers are not speculative
The numbers are, in fact, public.
At Google Cloud Next 2026, Sundar Pichai said that 75% of all new code at Google is now AI-generated and approved by engineers, up from 50% last fall. The framing is the part to read closely. Code is generated by AI; engineers approve it. The role separation is already in the corporate language.
Sonar's 2026 State of Code Developer Survey puts the across-the-industry version at 42% of current code already AI-generated or substantially AI-assisted, with developers expecting that share to reach 65% by 2027. Seventy-two percent of developers who have tried AI tooling use it daily. Different studies measure differently and "AI-assisted" hides a lot of variance — autocomplete is not the same thing as autonomous-agent PRs — but the direction is consistent across every survey of the past eighteen months.
Anthropic's 2026 Agentic Coding Trends report adds a useful nuance. Developers use AI for roughly 60% of their work; the share of tasks they can fully delegate, end to end, is much smaller, typically 0–20%. The model is not replacing the work. The model is doing most of the typing inside the work.
The headline that matters is not the number. It is that the entire entry-level surface of the profession is now the thing AI is best at.
What seniors carry that AI doesn't
There is a useful term the original Russian-language article on this topic coined for what stays with the human after the code is generated: the responsibility perimeter. The literal English would be the perimeter of responsibility, and it works. The perimeter is the set of things a senior engineer is still on the hook for, even when none of the typing comes from them:
- Understand what is actually being asked, including what isn't being asked.
- Choose the architectural approach and the limits of the system.
- Evaluate the security posture, the failure modes, the edge cases.
- Plan the test strategy and the rollout.
- Read the diff the model produced and notice the wrong abstraction.
- Accept the risk and answer for the production incident.
AI can write the code. AI does not get woken up at 3 a.m. when the payment flow goes down. The new asymmetry of software work is that operational participation has fallen and accountability has not. A senior might write 5% of the code in a commit and remain answerable for 100% of what that commit does to the system.
The perimeter is not a feature you add to a model. It is a thing humans grow into by being responsible for outcomes long enough that they learn what to look for. There is no shortcut. There is no documentation that imparts it.
Where seniors used to come from
Senior judgement is not knowledge. It is patterned response, accumulated by repeated exposure to systems that broke in ways the textbook did not predict.
The classic path went something like this. A junior joined a team. They got a small, contained task — write the endpoint, add the column, fix the obvious bug, document the existing module. They did it slowly. They wrote the wrong abstraction. They got reviewed. They argued with the reviewer. They redid it. They broke their local environment. They asked the senior next to them why the foreign key was structured that way and were told a story that started "well, in 2019 we had an incident where…" After a hundred of those, they could see the next incident coming before it happened. That is what senior judgement is.
The contained task was a learning artifact, not a productivity artifact. It was the cheap kindling that, eventually, made fire. The same task today goes to the agent. The senior is happy because the boring work is done in fifteen minutes; the business is happy because the cost line went down. The team is happy. The junior who would have been growing on that task is, on the same day, growing on a different task that the agent also did better. None of these decisions look wrong locally. The aggregate is the problem.
Side by side, the old and new versions of one routine task look like this:
| Learning surface | Old path (junior writes it) | New path (senior reviews agent output) | What the junior used to learn |
|---|---|---|---|
| First simple endpoint | Junior writes the route, DTO, validation, persistence, tests | Agent produces the whole thing; senior approves the PR | The shape of the codebase; what the team's idioms are |
| First migration | Junior writes the SQL, the up/down, the rollback plan | Agent generates migration; senior checks blast radius | Why migrations are scary; what reversibility means |
| First production bug | Junior pages themselves, walks the logs, finds the cause | Senior asks the agent for a likely root cause and confirms | What incident pattern recognition feels like |
| First code review of someone else | Junior reviews a teammate's PR; the discussion is the lesson | Agent's PRs get senior-reviewed; no peer-review surface for the junior | How another engineer thinks; what good taste looks like |
| First conversation with the product owner | Junior gets the half-formed requirement and asks clarifying questions | Senior writes the prompt that the agent then implements | How requirements get translated into a system |
The right-hand column is what disappears from the new pipeline. Not the work, not the output — the learning. The work is being done. Nobody is learning to do the work.
The data is in
Stanford's 2026 AI Index report put a number on the front of the pipeline. Employment for software developers aged 22 to 25 has fallen by roughly 20% since 2024 — even as employment for older developers in the same firms has continued to grow. The cohort that should be in its first or second job is the cohort that is not getting hired. Other forces are in the mix — interest rates, post-pandemic correction, layoffs, bootcamp saturation, geography of hiring. But the report's own framing is that the effects of AI on the labor market are showing up unevenly, "concentrated in hiring pipelines and the youngest workers in exposed occupations."
Anthropic's randomized trial on AI-assistance and the formation of coding skills put a number on the back of the pipeline. Two groups solved the same problem. The group that used AI assistance finished slightly faster. On a follow-up quiz that tested four things — debugging, code reading, code writing, and conceptual understanding of what they had just built — the AI-assisted group averaged 50%. The unaided group averaged 67%. The researchers described that gap as roughly two letter grades. Same problem, faster solution, weaker skill formation. The framing the researchers chose for the implication is that aggressive AI deployment in the workplace may produce a short-term productivity win at the cost of the skills needed to verify the AI's output later.
These two studies are not unrelated. They are the same phenomenon at different points in the funnel. Fewer entries into the pipeline. Worse learning for the entries that do get in. Five to seven years downstream is the senior tier of the same pipeline.
The reproduction gap
There is another coined term from the original article that travels well: the engineer reproduction gap. It is the gap between what the market continues to demand — strong mid-level engineers, senior engineers, tech leads, architects — and what the market is willing to fund the production of. The demand side is loud. The supply side is, year over year, less loud. The two have been drifting apart since roughly 2023. AI is not the cause; it is the accelerant.
The thing that makes the reproduction gap structurally hard to see is the lag. Most labor-market problems show up the same quarter the decision is made. You stop hiring in Q1, you have a hiring problem in Q1. The senior-engineer reproduction problem does not work like that. You stop hiring juniors in 2024. You feel the missing seniors in 2030. Nothing in the corporate planning cycle is set up to notice a problem that takes six years to arrive.
The five-to-seven-year extrapolation is not a forecast. It is the duration of the senior-engineer formation cycle, applied to the labor data that already exists. If the 22-to-25 cohort is 20% smaller than it would otherwise be, and the cohort that is hired is having a measurably weaker time learning, then five to seven years from now the cohort of fully-formed senior engineers will be perceptibly smaller, perceptibly less prepared, or both.
What this would look like
It will not announce itself. There will not be a "senior engineer shortage" press release. There will be a slow shift in the tone of hiring posts. "Senior engineer with experience in X" will get fewer good replies, then more replies that look qualified on paper and then fall over in the technical screen. Recruiters will start describing the role as "harder to fill than it used to be" and "needing a stretch." Salaries for confirmed-strong seniors will move; the rest of the market will not move with them. Companies that always assumed they could buy senior judgement on demand will discover that they cannot.
At the same time, the bottom of the funnel will keep widening. More juniors will graduate from bootcamps and CS programs every year. The phantom-vacancy phenomenon — open requisitions that exist on paper but never close — will become more visible. The mismatch is not "too few entrants and too many jobs." It is "many entrants and not enough of the kind of slot that produces the next senior."
What an industry could do that this one mostly isn't
The fix, if there is one, is not to ban AI from juniors. They will use it; they have to learn to use it; the bigger danger is that they use it badly. The fix is to engineer the learning path around AI rather than around its absence.
Concretely:
- Apprenticeship time as a budget line. Companies that want senior engineers in 2032 have to fund the slower-than-AI work that produces them today. That means deliberately giving juniors tasks they would not be optimal for, and accepting the delta against the AI-augmented alternative as a training cost. The companies that do this will be the ones with senior bench depth in 2032. Almost nobody is doing it today.
- The "learning autopsy" after every agent-assisted task. A senior reviews an agent's output and approves it; fine. A junior reviews the same agent's output, writes a one-paragraph note on what the agent got right, what it got wrong, and what they would have done differently; better. The artifact is the learning, not the code.
- Guided-failure environments. A staging system the junior can break, with a real incident-response loop attached, that does not put production at risk. The fire drill, scheduled rather than incidental. The senior engineers of 2018 learned this by accident. The senior engineers of 2030 will need it on the calendar.
- Slower onboarding tracks for early-career hires. Specifically slower than the AI-augmented baseline. This is the line most companies will not cross, because it costs money the financial model says it does not have. It is also the only one that demonstrably produces senior engineers in the long run.
None of these are novel. All of them used to happen, more or less, without anyone having to engineer them on purpose. The reason they have to be engineered on purpose now is that the local incentive has shifted: every individual task is cheaper to ship via the AI-augmented path, and the cost of taking the slower path is paid by whoever is left holding the team's senior bench in 2032.
That cost lands later, on someone else, at a time when the decision that produced it is no longer traceable. The textbook name for that is a market failure. The fix for market failures is policy, not exhortation.
Nobody is firing senior engineers. The current cohort is, if anything, more valuable than it was three years ago. The cohort behind them is shrinking. The cohort behind that is being trained worse.
That is not a hiring problem. It is a reproduction problem.
The five-to-seven-year horizon is not a forecast. It is a cycle length. The decisions that determine whether the industry has senior engineers in 2032 are being made, somewhere on a procurement spreadsheet, this week. The companies that figure it out will end up with the bench. The ones that don't will discover, in 2030 or 2031, that you can run out of senior engineers without firing any. By then it will be late to start.