What junior engineers should be learning now

The story managers keep describing has a consistent structure.

A junior, a few months in, submits a clean well-organised PR that solves a genuinely tricky caching bug. In review, somebody asks why one particular check comes before another.

The junior doesn't know.

He asked the agent to fix the bug, it did, the fix was correct, and he has no model of why.

He wasn't being lazy. He did exactly what the tool made easiest, and the tool made the wrong thing easiest without either of them noticing at the time, which is how this particular failure always arrives.

Worth being precise about that story, because the obvious reading is wrong.

The problem isn't that an agent wrote the code. It's that nobody read it. Least of all the person whose name is on the pull request.

How the apprenticeship used to work

Nobody designed the old system on purpose. It worked anyway.

A junior wrote a lot of code, most of it mediocre, and a senior read it and pushed back. This breaks under load. This doesn't handle the empty case. This assumes something about the data that isn't true.

The junior absorbed judgment through the friction of being wrong, repeatedly, on real stakes, over a couple of years, and the volume of those reps was the actual mechanism rather than an unfortunate cost of training people on the job.

Reading code built the same muscle from the other side. Debugging somebody else's mess at 11pm, under a bit of pressure, taught pattern recognition that no amount of passive exposure produces.

None of it was written down as curriculum. It was what the job forced you to do, for years, before you were allowed to call yourself senior.

What breaks, and what doesn't

An agent can now produce plausible working code for a junior without that junior building any model of why it works.

Throughput goes up. If nothing else changes, rep count goes down, quietly, because nothing in the visible metrics flags it.

The junior looks more productive on every dashboard a manager might check.

What's easy to miss is that the reps didn't have to disappear. They changed kind.

Writing a function teaches you one solution, slowly, whereas reading a change and judging it teaches you to evaluate many, and there are far more changes arriving now than any one person could ever have produced by hand.

A junior who reads every diff before it ships gets more reps in a week than the old apprenticeship delivered in a month. Wider range of problems. A proposed answer already in front of them to argue with.

That's the loop replacing the old one. And it isn't hypothetical.

Juniors who review more than they write, and who ship to production sooner, grow faster than the write-a-lot-and-get-corrected model ever managed, because feedback arrives from the pipeline in minutes rather than from a senior in days and the consequence of a decision lands while the decision is still fresh in their head.

Get it wrong and it's a skill-formation failure, not a slower ramp.

The pipeline that used to turn juniors into seniors over three or four years was never guaranteed. It was built out of specific, repeated friction.

Let that friction disappear, because it became easy to route around, and the org doesn't notice. Not until it needs a bench of seniors who can review agent output with real judgment, and finds the bench thinner than the headcount chart suggested.

What to actually do about it

Point juniors at review before you point them at authorship.

Have them read and judge more changes than they write, including changes they didn't prompt for, and make it the assignment rather than something they get to when there's time.

The old apprenticeship worked by accident. This one has to be assigned on purpose. That's the whole difference.

Get them to production sooner than the old ladder allowed.

The rep that builds judgment isn't writing the code. It's carrying the consequence of a decision you made, and that arrives faster when changes are small, flagged and reversible.

Change what review asks for.

Instead of "does this PR look right," ask the author to explain it. Why this approach. What breaks it. What they'd test next.

That surfaces exactly the gap the caching-bug story exposed, while it's still cheap, in a code review. Rather than expensive, in an incident six months later, when that same engineer is on call alone.

Hiring and levelling need the same adjustment. Interviews measuring how fast somebody produces working code are measuring a thing that stopped being scarce.

What's scarce now: reading unfamiliar code accurately, debugging from a vague symptom through to a real cause, and knowing when a plausible-looking answer is subtly wrong. Screen for those directly, because the old proxy, can you write this function under time pressure, measures a great deal less than it used to.

The ladder itself may need to bend.

Catching wrongness in a competent-looking diff might become valuable earlier than the old ladder assumed. Worth naming and rewarding at a junior level rather than treating it as a purely senior trait.

Architectural judgment, weighing a tradeoff nobody has told you the answer to, is probably still a multi-year build regardless of tooling. It was never about typing speed.

Worth stating as a positive result rather than a warning, because it works.

On a team where juniors reviewed more than they wrote and shipped sooner, growth accelerated rather than stalling. That came with conditions attached, and the conditions are the part to copy.

The surrounding engineers were senior enough to correct a junior's review. The validation was strong enough that shipping early wasn't reckless. Reading the change was the assignment, not the optional extra.

Remove any one and you get the caching-bug story instead. Same tooling, opposite result.

The test

Ask a junior to explain the last real PR they shipped. In their own words, without looking at the diff.

If they can, the tool accelerated them. If they can't, it did their job for them, and you have a training gap wearing a productivity metric as a disguise.