Mentoring Juniors in an AI-Assisted Team

The concern is not that juniors using assistance produce worse code. Often they produce better code. The concern is what happens to the learning that used to occur in the gap between not knowing and knowing, when that gap is now filled in seconds.

The problem, stated precisely

A traditional path to competence contained a lot of unpleasant searching: reading an unfamiliar codebase to find where a thing is done, forming a wrong hypothesis about a bug and spending an hour before discarding it, writing a function badly and then seeing why it was bad. That searching was slow and much of it felt wasted.

It was not wasted. It was where three specific things were acquired: a map of the codebase, a repertoire of failure shapes and what they indicate, and a calibrated sense of how confident to be. All three come from time spent in the uncertain state, and assistance is extremely good at ending the uncertain state quickly.

Two honest caveats before the practices. This is a mechanism argument, not a finding — there is no study cited here, and anyone telling you the long-term effects on skill acquisition are established is ahead of the evidence. And the same mechanism cuts the other way: a junior who uses assistance to explore three approaches in the time it used to take to write one may be learning faster, not slower. The variable is not the tool. It is whether the uncertain state is entered at all.

Why it is not simply faster learning

The reason to take this seriously rather than treating it as the usual complaint about a new tool is that the shortcut removes a specific input rather than making a process faster.

• Recognition is built from failures, not from successes. Knowing what a race condition looks like from a symptom comes from having chased several. A correct answer supplied at the moment of confusion provides the fix without the symptom-to-cause link, which is the part that transfers to the next bug.
• Calibration needs to be tested. You learn how much to trust your own judgement by committing to it and finding out. A workflow where the answer is always available externally never forces the commitment, so confidence stays uncalibrated in both directions.
• A codebase map is built by getting lost in it. Being handed the right file is faster and leaves no map behind. Juniors on assisted teams can be productive in a repository they could not describe.
• Reading code is now the dominant skill and gets the least practice. If most code is drafted quickly, the bottleneck moves to evaluating it — and evaluating code you did not write is a harder skill than writing it, which juniors have historically acquired last.

Six practices

None of these is a ban. Restricting tools produces resentment, non-compliance and a junior who is slower than their peers, which is not a kindness. All of them target the mechanism instead.

• 1. Predict before generating. Before accepting a suggestion, say out loud — or in a comment — what you expect it to do. Then compare. This is a thirty-second habit that restores the commit-and-check loop that calibration needs, and it costs almost nothing.
• 2. Ring-fence some work as unassisted. Not most of it. One task a week, chosen because the struggle is the point: debugging something subtle, reading an unfamiliar subsystem to explain it back. Frame it explicitly as training rather than as deprivation, and make clear it is not how the rest of the work is judged.
• 3. Require an explanation of code before it is submitted. Not written — spoken, in review. “Why is this here, and what happens if this line is removed?” A junior who can answer has understood the code, whoever drafted it. One who cannot has found the gap, and found it cheaply.
• 4. Make the failure visible. Deliberately let a plausible-but-wrong approach reach the point where the test fails, rather than heading it off. The uncomfortable part of mentoring has always been letting somebody find out; assistance makes it easier to rescue them and therefore easier to deprive them.
• 5. Teach verification as a first-class skill. How to check whether generated code does what it claims: reading it adversarially, writing the test first, checking the edge case that was not mentioned. This is the skill the workflow most requires and least teaches on its own.
• 6. Pair on the hard part, not the easy part. Assistance handles the boilerplate well, which frees mentoring time for the parts it does badly: deciding what to build, arguing about a trade-off, and diagnosing a failure that spans systems. That is a genuine improvement in what mentoring can be spent on, and it is worth naming as a benefit rather than only cataloguing losses.

What to change in code review

Review is where most of this is either fixed or lost, and the shift is from “is this correct” to “does this person understand what they submitted”.

• Ask about alternatives. “What else did you consider?” A junior who considered nothing accepted the first suggestion, which is the behaviour to change.
• Ask about the failure path. Generated code is typically correct on the happy path and thin on error handling, timeouts, and what happens when a dependency misbehaves. This is a real quality issue and a good teaching surface at once.
• Notice unexplained sophistication. Code more advanced than the author’s demonstrated understanding is a flag, not for dishonesty but for a maintenance risk: nobody on the team can now change it confidently.
• Praise deletion and simplification, explicitly and in public. Assistance biases toward producing more code; the counterweight has to be cultural because it will not come from the tool.

What to say to the junior directly

Being honest with the person is more effective than managing them quietly, and the argument is not moralistic — it is about their leverage.

The version worth saying: your value will not come from producing code quickly, because that is the part that is most assisted. It will come from judging whether the code is right, deciding what should be built, and diagnosing failures nobody has seen before. Those are built by spending time in confusion, and the tool is very good at ending confusion. So use it, and deliberately keep some confusion for yourself.

Give it a concrete form so it is a habit rather than an exhortation: before asking for a solution, write down what you think is happening and why. Then ask. When you were wrong, that gap is the learning, and you will have it in writing. It costs a minute, it survives contact with a deadline, and it is the practice that most reliably keeps the curve going up.