Deliberate practice in agentic coding

Day 17: The Practice Reps Agentic Coding Is Quietly Deleting

Your juniors are merging more PRs than ever, and review is barely catching anything. Great news, right? Except faster and better aren't the same thing, and the gap between them won't show up on any dashboard you own today — it'll show up two years from now, as a junior who can approve a diff fluently but can't debug one.

The afternoon feature that should unsettle you

A junior opens a ticket at 10am. By 2pm, there's a PR — feature complete, tests green, and the only review comments are nitpicks. Six months ago, that same ticket would've eaten two days, most of it spent stuck and staring at a stack trace. Not anymore. There's nothing wrong with the PR. But something about it still bugs you, and you can't point to which line.

Name the mechanism: deliberate practice

Anders Ericsson's research on expertise — the real work behind 'Peak', and the substance under the much-misquoted '10,000 hours' idea — is precise about what actually builds skill. It isn't repetition. It isn't output. It's effortful struggle right at the edge of what you can currently do, followed by fast, specific correction. You attempt something just past your ability, you fail or half-fail, you find out exactly where it broke, and you go again. The struggle isn't the price you pay for learning — it is the learning. Skip that phase and no volume of correct output buys it back.

• ▹Deliberate practice, in one line: struggle at the edge of your competence, plus immediate, specific correction
• ▹Whether the output was correct barely matters — a failed attempt still builds skill; a correct answer that cost no struggle builds nothing
• ▹It's why pairing, code review, and incident retros actually train people: each one bolts correction onto an attempt right after it happens
• ▹Agentic coding doesn't just remove the struggle — it removes the attempt. If the agent writes the first draft, there's nothing left for correction to attach to

The swap nobody notices: oversight skill arriving before production skill

There used to be a fixed order to this. You write code yourself, badly, for years. You get paged at 2am and feel it break. You build an intuition for where bugs hide because you've personally planted a thousand of them. Only once that base exists do you get handed review and oversight — judging someone else's code against a felt sense of how code actually fails. Agentic coding skips the queue. A junior today is asked to review and approve an agent's diff in month one, before a race condition, a bad abstraction, or a silent off-by-one has ever cost them a full day of their life. Oversight skill is showing up with nothing underneath it.

What it looks like inside a team — the tell is in the words, not the outcome

Managing engineers at PhoenixDX, I've watched this same pattern play out more than once. Someone looks at an agent-generated diff and approves it fluently — flags the one genuinely risky line, asks a sharp question, ships it. Then the same class of bug shows up in production, the agent's unavailable, and you watch them debug it live. The fix usually still lands. But listen to how they describe it afterward: 'I changed this and it worked,' instead of 'this was null because the upstream call doesn't guarantee ordering, so I added a guard.' The first sentence is pattern-matching on an outcome. The second is a causal model. Fluently approving someone else's reasoning — or an agent's — is not proof you have a causal model of your own. And a causal model is exactly what oversight is supposed to rest on.

Why this is easy to miss as an EM

Every metric you're used to watching — PRs merged, cycle time, tickets closed — is climbing, for juniors and seniors alike. There's no dashboard for 'pattern recognition accumulated this quarter,' because nobody's built one. So the one signal that would actually warn you — a junior not building the base — is precisely the signal your tooling can't show you, while the signal that says everything's fine, throughput, is the one it shows you every single day. The gap doesn't announce itself. It just waits for the day the agent is wrong about something non-obvious, and the junior has no independent way to catch it.

The counter-argument, and why it's incomplete

The obvious pushback: senior engineers have always delegated the grunt work — to juniors, to libraries, to codegen, to a well-timed Stack Overflow copy-paste. Fair. But a senior delegating today is delegating from roughly 10,000 reps already in the bank. They can read a generated diff and know, in their gut, exactly where it's likely to be wrong, because they've been wrong in that same spot themselves, many times over. A junior handing a ticket to an agent on day one is delegating before any of that base exists. It's not the same move wearing a new tool. One is outsourcing execution after the judgment is already built. The other is outsourcing the very thing that was supposed to build the judgment.

What to actually do about it

Banning agents for juniors isn't realistic, and it's not even the right fix — oversight skill is genuinely valuable, and they need to build it too. Instead, put the struggle back in on purpose, and book the time it costs as training budget, not lost velocity:

• ▹Before the agent ever sees the ticket, have the junior write one real function unassisted — then compare their draft against what the agent produces
• ▹Pick one incident or real bug each sprint and debug it start to finish by hand, agent access off
• ▹Grade the explanation, not the diff. Ask 'why did this break' and listen for a causal model, not a description of what got changed
• ▹Put it on the plan explicitly ('this ticket is a no-agent rep') so it doesn't quietly disappear the first time a deadline tightens

Day 17 of 30. Tomorrow builds straight on this: once you accept skill-building needs its own line item, the next question is how you actually defend that budget against a roadmap that doesn't care.

Extend your knowledge

• ▹Read Anders Ericsson and Robert Pool's 'Peak: Secrets from the New Science of Expertise' for the real research behind deliberate practice — the substance under the misquoted '10,000 hours' idea
• ▹Look at how trade apprenticeships sequence unassisted reps before handing over inspection or oversight responsibility — this sequencing problem predates software, and there are solutions worth stealing
• ▹Audit your own team's last sprint: how many tickets did a junior finish with zero unassisted attempt before the agent ever touched them?
• ▹Look at how your team already runs incident retros — that correction loop is a ready-made template for a deliberate no-agent debugging exercise