The Senior Engineer Shortage Is About to Get Worse — and AI Is the Reason

There is a comfortable story going around about AI and engineering, and most of it is true. AI writes the boilerplate. It scaffolds the service. It explains the stack trace, drafts the test, and turns a vague ticket into working code before lunch. Junior engineers are shipping more, faster, than any cohort in the history of this industry. As someone who has spent twenty years building a company on the productivity of engineers, I should be thrilled.

I am — and I am also worried, because underneath the comfortable story is an uncomfortable one that almost nobody is pricing in.

We are quietly switching off the furnace that used to forge senior engineers. And in five to ten years, the bill for that is going to come due as a shortage of exactly the people who are hardest to replace.

Seniority Was Never About Years — It Was About Friction

Ask yourself how the best engineer you know actually became senior. It was not a course. It was not a title that arrived on an anniversary. It was a thousand hours of friction: the bug that took three days and turned out to be a clock-skew problem; the "it's slow" complaint with no error and no stack trace and no Stack Overflow answer; the migration that went sideways at 2 a.m.; the design they were sure about until it fell over under real traffic.

Seniority is the residue of struggle. The struggle is what teaches you that symptoms are not diagnoses, that the real bottleneck is rarely where the dashboard points, that every architecture is a trade and your job is to find which one. None of that is knowledge you can be told. It is judgment, and judgment is forged by the productive pain of being stuck and working your way out.

Here is the problem. AI is extraordinarily good at removing exactly that pain.

When a junior hits the wall that used to make a senior, the wall is now gone. The AI hands over a working answer in fifteen seconds. The ticket closes. The demo passes. Everyone is happy — and the engineer has been moved past the precise moment that would have grown them. Multiply that across every ticket, every day, for years, and you get a generation that has shipped enormous amounts of code and been forged by almost none of it.

We are optimizing, very efficiently, for output. We are de-optimizing, without meaning to, for the formation of judgment.

AI Raises the Floor and Hides the Ceiling

I want to be precise, because this is not an anti-AI argument. AI raises the floor dramatically. A junior with a good model is more useful on day one than a junior was a decade ago. That is real and it is good.

But raising the floor is not the same as building the ceiling, and the two get confused. A team can look highly productive — velocity up, tickets flying — while the depth that handles the genuinely hard 10% silently fails to develop. The hard 10% is where companies actually live or die: the incident at 3 a.m., the architecture decision that is expensive to reverse, the performance cliff at scale, the security hole nobody validated.

Regular readers will recognize that number. I made the model-stack version of this argument in The 90/10 AI Stack: open-source models now handle the easy 90% of daily workloads, and frontier models earn their premium only on the hard 10% that genuinely needs them. The talent stack splits exactly the same way. AI absorbs the routine 90% beautifully. The hard 10% does not yield to "ask the model." It yields to someone who has been here before and knows which question to ask first — and that is the supply we are quietly choking.

And the most dangerous part: AI is brilliant at producing answers that are plausible. Plausible is not the same as correct. I went deep on why in The Human and the Machine — the model is a cognitive memory with a belief system and an energy bill; it predicts, it does not verify. Telling plausible from correct — at speed, under pressure, with money on the line — is the single most senior skill there is. The more output your organization generates with AI, the more you need people who can look at a confident, fluent, well-formatted answer and say, "no, that's wrong, and here's why." That skill is built by exactly the friction we are now removing.

So the shortage is not coming because we will have fewer engineers. We will have more, and they will be more productive. The shortage is coming in judgment — the verification, the systems thinking, the ownership of trade-offs — and judgment is the thing you cannot buy your way out of, because everyone will be short at once.

You Cannot Hire Your Way Out of a Judgment Gap

This is where it stops being a philosophical observation and becomes a CEO problem.

If senior judgment becomes scarce across the whole industry at the same time, the market response is obvious: the price of real seniors goes vertical, and you cannot simply outbid your way to a deep bench because there is no deep bench to bid on. The companies that win the next decade will not be the ones who got the most out of AI-assisted speed. They will be the ones who used that speed and deliberately kept growing senior judgment in-house while everyone else let the furnace go cold.

I have said for a while that AI-native organizations will outperform AI-assisted ones. This is a large part of what I mean. An AI-assisted org bolts AI onto its existing workflow to go faster. An AI-native org redesigns the workflow — and the talent model — around the fact that producing code is now cheap and verifying judgment is now the bottleneck. That second org treats senior-making as core infrastructure, not as something that happens by accident on the job.

Why I Still Teach Juniors Myself

Which brings me to the question I get asked, usually with a raised eyebrow: you run a company of 450-plus engineers — why are you personally in a room every week teaching a cohort of ten?

Because I decided I was not willing to bet the next decade on senior judgment forming by accident.

So I run a live program at GeekyAnts — I am calling it Junior to Senior — where I teach the fundamentals the AI era is quietly skipping. Not framework tutorials. The bedrock: how a packet actually crosses an ocean, what the kernel does before your code runs, where state really lives, why "it's slow" is a question and not a problem statement, what a session actually is and why never to trust the client. The things AI will happily answer for you — which is exactly why engineers now grow up never having had to work them out for themselves. One of those sessions — the one where we turned the lens away from the machine and onto the operator's own brain — became The Human and the Machine, if you want a feel for how these run.

The method matters more than the syllabus, and it is built around one rule: don't trust me. I deliberately seed small errors into my own lectures, and the homework is to catch them. I will say something that sounds authoritative — "SHA-1 is the strongest hash we have" — and the assignment is to go find out that it is not. The chapters are the prompt; the homework is the lesson. I split the cohort into two teams building the same product on two different stacks, and at the end nobody gets to present a benchmark they cannot defend. "It handles 500 users" earns the immediate follow-up: how do you know? show me the number. It is the same discipline I built Modern Application Performance 360 around — the real unit, the real bottleneck, the real number.

If that sounds familiar, it should — it is the exact muscle AI is letting people skip. Verification. Skepticism toward a fluent answer. Insistence on the real unit, the real bottleneck, the real trade-off. I am not teaching them to out-code the model. I am teaching them to out-judge it, because that is the job that is about to be scarce.

I do it myself, personally, for two reasons. First, judgment transfers from people who have it, not from documents — you cannot outsource the modeling of how a senior thinks. Second, it keeps me honest. Standing in front of ten sharp juniors who have been told to fact-check me is the best defense I know against a CEO drifting away from how the work actually works.

What I Would Tell Another Leader

If you take one thing from this, let it be that velocity is not the same as depth, and your dashboards mostly measure velocity. Here is what I would watch and do:

Protect some friction on purpose. Not all of it — that would be sadism, and AI-assisted speed is a genuine gift. But identify the moments that actually grow people (the gnarly debug, the design they have to defend, the incident they have to own) and resist the urge to let AI vaporize every one of them. Struggle, in measured doses, is a feature of the talent pipeline, not a bug.

Hire and promote for verification, not just output. In an AI-native team, the rarest and most valuable person is the one who reliably tells plausible from correct. Make that an explicit, rewarded competency.

Treat senior-making as infrastructure. Mentorship, real code review, deliberate teaching of fundamentals — fund it like you fund your platform, because it is your platform. The org that compounds judgment while everyone else compounds output will be the one with people who can handle the hard 10% when it counts.

And get in the room yourself, at least sometimes. Not to micromanage — to keep your own judgment sharp and to model the thing you most need to grow.

AI is the most powerful lever engineering has ever been handed. It will make average teams fast and great teams extraordinary. But it raises the floor for everyone equally, which means the floor stops being where you compete. The ceiling does. And the ceiling is still built the old way — by people with judgment, deliberately grown.

The companies that remember that, while everyone else is busy celebrating their velocity, are the ones I would bet on.

That is why I still teach.

If you are rethinking how your organization grows senior judgment in the AI era — or want to compare notes on running a program like Junior to Senior — reach out at pratik@geekyants.com or geekyants.com.