The question everyone is asking is: who will be the senior engineers in 10 years?
It’s a reasonable question. But I think it’s the wrong timeframe. The decisions shaping what your senior engineering pool looks like in a decade are not future decisions. They were made in 2023. They are being made right now, this quarter, in budget reviews and headcount conversations happening in meeting rooms and Zoom calls at companies you’ve heard of. And most of those rooms are making the same call without realizing the long-term consequences.
I’ve managed engineering teams long enough to have lived through a few versions of this panic. The talent war of 2021-2022, when we were outbid for mid-levels by companies throwing RSUs around like confetti. The post-pandemic correction, when those same companies collapsed their hiring overnight. You develop a feel for when the industry is about to step on a rake. This feels like that.
What follows is my honest attempt to think through where we’re actually headed, why the optimistic reading keeps getting things wrong, and what I think is the most likely future for engineering talent in the next decade. I’m going to be more specific than “it could go several ways.”
I have opinions. I’ll share them.
The pipeline nobody noticed
For decades, the junior-to-senior progression worked almost automatically.
Not because companies were particularly good at developing talent. Most weren’t. It worked because the environment did the development work. Codebases were messy and undocumented. There was no AI to ask. Production incidents were your responsibility to debug with the logs you had. You sat next to someone more experienced and absorbed how they thought, not because your manager had a development plan for you, but because that was just how offices worked.
I learned more in my first two years from reading other people’s code reviews than I did from any deliberate training my employer offered. The environment created friction. The friction created learning. Managers got credit for development that the situation was quietly doing for them.
Here’s what’s changed: AI has removed most of that natural friction. Junior engineers can now get an implementation in 30 seconds that would have taken them two hours to work through. That’s obviously good for output. It’s not obviously good for learning. When you skip the struggle, you skip the part where the mental model forms.
And simultaneously: there are fewer juniors to speak of. Entry-level tech job postings have dropped by more than 60% since 2022 . Stanford researchers tracked a nearly 20% decline in employment for software developers aged 22-25 from late 2022 to mid-2025. A Harvard study found that in firms actively adopting AI tools, junior employment fell by nearly 8% relative to non-adopters within six quarters. These aren’t rounding errors. An entire cohort is missing.
So we have two things happening at once: fewer people entering the pipeline, and the pipeline itself working less reliably for those who do enter. The compounding effect of that combination is what nobody is quite willing to say out loud.
Why the optimistic reading keeps failing
The hopeful version of this story usually goes like this: every abstraction layer was supposed to be the end of entry-level programming, and it never was. Machine code gave way to assembly, assembly to higher-level languages, the browser brought JavaScript, the cloud abstracted away infrastructure. Each time, instead of collapsing the entry points, the new layer created different ones.
I find this argument genuinely compelling as history. I find it much less compelling as forecast.
The thing about previous abstraction layers is that they made programming accessible to more people, not just faster for existing programmers. BASIC on home computers meant a generation of teenagers could start coding on their own. JavaScript in browsers meant designers could learn to program without setting up a build environment. Each layer lowered the floor and expanded the population.
AI does something categorically different. It doesn’t lower the floor by making concepts easier to learn. It lowers the floor by letting you skip the concepts entirely. You can ship working software without understanding what it does. That is genuinely new (and harmful/dangerous on many levels, but that’s for another post…).
There’s a real version of the optimistic scenario where new entry points emerge that we haven’t imagined yet. Maybe product engineers who orchestrate AI become the new juniors. Maybe the skills required shift enough that a whole new population can participate. I hold that possibility open.
But I don’t think you can bet a talent strategy on “maybe.” And more importantly, I think we need to be honest about what the data is already showing.
Three predictions, not three scenarios
Most writing on this topic offers you a menu of scenarios and declines to pick one. That’s intellectually safe. It’s also not very useful.
Here’s what I actually think is going to happen, in roughly the order I expect it to unfold.
First: a two-tier labor market, arriving faster than expected
This is already beginning. It won’t look like a sudden bifurcation. It will look like a gradual widening.
- On one side: engineers who have judgment, system intuition, the ability to debug things they’ve never seen before. Engineers who were formed by years of actual struggle with real systems, who can hold the architecture of a large codebase in their head, who have a feel for when something is about to go wrong before it does. These people are already scarce. They will become scarcer.
- On the other side: engineers who are highly productive with AI tools, competent at composing features from components, good at moving fast. Not incapable, but shallow in ways that don’t show up until you hit a real systems problem, a production incident at 2am, a migration that needs careful sequencing across a distributed system with three years of accumulated decisions baked in.
The gap between these two groups is already visible to anyone managing teams. What changes by 2028 or so is that the gap becomes a chasm. The companies that have been running lean on senior headcount for a few years start to feel the absence. The engineers who can do the hard things become significantly more expensive. And the engineers who grew up purely on AI assistance hit ceilings they don’t fully understand.
I want to be careful here. I’m not saying the AI-native engineers are less valuable. In many roles they’ll be more than enough. But for the work that actually requires engineering judgment - and that work will still exist, probably more of it as systems become more complex - the shortage will be real.
Second: a talent war in 2029-2031 that makes 2021 look mild
The 2021-2022 hiring boom happened against a backdrop where the pipeline was still functioning. There were plenty of engineers at every level; the issue was that everyone wanted them at once.
What happens when you add a structural pipeline shortage to high demand? The competition concentrates at the top of the distribution. Senior engineers with genuine systems depth will be fought over by companies who realize, too late, that they don’t have enough of them. Compensation will spike in ways that feel absurd at the time. Retention will become the primary engineering leadership challenge for several years.
I’ve been in that environment before, and it’s grinding. You spend more time on compensation strategy and counteroffers than on anything technical. Your best engineers get calls weekly. The institutional knowledge embedded in the people you’ve developed walks out the door when someone offers them a 40% raise.
The companies that will be in the best position are the ones that kept developing engineers through the lean years, even when it felt expensive and unnecessary. They’ll have mid-levels they grew into seniors. They’ll have seniors who know their systems deeply because they’ve been there long enough to accumulate the context. Everyone else will be competing for the same thin pool of external hires.
Third: a correction in how the industry thinks about AI and skill formation, probably around 2030-2032
I think we will look back on the 2024-2027 period the way we now look back on the early days of GPS in cars. Remember when people thought GPS would make navigation skills obsolete? Then people started driving into lakes because they followed their satnav off a pier. There was a period of recalibration.
I expect something similar with AI and engineering skill formation. Not a rejection of the tools. The tools are genuinely transformative, and some productivity gains are real. But a serious reckoning with the second-order effects.
The evidence is already starting to accumulate. Stack Overflow’s data shows positive sentiment toward AI tools dropped from above 70% in 2023-2024 to 60% in 2025. A large share of developers report that debugging AI-generated code takes longer than writing code from scratch. The bugs are different: they look plausible, they often pass review, and they fail in edge cases that require understanding the system to catch.
My prediction is that by the early 2030s, the most forward-thinking engineering organizations will have developed explicit curricula for building judgment - not just productivity. They’ll treat AI assistance and depth-of-understanding as separate axes to develop deliberately, rather than assuming the first produces the second.
The organizations that figure this out first will develop stronger engineers faster than the ones that don’t. Not because they reject AI, but because they use it with a clear model of what it does and doesn’t teach.
What the 2035 picture actually looks like
Put all three of these together and here’s what I think the engineering talent landscape looks like in ten years.
The sheer number of people writing code will have expanded significantly. AI tools will have lowered the floor enough that product managers, designers, and domain experts routinely build functional software. In that sense, the optimistic “democratization” reading will have come partially true.
But the engineers who can reason about complex systems, manage large codebases over time, make architectural decisions with long-term consequences, and debug hard failures under pressure - those engineers will be a smaller proportion of the overall field than they are today. And the absolute number in that category will depend heavily on choices being made between now and 2028.
Charity Majors put it well : “Being a senior engineer is not primarily a function of your ability to write code. It has far more to do with your ability to understand, maintain, explain, and manage a large body of software in production over time.” AI has accelerated code writing significantly. It has done very little for the rest of what seniority actually means.
The companies that understand this distinction - and act on it now - will be positioned well. The ones that conflate productivity with capability will feel fine through 2027 and start hurting around 2030.
The thing that worries me most
I’ve watched a few rounds of the industry eating its seed corn and convincing itself it was making a rational trade. The post-2022 layoffs hit engineering managers and tech leads disproportionately hard. The implicit logic was: we can run leaner, we have AI, the seniors can cover more ground.
What got cut in many of those rounds wasn’t just headcount. It was the connective tissue of a team: the people who did the knowledge transfer, who ran the design reviews, who had enough context to mentor early-career engineers while still shipping. When you cut that layer, you don’t see the damage immediately. You see it eighteen months later when your juniors are blocked on things nobody knows how to answer, when your senior engineers are burning out because they’re carrying the entire weight of technical decision-making alone, when the institutional knowledge that was being passed down just… stops.
The same dynamic is playing out at the junior level, and I think the timescales involved mean we won’t fully see the consequences for years. A 22-year-old who couldn’t get a job in 2024 didn’t disappear. Some of them found their way in eventually. Some changed careers. Some are brilliant engineers who just needed a different entry point.
But there’s a cohort - I genuinely don’t know how large - who got priced out of the profession entirely during the hiring freeze. Those are the engineers who would have been mid-levels by 2028 and seniors by 2033. That pool is smaller than it should be. And the knowledge and habits they would have built during those early, formative years can’t be reconstructed later.
I find this genuinely sad, not just strategically worrying. The early years of an engineering career are formative in ways that go beyond skills. The sense of what good engineering culture looks like, the norms around code quality and documentation and incident response - these get embedded early. A generation that missed that formation is navigating its careers without a north star that many of us take for granted.
What I think you should actually do
The honest answer is that individual companies can’t fix a systemic pipeline problem. If the industry collectively under-hired juniors for four years, no single organization can compensate for that. What you can do is position your team well relative to the broader shortage.
A few things I think are worth doing now, not as a checklist but as a genuine shift in how you think about talent.
Treat junior hiring as risk mitigation. Not charity, not altruism. The engineers you develop over the next three years are your insurance against the talent war I think is coming. The cost of growing someone from junior to senior over four years is significantly lower than the cost of competing for experienced engineers in a constrained market. (Run that math explicitly in your planning. Leadership tends to respond better to projected future cost than to abstract arguments about pipelines. “Here’s what we’ll be paying a senior engineer in 2029 if we haven’t grown any internally” lands differently than “we should invest in people.”)
Don’t assume the conditions for growth are present. This is the part I see most managers miss. They hire a junior, point them at a Jira board, and assume the environment will do the development work. It used to. It doesn’t anymore.
The natural friction that formed engineers - the undocumented codebase, the slow feedback loops, the production incident you had to debug with nothing but logs and intuition - has been reduced by AI tooling. That friction was annoying. It was also pedagogically essential. When you skip the struggle, you skip the part where the mental model forms.
So you have to reconstruct the friction deliberately. Not by withholding AI tools - that’s counterproductive - but by designing the work for learning, not just output. Give people ownership of problems where the hard part is figuring out what to build, not just how to build it. Pair them on architecture discussions where the ambiguity is real. Let them run the post-incident review rather than just attending it. Make them write the runbook before the incident happens. The goal is to ensure AI is a tool they’re steering, not a crutch doing the thinking.
I’ve seen this done well a few times. The managers who do it well share a common trait: they think explicitly about what skills they’re trying to build in each person, and they choose work assignments accordingly. They’re playing a longer game than the sprint.
Invest in making knowledge visible. The institutional knowledge in your most experienced engineers’ heads is the most irreplaceable asset you have. It can’t be hired externally. It degrades slowly when people leave or move into management. And most organizations have almost no systematic way to transfer it.
The barrier to doing this has genuinely never been lower. AI makes writing, diagramming, and explaining dramatically easier. A two-hour architecture review where a senior engineer talks through a system can be transcribed, summarized, and turned into documentation before the meeting ends. What used to require significant willpower to produce can now happen almost as a side effect of normal work, if you build the habit. Make it a first-class expectation, not an optional nicety.
Track your knowledge concentration. How many people on your team can independently debug your three most critical services? What’s your bus factor on your oldest, most important codebase? If the answer to either question is “one or two,” you have a fragile organization - and the fragility compounds over time if you’re not actively moving knowledge around.
And if you’re an individual contributor: the gap between those who have genuine depth and those who have AI-assisted productivity will widen for the next several years. The engineers who will be most valuable are not the ones who ship the most features today. They’re the ones who can reason about hard problems independently, who understand why systems fail, who have accumulated enough context about real software in production to have genuine instincts.
Seek the hard problems. Volunteer for the migration nobody else wants. Stay on the post-incident review long enough to actually understand what happened, not just to mark it resolved. When the AI gives you an answer, take the time to understand why it’s right - or whether it’s right at all. The discomfort of not immediately knowing is exactly where the growth happens. Don’t outsource it.
The choice that’s already being made
Here’s what I keep coming back to.
The senior engineers of 2035 are not a future problem. They are people who are somewhere in the industry right now, or who tried to enter the industry and were turned away, or who are making decisions right now about whether software engineering is a viable career. The conditions that will determine whether they develop into exceptional engineers are being created today.
Every company that freezes junior hiring is making a choice about 2033. Every manager who stops investing in early-career development because AI covers the gap is making a choice about 2031. Every organization that measures engineering output purely in velocity without asking whether the people producing that output are growing is making a choice it won’t fully feel for years.
I think most of those choices are being made without a clear view of their consequences. Not maliciously. Just with the usual human preference for short-term clarity over long-term uncertainty.
The irony is that the companies best positioned for 2035 won’t look obviously superior in 2026. They’ll look slightly less efficient. They’ll be carrying some overhead in the form of junior engineers who aren’t yet fully productive. Their senior engineers will spend some time on mentorship that doesn’t show up in sprint velocity.
And then 2029 arrives, and the talent war starts, and those are the teams that already have the people they need.