Why I'm Worried My Best Junior Engineer Couldn't Debug Her Own PR

Last month one of my juniors shipped a caching layer for an ingestion pipeline — invalidation logic, TTL tuning, a race condition, fixed — in a single afternoon, agent driving the whole thing. The diff was clean. Tests were green. I approved it. Then I sat there with a question that's been bugging me since: if the agent had gotten the invalidation wrong, would she have caught it? Could she have debugged it at 2am if it broke in prod? I didn't know. She didn't either.

The apprenticeship contract we're quietly breaking

For twenty years the deal for junior engineers was unspoken but reliable: you get the small tickets, you write code that's naive in predictable junior ways, a senior reviews it and finds the problem, and then — this is the part that mattered — you go debug your own mistake. Nobody wrote "internalize why null checks matter" into an onboarding doc. You got there by shipping the null pointer exception, getting paged, and tracing it back at your own desk until it hurt enough to stick. Do that across fifty tickets over two years and you've built a pattern library — this shape of code tends to break this way. That library is what we actually mean when we call someone a strong engineer, long before we mean anything about algorithms.

The new default task: verify, don't produce

That loop assumed the junior wrote the bad code. Increasingly, they don't. The default task on an agentic team isn't "implement this ticket" anymore — it's "point the agent at the ticket, read what comes back, decide if it's safe to ship." That's not a lighter version of coding. It's a different skill: reading someone else's output under uncertainty, deciding what to trust and what to interrogate, catching the failure mode before it ships instead of after. Almost nobody teaches this yet — not CS programs, not bootcamps, not our own onboarding docs, which still read like "here's how to set up your dev environment and grab your first ticket."

The trap

Here's what worries me more than the skills gap itself: verification instinct is downstream of debugging instinct. The reflex that says "this smells off" doesn't come from reading code carefully — it comes from having personally been burned by that exact class of bug before. You get suspicious of retry logic because you once shipped retry logic without an idempotency key and got paged for duplicate side effects. You can't review your way into that suspicion; review is only as sharp as the pattern library you bring to it. A junior verifying agent output has no library to match against, so they check what's checkable — does it compile, do the tests pass, does it match the ticket — and miss the invariant sitting three hops away that only shows up under load, or six months later, or in a retry storm.

A PhoenixDX near miss

We had exactly this happen. A junior asked an agent to add retry handling to a webhook consumer — reasonable ask, the handler was flaky under load. The agent wrote clean retry logic with backoff. No idempotency check. Retried webhooks meant retried side effects — a customer notification firing twice for the same event. She didn't flag it in her own review, because she had no reason to think about idempotency: she'd never built a retry system that got her paged for duplicate processing, so nothing in her told her to look. A senior caught it in code review, and it took him actually walking through the failure mode before it clicked for her — not just that it was wrong, but why. No incident, no postmortem. That's the part that unsettles me. It stayed invisible right up until someone with the scar tissue looked at the diff.

The prediction: a visible cohort by 2029

Here's the checkable version of the claim. Give it about three years. Teams that hired heavily through this transition will have a recognizable cohort — a few years of tenure by title, genuinely fast and fluent at directing agents — who can't operate outside the guardrails an agent gives them. You'll see it in specific, nameable ways:

• ▹Interviews: fluent walking you through what they built with an agent, then stuck cold on a raw stack trace with no agent in the loop
• ▹On-call: escalates the second the runbook runs out, no ability to form and test a hypothesis solo
• ▹Code review: approvals that track "tests are green," not "here's the invariant this could violate"
• ▹Postmortems: can tell you what the fix was, not why the system was ever vulnerable to that class of failure in the first place

None of this reads as incompetence day to day, because the agent covers the gap constantly. It shows up exactly once, at the worst possible time — an outage the agent can't diagnose, an incident during a model provider degradation, a security review that needs someone to reason from first principles instead of pattern-matching to training data.

What doesn't change

Senior judgment — the instinct that something's off before you can say why — still has to get built somewhere. It won't come from reviewing agent diffs, because that's the same trap one level up. If we're not getting it for free anymore from juniors writing bad code on real tickets, we have to construct the exposure on purpose: pair juniors with a senior on-call from month one instead of year two, hand them debugging-only tickets — real bugs, doesn't matter if a human or an agent introduced them — instead of feature tickets, make them own the postmortem write-up, not just sit in on it. Replace the ticket ladder with a debugging ladder, deliberately, because it's no longer a side effect of how work gets handed out.

The question to actually ask

So here's what I'd ask any EM reading this, about their own junior hires, right now — not in three years: name the last bug one of them debugged that they didn't write themselves and that wasn't a tutorial exercise. If you can't answer that in under ten seconds, you don't have an apprenticeship pipeline anymore. You have a review queue with a junior title attached to it. I don't have a tidy fix for this yet. I just know the loop that used to build senior engineers is running for fewer and fewer of them, and I'd rather know that now than find out during an incident.