The junior developer in the AI age: Building judgment when answers are free

The PR that proves nothing

A junior on the team delivers a PR. The code is well structured. The error handling is thought through. The naming is better than half the team’s.

Five years ago this would have been a sign of unusual talent. Today it means nothing.

Not because the junior isn’t good. But because output no longer says anything about understanding. AI has made senior results available to everyone – without making senior judgment available to anyone.

And judgment is the profession.

The learning curve that disappeared

Judgment has always been built the same way: through struggle.

You wrote something. It failed. You understood why. You wrote it better. A thousand small rounds of pain and insight.

AI removes the struggle. That sounds like a gift, and in many ways it is. But it also removes the learning that lived inside the struggle.

A junior who has the solution generated for them skips exactly the steps that build intuition:

• why the first attempt didn’t work
• which alternatives were discarded, and why
• where the pattern’s limits are

The result is developers who deliver fast but stand helpless when something unexpected happens. Because for the unexpected, there is no prompt.

It’s not the junior’s problem. It’s the team’s.

It’s easy to put the responsibility on the individual: “you have to understand what you deliver.”

But as with technical debt, this is a team phenomenon, not an individual failing. It’s the same mechanism as in Technical debt as a team phenomenon (in Norwegian). If the team’s culture rewards speed and accepts code no one understands, juniors will optimize for exactly that. So the question isn’t how we get the junior to shape up, but which of our own practices build judgment.

Practices that build judgment

1. Make it safe to not use AI

It sounds backwards. But when everyone around you delivers at high speed, spending a day understanding something AI could solve in minutes feels risky.

As a tech lead you have to say it explicitly: “For this task, I want you to try it yourself first.” It is meant as an investment, not a punishment.

2. The duty to explain in review

The same requirement applies here as everywhere else on the team. Whoever opens a PR must be able to explain it. For juniors this is the new learning arena rather than control, and the questions in review replace the struggle that disappeared. “Walk me through what happens if this call times out” teaches more than ten generated solutions.

3. Pair programming in two modes

Run sessions both with and without the assistant. Both are the profession now.

With AI: learn to evaluate suggestions, ask follow-up questions, spot when the answer is generic. Without AI: build the underlying muscle the evaluation rests on.

4. Let juniors reject AI suggestions – out loud

The most important skill of the AI age is not accepting good suggestions. It’s rejecting plausible but wrong ones.

Ask juniors to show suggestions they discarded, and why. In standup, in review, in team sessions. It trains judgment, and it shows the rest of the team that critical evaluation is the norm, not the exception.

The frame-setter’s responsibility

In Tech lead in the AI age I wrote that the tech lead role is shifting from expert to frame-setter. Nowhere is it clearer than here.

You can no longer train juniors by showing them the answers. They already have the answers.

You have to teach them to evaluate answers. That’s a different pedagogy, and it takes time, questions, and safety rather than answer keys.

Who shapes your seniors?

The next generation of seniors is being built now, and it isn’t AI that shapes them but the practices around it. Teams that only harvest speed get developers who produce without understanding. Teams that deliberately build judgment get developers who can do both.

Both teams use the same tools. What separates them is which practices someone decided to hold on to.