AI Pair Programming and the Junior Developer Skill Gap

The pull request was three lines long and the tests were green. A TypeError in an invoice formatter had been fixed by defaulting the discount field to zero, and every row downstream rendered again. I asked the junior who opened it why that value had been undefined in the first place. The answer came back without embarrassment, because it did not feel like an admission: the agent had suggested it.

That fix was probably correct on the order it was tested against, which is what makes this hard to talk about. This post is about the one skill AI pair programming genuinely puts at risk — debugging from first principles — the five sub-skills it decomposes into, the drill I now use instead of explaining fixes, and the questions a reviewer has to ask to tell a learned fix from a borrowed one. Adoption and trust figures come from the 2025 Stack Overflow Developer Survey; the self-assessment figure comes from METR's randomised trial.

Syntax was never the hard part

The skill an agent erodes is not syntax. A junior who cannot remember the argument order of a reduce callback was never blocked by that: the documentation was one browser tab away in 2015 and is one prompt away now. What juniors used to practise dozens of times a week, without ever calling it practice, was something else entirely — the loop between a symptom and a cause.

That loop got practised by accident, because for a long time there was no alternative route through it. A stack trace appeared, and the only way past it was to read the thing, guess, test the guess, and be wrong a few times before being right. An agent removes the monopoly by offering a second route, and the second route is faster on almost every individual bug. Nobody chooses the slow path forty times a week when a fast path is sitting right there, which is why this is a structural problem rather than a discipline problem.

The debugging loop has five steps and an agent covers three

Written out, the loop is short enough to audit. Each step is a separate skill, and each one decays separately once something else performs it for you.

1. Read the trace and find the first frame that is your own code, rather than the frame where the value finally broke something. Those are usually different lines, in different repositories.
2. State one cause, phrased so that the next run can prove it wrong. Something to do with the discount cannot be disproved; the query omits the discount join for orders created before the pricing migration can be.
3. Design the cheapest experiment that separates that cause from the next most likely one — deliberately not the experiment that confirms the cause you prefer.
4. When no hypothesis survives the evidence, stop guessing and bisect: find a check that fails on the bug, and let the tooling halve the search space until one commit is left.
5. Register the moment your prediction and the output disagree. This is the step that changes what you believe, and the only one nobody can perform on your behalf.

An agent will happily do the first two, mechanise the fourth if you hand it a test command, and skip the third almost every time — it proposes a fix rather than an experiment, because a fix is what it was asked for. The fifth it cannot do at all, since the fifth happens inside a head that made a commitment. A junior who skipped straight to the fix has no commitment on record, so there is nothing for the output to contradict.

Reading a stack trace is a decision, not a scan

Ask a junior who has been pairing with an agent for six months to read a stack trace aloud and you learn quickly whether they have ever really read one. The common failure is not confusion. It is reading the top line, recognising the words, and stopping there.

TypeError: Cannot read properties of undefined (reading 'toFixed')
    at formatCurrency (/srv/app/node_modules/@acme/invoice-kit/dist/format.js:41:28)
    at Array.map (<anonymous>)
    at buildRows (/srv/app/node_modules/@acme/invoice-kit/dist/rows.js:88:19)
    at renderInvoice (/srv/app/src/invoice/render.ts:48:29)   <-- first frame we own
    at handler (/srv/app/src/routes/invoice.ts:22:11)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)

// The stack proceeds from the most recent call to earlier ones (MDN), so:
//   frame 1 = where it threw. Read it to learn what toFixed wanted: a number.
//   frame 4 = the first frame we own. That is where the undefined was handed
//             over, and the only line in this list we are allowed to change.
//
// The three-line fix defaults the field to zero at frame 1's doorstep.
// It turns a loud crash into a silent, wrong invoice: discount 0.00 on every
// order the query forgot to join. Green tests, incorrect PDFs.

Which end you start from is a choice with a rule behind it. Start at the top when the error type itself is unfamiliar, because the top frame is the only one that tells you what the failing call actually wanted. Start from the bottom when the top frames are all inside a dependency, because your own program's last decision is the only thing in that list you are allowed to change. Neither habit is difficult to acquire. Both are invisible if a working fix arrives before the trace has been read.

A hypothesis you cannot falsify is a feeling

The most valuable ten seconds in debugging are the ones spent turning a suspicion into a sentence that could be wrong. Two hypotheses that both explain the same symptom demand different experiments, and the experiment worth running is whichever one kills a hypothesis rather than flattering it.

// H1: discount is undefined because the query omits the join for orders
//     created before the pricing migration.
// H2: discount is undefined because the DTO strips zero-valued fields
//     on serialisation.
//
// Both explain the crash. Neither is worth arguing about, because one line
// at the boundary between them settles it:
console.log(JSON.stringify(rows[0]));
// discount present here  -> H1 is dead, the loss is downstream in the DTO
// discount absent here   -> H2 is dead, the loss is upstream in the query

// When nothing survives contact with the evidence, stop guessing and bisect.
// Any check that exits non-zero on the bug will do:
git bisect start HEAD v3.11.0
git bisect run npm test -- invoice.spec.ts
// About nine checkouts across four hundred commits, and no intuition required.

Bisecting is the same discipline, mechanised. Once no hypothesis survives the evidence, a check that exits non-zero on the bug lets git halve the search space repeatedly — roughly nine checkouts across four hundred commits, instead of four hundred readings of a diff. Juniors reach for it rarely, and not because the command is obscure: it only feels worth setting up after you have accepted that your intuition is exhausted, and accepting that is itself a practised move.

The drill: predict before you run

Explaining a fix to a junior teaches far less than it feels like it does, because a clear explanation is pleasant to receive and costs nothing to accept. The reversal that works is to make them commit to an outcome first: prediction, then observation, then an account of the gap between the two. It is the predict-observe-explain sequence used in science teaching to surface misconceptions, and the mechanism is identical in a terminal — a wrong prediction that has been written down is a misconception with an address, so the output has something to correct.

# 1. WRITE THE PREDICTION DOWN. Before running anything, before asking anything.
#    Three lines in a scratch file nobody reviews:
#
#      cause:    renderInvoice passes undefined for orders with no discount row
#      evidence: the first frame we own is render.ts:48, not the library frame
#      test:     log rows[0] at render.ts:47 and expect no discount key

# 2. RUN THE EXPERIMENT YOU JUST WROTE. The experiment, not the fix.
node --enable-source-maps dist/invoice.js 8842 2>&1 | head -20

# 3. NOW bring in the agent. Paste the trace AND the three lines, and ask which
#    of the three is wrong. A prediction gives a model something to correct;
#    a bare stack trace gives it something to guess at.

# 4. Score it out of three: cause, evidence, test.
#    A wrong prediction you wrote down is worth more than a right fix you
#    watched appear. Only the mismatch changes what you believe.

The agent is not excluded from this drill. It is moved. It goes from producing the fix to marking the prediction, which is a better use of it in every way: paste the trace and your three lines, ask which of the three is wrong, and the explanation you get is aimed at what you actually believed rather than at undefined values in general. The junior still gets the answer in under a minute. They just pay one minute of commitment for it first.

What genuinely got better, which is most of it

None of this is a decline story, and any post that treats it as one is wrong about the last two years. Juniors joining now are better off on nearly every axis I can observe directly.

• They ship something real in their first week rather than their first month, because scaffolding, config and boilerplate no longer eat the whole of onboarding.
• They read far more unfamiliar code, because the cost of asking what a four-hundred-line file does has collapsed to roughly nothing.
• They have an always-available explainer for library internals at two in the morning, without the social cost of asking a senior something basic.
• They attempt work above their current level and often finish it, which is how a level moves in the first place.

So the goal is not to withhold the tool, which would be both unenforceable and unkind. It is to keep one narrow activity deliberately manual: a couple of bugs a week where the agent may explain anything and fix nothing.

Usage rose, trust fell, and that is the environment you train for

The 2025 Stack Overflow Developer Survey puts 84% of respondents using or planning to use AI tools in their development process, and 51% of professional developers using them daily. Sentiment moved the other way over the same period: more developers actively distrust the accuracy of AI tools, 46%, than trust it, 33%, and positive sentiment fell from over 70% in 2023 and 2024 to 60%. The most-cited frustration, at 66%, is solutions that are almost right but not quite. The second, at 45%, is that debugging AI-generated code takes more time.

Read those figures together and the training priority stops being a matter of opinion. Two thirds of the industry's daily annoyance is a class of output that looks correct and is not — which is exactly the output that only a practised verification loop catches, and exactly the output a junior with no loop will merge. Rising usage alongside falling trust is not a contradiction. It is a description of a workplace where verification is the scarce skill.

What review has to ask now

Reviewing a junior's AI-assisted pull request means asking why, not whether the tests pass. Tests passing is now the cheapest property a diff can have — an agent will iterate until they do, and a default value planted at the throw site reaches green faster than a fix at the cause. In the invoice case it reached green while quietly printing a zero discount on every order the query had forgotten to join, which is a worse outcome than the crash it replaced.

Three questions do most of the work, and none of them are adversarial. What was your first guess, and what killed it? Which frame in that trace is ours? What would have failed if you had been wrong? An author who debugged the problem answers all three in a sentence each. An author who accepted a suggestion pauses on the first, and the pause is the entire signal — not a cue for a lecture. The agent suggested it is a perfectly reasonable thing to have done; it is only a problem when nobody asks the next question.

The rule I hold to now is narrow enough to actually keep: the agent may explain any bug, and may fix any bug I am not trying to learn from. For the two or three a week that I am, the prediction goes down first — cause, evidence, disproving check — and the agent only gets to mark it. Reviewers hold the other end of the same rule by asking what was ruled out, because a fix nobody can account for is technical debt that passed its tests.