Who will be the senior engineers of 2035?

And what do we need to do about that right now?

This month, we’re going to explore a question that is a pertinent topic right now: where are the senior engineers of the future going to come from?

After years of post-Covid layoffs, hiring has slowed across the board as companies wait to see how AI efficiency gains and the economy play out. Unfortunately, juniors are caught up in that slowdown: it’s a hard time to be graduating with a computer science degree.

Meanwhile, AI is absorbing the small changes and bug fixes that used to be perfect training tasks for junior engineers, and the managers who traditionally developed early-career talent are stretched thin or being cut entirely. When viewed purely as profit and loss, some short-term rationale can be derived. However, the long-term consequences are worrying.

We’ll start by looking at the pipeline we used to have: how senior engineers traditionally emerged through years of mistakes, mentorship, and low-stakes learning. Then we’ll examine what’s replacing it, and hypothesise whether AI will actually fill the gap. We’ll explore three possible scenarios for 2035, and finish with what this means depending on where you sit in the industry.

If you’d like to dig deeper, here are some related articles from the archive:

• Coaching explores how managers develop people at different experience levels, and why the approach needs to change as someone grows.

• Delegation creates career progression looks at how handing over tasks is an act of trust and an opportunity to learn.

• Use it or lose it covers the risk of skill atrophy in the AI era, and why deliberate practice still matters.

Let’s explore.

The programmer’s path

For decades, the path was well-worn: you got hired as a junior, paired with someone more experienced, and were given tasks that existed as much for your development as for the work itself.

As part of your ramp-up into real-world programming, you’d follow this loop: write some code (often pairing with others), submit a pull request, get feedback that made you rethink your approach, fix it, and learn something. Over time, through repetition and correction, you built judgment: one of the key skills that separates senior engineers from those with less experience.

Learning with other people was not the only path. Some of the most influential figures in computing taught themselves to code before they were adults, tinkering with whatever hardware they could access; learning through curiosity and obsession rather than formal training. I was no different (although I do not claim to be influential): I learned to code on our family computer, building websites with HTML and simple tools in Visual Basic.

Yet, although they may have begun alone, many autodidacts eventually joined or created teams and companies, and there they learned a different set of lessons: how to collaborate, how to navigate trade-offs, how to build things that outgrow your singular contributions. And these are things that are very hard to learn in formal education or on your own.

However, what both paths shared was this: you had to do the work yourself and with others, and the doing was the point.

What’s replacing it

The traditional pipeline is breaking down in several places at once. Hiring freezes, driven by post-pandemic correction and uncertainty about AI’s impact on headcount, mean fewer junior roles: entry-level tech postings have dropped 67% since 2022, and a Stanford study found that employment for software developers aged 22-25 has declined nearly 20% from its late 2022 peak.

A Harvard study found the effect is even sharper in firms actively adopting AI: junior employment fell 7.7% relative to non-adopters within six quarters. The managers who used to mentor early-career engineers are being cut or stretched across larger teams. And the tasks that once served as training ground, such as the small bug fixes and incremental features, are increasingly being handed to AI tools instead.

For leadership purely concerned with cost, the assumption is compelling: AI will keep improving, so we’ll need fewer humans, so why invest in growing them? A LeadDev survey found that 54% of engineering leaders plan to hire fewer juniors, reasoning that AI enables seniors to handle more.

On a balance sheet, the short-term economics make sense. But there’s an incredibly important question that needs to be addressed: what happens to the skills that juniors used to develop along the way, if AI is taking them and there are fewer juniors to do them in the first place?

The answer matters because much of the judgment of an experienced craftsperson comes through being in the details, making mistakes, and learning from them.

Consider judgment under ambiguity, organisational navigation, the instinct for when a shortcut will come back to bite you and when it’s the right call; these aren’t skills you acquire by reading documentation or even prompting AI for answers, but through years of making mistakes in environments where the stakes were low enough to fail safely.

There’s a term that comes to mind for how one progresses from junior to senior: scar tissue. The scars come from shipping something that broke in production and staying up to fix it, from proposing an architecture that didn’t scale and having to rebuild it, from navigating a difficult stakeholder relationship and learning, the hard way, what actually works.

AI can answer questions in the same way that revising for an exam can help you memorise an answer, but it can’t give you the scars that you can then apply to new problems in the future.

So what happens if we continue down this path? There are a number of possibilities that could all prove true to some degree. Analysing them, and where they could lead, is one of the ways we can steer towards a future that makes sense for the industry.

Three possible futures

The talent crunch. We’ve seen a version of this before. During the pandemic hiring boom of 2021-2022, tech job postings more than doubled and salaries hit record highs. Top candidates fielded multiple offers; poaching was rampant. Companies that weren’t seen as desirable places to work found themselves outbid by those that were.

Now imagine that dynamic, but worse. Senior engineers don’t appear from nowhere: they’re the juniors you hired five or ten years ago who learned, failed, recovered, and grew.

Cut the pipeline today, and the shortage doesn’t show up immediately. Instead it shows up in 2035, when the industry finds itself desperate for engineers with the scar tissue that comes from years of real-world experience. When the critical system goes down at 3am, there’s no one left who knows how it works. The parallels to other industries that neglected their pipelines, such as nursing and skilled trades, become impossible to ignore.

The bifurcation. Instead of a shortage, a split emerges. On one side: vibe coders who move fast, shipping features by orchestrating AI tools, comfortable with velocity but shallow on fundamentals. On the other: engineers who understand how things actually work, but who are increasingly rare and expensive.

The middle disappears. A HackerRank advisory board described this as a “hollowed-out career ladder”: seniors at the top, AI handling the grunt work, and very few people learning in between. The traditional path from junior to mid-level to senior breaks down because the rungs in the middle are gone.

This pattern shows up elsewhere. Economists have documented job polarization for decades: automation eliminates middle-skill routine work while high-skill and low-skill jobs grow. The same dynamic appears in wealth distribution, where the middle class has steadily shrunk across developed economies. In retail, analysts call it the barbell economy: luxury and discount thrive while the mid-market hollows out. Software engineering may be next.

The tinkerer’s precedent. There’s a more optimistic reading, grounded in computing history. Formal computer science education was still in its infancy: Cambridge offered a diploma-level course from 1953, but the first dedicated department wasn’t established until 1962 when Purdue established theirs. The first undergraduate degree followed in 1967. Yet computing advanced for decades before that, driven by aforementioned autodidacts who taught themselves from manuals, blueprints, and tinkering: messing around for curiosity’s sake.

Each new abstraction layer was supposed to be the end of entry-level programming. Before software existed at all, “computers” were humans doing calculations by hand. Then came machine code, then assembly, then BASIC: created at Dartmouth for liberal arts students, it came pre-installed on home computers and enabled a generation of bedroom coders.

The browser brought JavaScript, which democratised web development. Cloud computing abstracted away infrastructure. Each time, instead of eliminating entry points, the new layer created different ones. And with each step up, we wouldn’t wish to go back: would you want to write everything in assembly today? I thought not.

If AI follows the same pattern, we could see a world where everyone becomes part product manager, part engineer, part designer. Building software gets faster, and the bottleneck shifts elsewhere: to sales, to go-to-market, to the hard work of finding customers and convincing them to pay. The constraint moves, but it doesn’t disappear.

There’s an alternative version of this future: the number of software engineers a company needs seriously dwindles, teams of fifty become teams of five, and average company size shrinks. The engineers who thrive are the entrepreneurial ones, those who can ship whole products rather than just features. Everyone else competes for fewer and fewer seats.

What makes this scenario different from the first two is that it still offers a path. Each earlier abstraction layer required you to understand programming logic; you were just expressing it at a higher level. AI potentially abstracts away programming itself: describe what you want and let the model figure out how. That could mean the ultimate democratisation, or the elimination of the ladder entirely. But if history is any guide, new entry points will emerge, even if we can’t yet see what they look like.

What this means for you

Which scenario plays out, and in what combination, depends partly on choices being made right now: not just by industry leaders, but by individuals at every level, including yourself.

We still have years ahead in which these effects will compound, and that means years in which deliberate choices can steer us toward a better future than the one we might waltz into without thinking. Here’s what you can do depending on where you sit.

If you’re a senior engineer, your expertise is becoming scarcer, not more common. This is an extremely strong position to be in, especially if you’re investing heavily in AI-first engineering skills. The scar tissue you’ve accumulated, the instinct for where the edge cases hide, the ability to debug systems you’ve never seen before: these take years to develop and can’t be downloaded. Three things you can do:

• Mentor actively. Find a junior and invest in their growth, even if nobody’s asking you to. This is actually more fun than it used to be: you’re exploring AI tooling together, learning alongside each other rather than just handing down wisdom.

• Make your knowledge visible. Use AI to generate excellent documentation and diagrams, and use it to level up the knowledge you transfer to the rest of the organisation. The tribal knowledge in your head is worth far more when it’s shared, and the barrier to doing so has never been lower.

• Invest in engineering-led initiatives. The increased velocity you get through AI has to go somewhere. Instead of just shipping more features, use that time to work on the problems that often get deprioritised: performance, latency, resilience, and the kind of deep technical work that builds lasting competitive advantage.

If you’re a manager, the juniors you develop aren’t a cost centre; they’re a strategic bet. Every engineer you grow into a capable mid-level or senior is one you won’t have to poach from a competitor when the talent crunch bites. Remember the 2021-2022 hiring war? It could look mild by comparison. Three things you can do:

• Make the case for junior hiring. Frame it as risk mitigation, not charity. Show leadership the cost of senior attrition, the salary inflation in the market, and what happens when institutional knowledge walks out the door. Juniors are cheaper to hire and, with good mentorship, can become your most loyal senior engineers.

• Rethink what training looks like. The tasks that used to be training ground are being absorbed by AI. So create new ones: pair juniors with seniors on complex problems, give them ownership of small but real projects, let them lead incident retrospectives. OpenAI is experimenting with a “super senior + super junior” model for exactly this reason. The goal is scar tissue, not busywork.

• Invest in your own internal tooling. AI has made building custom tools almost as easy as building a spreadsheet. Instead of waiting for engineering to prioritise your visibility needs or settling for off-the-shelf software that doesn’t quite fit, build the tools yourself. Whether it’s a planning dashboard, a bragdoc generator, or a way to track knowledge distribution across the team, the friction between “I wish I had a tool for this” and actually having it has never been lower. I covered this in detail in Just build the tools yourself.

If you’re early in your career, the path is harder than it used to be, but it’s not closed. The key is to seek out the experiences that build judgment, even when the system isn’t handing them to you. Three things you can do:

• Seek scar tissue deliberately. Volunteer for on-call rotations. Take the messy migration project nobody else wants. When something breaks, be the one who stays to understand why. None of this is new: the tooling changes and the level of abstraction shifts, but the engineers who learn the most have always been the ones actively seeking scar tissue.

• Don’t outsource your understanding. AI tools are incredible accelerators, but they can also become a crutch. When the model gives you an answer, take the time to understand why it works. Read the documentation. Trace the code path. The goal isn’t to reject AI; it’s to use it without losing the ability to think for yourself. I wrote about this in Use it or lose it.

• Connect your work to the business. The engineers who get trusted with bigger problems are the ones who understand why those problems matter. Learn what your company’s metrics are, how your team contributes to them, and what keeps your leadership up at night. Then be proactive about getting closer to that work. Ask to be included in architecture discussions, request to shadow incident response, and when you get feedback, ask “why does this matter?” not just “what should I change?” Technical skill gets you in the door; business context gets you to the table.

If you’re a senior leader planning to spend more on AI than on people, you’re making a bet, whether you’ve articulated it or not. The bet is that AI will improve faster than your talent base depreciates: that you can cut junior hiring today and still have the senior engineers you need when it matters. That may be true. But if it isn’t, you won’t know until it’s too late to fix. Three things you can do:

• Stress-test your assumptions. What happens if AI progress plateaus for a few years? What happens if your most experienced engineers leave? What does your team look like in 2035 if you hire no juniors between now and then? Run the scenarios. The answers might surprise you. Why not use AI to do the modelling?

• Treat junior hiring as R&D, not overhead. The return on investment isn’t immediate, but it’s real. Every junior you develop into a senior is institutional knowledge you don’t lose when someone resigns. And some of the best junior talent right now, especially those who are AI-first, are incredible at their jobs, hungry to learn, and waiting for the right opportunity to come along. Frame junior hiring as investment, not cost, in your planning.

• Measure your knowledge concentration. How many people on your team can debug your most critical systems? What’s your bus factor on key services? If the answer is “one or two,” you have a fragile organisation, regardless of how productive AI makes those individuals. Track knowledge distribution the way you track uptime.

Wrapping up

Who will be the senior engineers of 2035? We don’t know yet. We’re running an experiment on the industry’s talent pipeline, and the results won’t be in for years.

But here’s what we do know: the outcome isn’t predetermined. The senior engineers of 2035 are being made right now, in the decisions about who gets hired, who gets mentored, and who gets the chance to fail safely.

Until next time.