The Junior Engineer Paradox

We have a succession problem.

I've written about the shift from typing to directing, from manual construction to constrained generation. Everyone agrees this is happening. What no one knows is how we are going to grow juniors in the agentive era. There is a lot of handwringing and worry about what the future looks like in this brave new world.

Engineering capability was earned through friction. You wrestled with syntax. You paged at 2 a.m because you made a mistake in the code a month earlier. You misunderstood state, then paid for it in production. You learned why certain patterns were bad because you lived inside their failure modes. That struggle didn't just produce software. It produced intuition.

That friction is gone, for all intents and purposes. We have the risk of a generation of engineers who lack that depth. They will be paper seniors, fluent in architectural jargon but lacking the visceral understanding that makes those words mean something. You know the type: they suggest microservices when you have a perfectly functional monolith, because they read about microservices, not because they've thought through the complexity they're introducing.

Relocating the Struggle

The mistake critics make is assuming that losing the typing means losing the learning.

It doesn't.

The struggle is simply moving up the stack.

Junior engineers used to fight off-by-one errors and syntax they hadn't internalized. That struggle was narrow and mechanical. It taught accidental details rather than durable systems thinking.

In the agentive era, the struggle is forensic.

And it requires a different kind of thinking. LLMs output with variance. The same prompt doesn't always produce the same result. Engineers need to reason about distributions of possible outputs, not just deterministic correctness.

Juniors will generate systems that mostly work almost instantly, only to encounter failures that are subtle, emergent, and systemic. The new craft isn't found in writing code. It's found in reading code you didn't write. It's about developing a nose for architectural rot in a 2,000-line PR that looks perfect but violates a core invariant. This is harder, more exhausting work than typing ever was. And the feedback loop is brutal. A syntax error slaps you in the face immediately. A subtle architectural flaw might not surface until the system is under load in production, weeks later. The learning signal is weaker and slower. In the old world, the compiler was the teacher. In the new world, production is the teacher, and production is unforgiving.

Intentional Friction

Just as we still teach long division in a world of calculators, we will still need to enforce foundational constraints.

Many years ago, I read a sci-fi novel about a world where general AI had recently been introduced, and it was having a profound effect on the society in which it was introduced (sound familiar?). One of those effects was a change in education. They had figured out that education needed to change from rote memorization to the exploration of knowledge. If all of human knowledge is at your fingertips, it's pointless to store it in your head. But understanding it, exploring it, and reasoning about it were more critical than ever. The school systems in that hypothetical society had to shift. That thought has stuck with me since I was a kid. Engineering is undergoing the same transition.

The New Apprenticeship

The old progression was about scope. You started small, both writing and reviewing, then took on bigger things, then bigger things still. Complexity grew with trust.

The new progression has the same shape. Scope still grows with trust. But the focus shifts from authorship to audit. You start by reviewing simple generated code, graduate to complex systems, and eventually design the constraints that guide generation in the first place.

Mentors won't critique a junior's syntax anymore. They'll critique their diagnostic depth. What did you miss? What signal did you ignore? What invariant did you fail to notice? This looks less like traditional programming and more like how we train doctors or pilots, through high-stakes simulation and rigorous peer review of decisions.

The Real Risk

Juniors will figure this out. They'll learn to be good arbiters of agents because that's the world they're entering. The risk is that leaders try to force the old approach. I had a senior engineer who forbade juniors from using LLMs so they would learn the way he had learned. His intentions were good, founded in genuine care for those juniors, but holy crap, I can't think of a better way to hamstring them in this age we are entering.

The risk is that we drag our feet, worrying about this. We will figure it out. I've laid out one approach here. Maybe it looks like this, maybe it looks different. But we will figure it out.