Who’s Training the Next Generation of Engineers?

We’ve spent years talking about automation. Removing toil, improving efficiency, accelerating delivery. All worthwhile goals. No argument from me on any of it.

And I wouldn’t trade the productivity gains AI gives me. I can build a tool in hours that might previously have taken weeks. That’s awesome.

But I also have decades of experience telling me what that tool should look like, how it should behave, what might go wrong, and which seemingly harmless decisions could become tomorrow’s operational headache. That experience didn’t arrive with a job title. It came from years of doing the work, making mistakes, fixing things, and gradually learning to recognise problems before they became problems.

Which leads to a question I can’t shake. Perhaps we’ve become so focused on automating the work that we’ve stopped considering what the work was teaching the people doing it.

Because here’s the thing. It’s not that AI replaces juniors. It’s that AI is quietly eating the exact work that turned juniors into seniors in the first place. We’re keeping the productivity. We might be throwing away the apprenticeship that came with it, and I’m not sure anyone has noticed yet.

Let me say up front: this isn’t an anti-AI rant. I use these tools every day, and they’re genuinely good.

The productivity is real, and I’m not pretending otherwise

AI can grep through ten thousand lines of logs and make sense of a stack trace faster than I can. Hand it a cryptic OOMKilled, let it cross-reference the resource limits in a Helm chart, and it’ll point at the misconfigured requests block before I’ve finished reading the first message in the incident channel. Tell it a service can’t write to a particular S3 bucket and it’ll have traced the service account and the relevant IAM policies blocking it while I’m still trying to remember the right aws CLI command to check. It’ll read a sprawling GitHub issue, follow the linked PRs, and summarise three years of context while I’m still making coffee. Ask it for Terraform, a Dockerfile, a half-sane CI pipeline, and it’ll produce something that mostly works.

For an experienced engineer, that’s brilliant. It takes the tedious parts of the job, the boilerplate, the log-diving, the “I know this is a one-line fix, I just have to find the line” work, and makes them disappear. It frees me up to think about the things that actually need thinking about.

So the problem isn’t that AI is bad at the work. The problem is what happens to the people who used to do that work to learn.

Nobody called it an apprenticeship, but that’s what it was

I didn’t become a halfway competent engineer by reading books. I became one by doing the boring, routine work, and slowly, painfully, building a feel for how things actually behave.

Chasing a flaky test at 2am. Skimming through gigabytes of log files until the pattern finally jumps out at you. Fixing the “one-line” bug that turned out to be a complete misunderstanding of how the retry logic worked. Writing the unglamorous glue code and the Terraform modules nobody else wanted to own. That’s where it happens.

That work was never really about the output. It’s how you learn what “normal” looks like, by staring at a lot of boring, healthy dashboards until the unhealthy ones feel wrong. It’s how you learn how systems actually fail, as opposed to how the documentation claims they fail, usually by being the unlucky one holding the pager when they do. You build those mental models one bad deploy and one 3am page at a time.

And that’s exactly the work we’re now handing to AI, precisely because it’s routine and easy to delegate. Which is another way of saying we’re handing over the work that used to teach people.

AI gives you an answer. It doesn’t give you context.

Here’s the bit I think gets quietly overlooked.

AI will happily give you a technically correct solution. What it won’t do is tell you that the technically correct solution is the wrong one for your setup, because it doesn’t know your setup. It knows the training data: the average of every blog post, tutorial and Stack Overflow answer ever written. And the average is almost never the right answer for a specific environment.

Here’s what I mean in practice.

Say I hand you a container image and tell you to get it into production. Ask an AI how to run a container in production on AWS and there’s a decent chance it reaches for ECS, or suggests Fargate, complete with a new VPC and a brand new AWS account to put it in. All of it correct. All of it plausible. All of it the sort of thing that reads beautifully in a getting-started guide.

And all of it completely wrong if your organisation already runs a well-architected Kubernetes platform, with observability, autoscaling, network policy and security controls already built in and already paid for. The right answer here isn’t “go build new infrastructure.” It’s “write a deployment manifest, drop it in the GitOps repo, and let the platform do the job it was designed to do.”

A senior engineer who knows the environment sees that straight away. They’re not just asking “does this work?”, they’re asking “does this fit?” Does it match how we already run things? What does it cost to operate? Who’s getting paged for it at 3am? Same thing with application code: a senior reads the AI’s output and spots the line that quietly breaks a business rule, or the input that never gets sanitised, because they’re carrying context the model simply doesn’t have.

A junior, more often than not, takes the first plausible answer and runs with it. Not because they’re careless, but because they don’t yet know that “does this fit?” is even a question worth asking. You can’t push back on an answer when you’ve got nothing to compare it against.

So here’s the trap. AI produces answers that need experienced, context-aware judgement to evaluate, while quietly removing the hands-on work that used to build that judgement. And that experience was never free. It came from doing things the hard way: standing the infrastructure up, breaking it, running it, and slowly working out why the environment ended up shaped the way it is.

If juniors never do that work, I genuinely don’t know where the judgement is supposed to come from. You can’t supervise what you’ve never learned to do, and you can’t challenge an AI if all you’ve ever done is accept what it hands you.

The ten-year problem

The reason this is dangerous is that it doesn’t hurt now. It hurts later.

Today’s senior engineers are fine. They already did their time, long before any of this existed. Give them a fleet of AI agents and they get scarily effective, because they know what good looks like and they know when the machine is confidently wrong. No complaints there.

The trouble is the generation behind them, and it creeps up slowly.

Think about the economics for a second. When one senior can supervise a swarm of agents and ship what used to take a team of six, the obvious move is to stop hiring the six. Why pay for juniors doing routine work when an agent does it faster and cheaper? So the entry-level roles quietly evaporate. Not in some dramatic round of layoffs, but through a hundred individual headcount decisions that each look perfectly sensible on their own.

Except those entry-level roles weren’t just cheap labour. They were the training ground. They were where the next round of seniors was supposed to come from.

So what happens in ten years, when today’s seniors retire or move on, and we never created the roles their replacements could have grown up in? You can’t hire your way out of a shortage that every company manufactured at the same time, for the same reasons. You can’t shortcut the years of context-rich judgement the AI cheerfully skipped. And you won’t notice the hole until the day you badly need someone who can look at an agent’s output and say “no, not here, not like that”, and realise nobody in the building ever learned how.

It’s a slow-moving risk with a long lead time. Which, let’s be honest, is exactly the kind of risk organisations are worst at taking seriously.

So what do we actually do about it?

Abandoning AI isn’t the answer. That would be stupid, and it would undercut everything I just said about how useful it is.

The real answer is to get deliberate about something that used to happen by accident. For years we never had to think about how juniors learned, because they learned as a side effect of doing the work. That side effect is drying up, so we have to recreate it on purpose.

In practice that might look like:

• treating some routine work as training, even when an agent could do it faster;
• having juniors critique and debug AI output rather than just consume it;
• deliberately rotating people through the messy, diagnostic work where judgement actually gets built;
• measuring whether people are growing, not just whether tickets are closing;
• and being honest that growing an engineer is an investment with a slow payback.

None of that is free. It trades a bit of short-term productivity for long-term capability. Which, funnily enough, is exactly the kind of trade-off engineering leaders are supposed to be good at making.

The question worth sitting with

We might be heading for a future where one senior engineer supervises a dozen AI agents and gets through what used to take a whole team. Genuinely impressive. Real progress.

But we spent all those years automating the work without ever really asking what the work was teaching the people doing it. That cost doesn’t land today. It lands the day we need someone who can look at an agent’s output and say “no, not here, not like that”, and find that nobody in the building ever learned how.

Productivity today shouldn’t quietly cost us the capability we’ll need tomorrow.