What AI Won't Teach a Junior

Part 2 of 3 — a series on mentoring juniors in the AI era

In Part 1, I argued that AI didn't kill the junior role. It killed the runway.

The mechanical tasks juniors used to learn on — boilerplate, CRUD, simple integrations — those still exist, but they don't carry the same educational weight. A junior can ship them now without ever paying the cognitive price that used to come bundled in.

This post is about what's in that bundle.

Because the boilerplate wasn't the lesson. The boilerplate was the delivery mechanism for the lesson. And there are at least three skills that used to ride along for free — skills AI cannot teach, no matter how good the model gets.

Or, more precisely: AI can explain these skills. It can even simulate parts of them. But it won't force a junior to practice them the way the old workflow did.

If we don't teach them deliberately, juniors won't pick them up at all.

1. Reading code you didn't write

The first casualty is the one most people miss, because it doesn't look like a skill. It looks like a chore.

But reading unfamiliar code — really reading it, not skimming it — is how developers build their internal map of a system. You see how the codebase actually behaves, not how it claims to behave. You see the half-finished abstractions. You see the workarounds someone left for a reason you don't yet understand.

The old junior couldn't avoid this. To add a CRUD endpoint, they had to read the five existing ones. To fix a small bug, they had to follow a function call through three files. They didn't choose to read the code — the code stood between them and the task.

A junior with AI rarely has to do that. AI reads the codebase for them. AI suggests the pattern. AI writes the diff. The junior reads the output, maybe.

That mental muscle — the one that lets you open an unfamiliar file and form a working theory of what it does within a minute — atrophies fast when you stop using it.

And here's the part that hurts: this is also the foundation of meaningful code review.

Code review isn't really about whether the code is correct. Linters and types check correctness. Code review is about why this pattern here, and not that one. About whether the choice fits the system's existing logic. About whether the author understood the constraints, or just satisfied them by accident.

You can't do that review if you can't read code. And you can't learn to read code by watching AI write it.

2. Debugging someone's reasoning, not just their code

This is, in my view, the most underrated skill in software engineering.

When a senior looks at a junior's PR and the code works, the senior doesn't stop there. They ask: why did you do it this way?

That question isn't pedantic. It's the entire job.

Because "works" has two very different meanings. Sometimes "works" means the developer understood the problem, considered alternatives, and picked the right trade-off. Sometimes "works" means the developer got lucky — the test passed, the happy path runs, and the next bug is just sitting there waiting for an edge case to find it.

These two outcomes look identical in a diff. They look identical in CI. They only diverge under pressure — production load, a weird input, a refactor six months later.

The way you tell them apart is by interrogating the reasoning, not the code.

This is what seniors do, mostly unconsciously, every time they review a PR. Why this data structure? What happens if this is null? Did you consider doing it the other way? What made you stop here?

A junior writing their own code at least had reasoning to defend. It might have been bad reasoning, but it was theirs. They could be walked through where it broke down.

A junior shipping AI-generated code often has nothing to defend. The code appeared. They accepted it. If you ask why this pattern and not the other one, the honest answer is "I don't know — that's what it gave me."

That's not laziness. That's a learning environment problem. Nobody has shown them how to own code they didn't write — to inspect it, push back on it, treat it as a hypothesis instead of an answer.

And until they learn that, "works" will keep meaning "got lucky."

3. Translating a problem before solving it

The third skill is the one furthest from the keyboard, and the one AI is worst at supplying.

AI is excellent at solving a clearly specified problem. The harder, messier part of the job is figuring out what the problem actually is.

A product manager says: we need a way for users to export their data.

The senior hears five questions inside that sentence. Which users — all of them, or a segment? Which data — what they entered, or what we derived? Export to what — a download, an email, an API? How often — once, scheduled, on demand? And the one that decides everything: why do they want it, and what will they do with the export?

A junior who's been in the room for a hundred of those conversations will hear the same questions. A junior who hasn't won't. They'll take the sentence at face value, hand it to AI, get back a CSV download button, and ship something that technically matches the request and completely misses the point.

You don't learn this by writing more code. You learn it by sitting next to people who push back on requests. By watching a product discussion go from a vague want to a concrete contract. By being there when an engineer asks what problem are we actually solving and the room realises nobody knew.

These conversations used to happen around juniors constantly, because juniors sat in on planning, refinement, incident reviews, retros. They still happen — but the link between "being in the room" and "doing the work" has gone soft. If the work is mostly AI-mediated execution, the room stops feeling load-bearing. And the skill that grew there stops growing.

What these three have in common

I picked these three deliberately, and not because they're an exhaustive list.

I picked them because they share a property that explains the whole problem.

You used to get all three of them for free.

You couldn't write an endpoint without reading the other five. You couldn't debug a ticket without entering someone else's head. You couldn't ship a feature without first asking the PM what they actually meant.

The boilerplate was the bill, and the skills were the change you got back.

That economy is over. The bill is gone. So is the change.

Which means anything we want a junior to learn now, we have to teach on purpose. Not as a side effect of giving them work. As an explicit part of how we run the team.

That's a different job for tech leads than most of us signed up for. The mentoring playbook most of us inherited assumed the work itself was doing half the teaching. It isn't anymore.

So what do we actually do about it

This is where Part 3 lives, and I won't try to compress it into a paragraph here. But the shape of the answer is already visible in the three skills above.

If reading code, debugging reasoning, and translating problems are the things AI won't teach, then those are the things we have to design the work around. Not the deliverable. The deliberate practice.

That means the tasks we give juniors need to be chosen differently. The way we review their PRs needs to ask different questions. The way we let them use AI itself needs structure — because the same tool can either accelerate learning or hollow it out, depending on how it's introduced.

I've been working on a way to think about this — a progression for how a junior should relate to AI over time, with the mentor in the loop at each stage. That's the next post.

For now, the takeaway is smaller and sharper:

The runway is gone. The free lessons are gone with it. If we want juniors who can read code, defend their reasoning, and translate a problem before attacking it, we have to teach those things — not hope they show up as side effects of shipping tickets.

The juniors will be fine. They're not less capable than we were.

But we have to be better mentors than the ones we had.

Because the old apprenticeship taught itself.

This one won't.

---

Next in the series: a four-phase model for working with AI as a junior — and the role the mentor has to play in each phase.