Hey all, real John here.
The first time I took down production, I was at Microsoft, 26 years old. A senior engineer named Kevin didn’t fix it for me. He pulled up a chair and sat next to me for about 20 minutes while I figured out what I’d done. I hated every minute of it.
It’s still the most useful morning of my career.
Now picture that same kid today, with an agent that finds the bug and ships the fix in 40 seconds. Faster? Absolutely. Better engineer afterward? I’m not so sure.
A while back I wrote about the decline in entry-level hiring. This is a different problem. Even if we keep hiring juniors, we may be taking away the thing that turns them into seniors.
Being Bad at Something Is Part of Getting Good
You didn’t learn to program by reading the answer. You learned by being wrong. You spent hours on a missing semicolon, wrote terrible abstractions, and built things that worked on your machine and exploded the moment someone else touched them.
Somewhere in there, patterns started to click. You learned why one approach beats another. You started anticipating problems before they showed up. You developed judgment, and you got it the expensive way: by living with the consequences of your own decisions.
Now skip most of that. One agent writes the function, another reviews it, a third generates the tests.
Congratulations. You shipped something. But what did you learn?
The Problem Isn’t AI. It’s How We Use It.
I use AI constantly. I’ve built entire systems around autonomous agents, and I think these tools are changing how software gets built for good. Telling juniors to stop using them would be ridiculous.
But there’s a difference between using a tool to accelerate your thinking and using it to replace your thinking. When a junior gets working code and moves on without understanding it, the code works and the engineer hasn’t improved. Repeat that for five years and you get a senior who is great at recognizing good-looking output and has no idea how the system behaves when everything goes wrong.
Those are not the same person.
“We Said This About Compilers”
Sure we did. I can’t build a modern compiler and I don’t understand every transistor in my laptop. I’m fine with that. Abstraction is one of the best things to happen to software.
But here’s the distinction. Good abstractions remove complexity you no longer need to manage. Bad abstractions hide complexity you’re still responsible for.
AI does both, and it doesn’t label which is which. Figuring that out is a job for someone with judgment.
The Real Answer to the Title
So who trains the next generation of senior engineers?
You do. The engineering leader. On purpose.
Here’s the uncomfortable part: it used to happen by accident. Juniors wrote the code, seniors reviewed it, and mentoring was a side effect. Now seniors spend their days reviewing AI output, juniors spend theirs prompting, and the apprenticeship channel is shrinking from both ends. Nobody decided that. It just happened.
If you want seniors in 2031, you have to build the training back in deliberately. Here’s where I’d start:
Predict before you run. Before executing anything AI-generated, the junior writes down what it will do and what could break.
Explain-back reviews. Every AI-assisted PR gets a five-minute walkthrough where the author defends it with the chat window closed.
Own an incident. Put juniors on the on-call shadow rotation and have them write the postmortem. Nothing teaches consequences faster.
Break it on purpose. Hand them working code and ask for three ways it fails in production.
Occasional no-AI work. Not because typing every line is sacred, but because you need to see their independent judgment, and so do they.
This changes how you mentor, how you interview, and what you measure. Stop counting output. Start asking whether they can tell you why it works and what happens when it doesn’t.
The Question I Can’t Shake
AI is eliminating a lot of engineering work, and we’re understandably excited about that. But some of that work was also how we made engineers. Eliminate the work without replacing the learning, and a few years from now we’ll have plenty of people who can operate agents and too few who understand what those agents are doing.
That isn’t inevitable. It is a leadership problem, and it’s one we can start solving now.
So here’s my question for engineering leaders: if AI took 80% of your juniors’ coding tasks tomorrow, what would you teach them instead?
Those people still have to become your next senior engineers, architects, and technical leaders. And I don’t think we can prompt our way around that responsibility.
Go build something amazing. And maybe teach someone else how to build it, too.
John Mann is the founder of Startups and Code LLC, a software engineering executive, and the guy who built Cash Critters for $50/month because constraints are a feature, not a bug. Subscribe for weekly takes on AI, startups, and building things that matter.