TL;DR
Juniors who use an AI assistant as a shortcut to finished code can ship work they cannot test, debug or explain, and the team loses its future seniors. Develop them on purpose: set the assistant to tutor rather than author on learning work, reserve some tasks for deliberate practice, ask juniors to explain each change before it merges, rotate mentors, and give one person ownership of a plan with observable milestones. Within a year you should see who can debug alone.
In this article
- What the novice studies measured
- Separate learning work from delivery work
- Reserve some tasks for deliberate practice
- Ask for the reasoning before the merge
- Rotate mentoring so it does not depend on one senior
- A twelve-month plan with milestones you can observe
- Written conventions shorten the path
- Frequently Asked Questions
8 min read
Give juniors a development plan that treats the AI assistant as a tutor on learning work and as a tool on delivery work, and make someone responsible for that plan. Controlled studies of novices suggest that the way a learner uses the assistant matters more than whether they use it at all. A ban wastes a useful tutor; unrestricted use removes the struggle that builds skill.
What the novice studies measured
The clearest software evidence comes from a randomized trial by Anthropic researchers, published in January 2026 (Anthropic research summary, 29 January 2026; paper, Shen and Tamkin). Fifty-two mostly junior developers learned an unfamiliar Python library with or without an AI assistant and then took a quiz; the assisted group scored lower, with the widest gap on debugging. For a manager, the authors’ breakdown of how people used the assistant matters most. Participants who delegated code writing to it, or slid into delegating after a few questions, averaged under 40%. Those who asked conceptual questions and resolved errors themselves, or asked for explanations alongside generated code, averaged 65% or more. The authors state that this breakdown does not establish cause.
A larger field experiment points the same way. In a randomized trial with nearly 1,000 high school mathematics students in Turkey, published in PNAS in July 2025, students practising with an unrestricted GPT-4 interface scored 17% lower on a later exam without AI than students who never had access, while a tutor version designed to give hints rather than answers largely removed that harm (Bastani et al., PNAS, 2025).
Two smaller studies add nuance. In an observation study of 21 novice programmers presented at ICER 2024, students who already knew what they wanted to build used AI suggestions to go faster, while struggling students had their difficulties compounded and often left with an inflated sense of their own ability (Prather et al., 2024). An earlier controlled study of 69 learners aged 10 to 17 at CHI 2023 found that access to a code generator did not reduce their performance on later manual code changes (Kazemitabaar et al., 2023).
The team-level risk of owning code nobody can explain is covered in Comprehension Debt: When the Team Owns Code It Cannot Explain. This article is about the people who will have to explain it in five years.
Separate learning work from delivery work
A junior’s week contains both, and the assistant should behave differently in each. On delivery work the team’s usual AI policy applies. On learning work, agreed per ticket, the assistant acts as a tutor: it answers conceptual questions, explains error messages and reviews the junior’s own attempt, but it does not write the solution.
Some tools support this directly. Claude Code’s Learning output style explains its choices and leaves pieces with a real design decision, marked TODO(human), for the developer to write (Claude Code documentation, output styles, checked 9 October 2026). The documentation describes a style as an instruction the model follows, not an enforced rule, and no measured learning benefit for it was found. Harvard’s CS50 course took the same approach at scale: it limited commercial assistants and gave students its own tutor built to guide them toward solutions rather than provide them (Liu et al., SIGCSE 2024). Its evaluation rests on student feedback, not on exam results.
Where a tool has no such mode, a team prompt convention does the same job: ask for concepts and hints, never the finished function.
Reserve some tasks for deliberate practice
Deliberate practice means work slightly beyond what the junior can already do, with feedback soon after. In a team that ships with AI, it has to be scheduled, because the assistant will otherwise absorb exactly those tasks.
Practical forms that fit normal delivery:
- A real bug, diagnosed without the assistant, within a time box, before a mentor helps. The debugging gap in the Anthropic trial makes this the first habit to protect.
- A small change in an unfamiliar module, where the junior first writes down how data flows through it and only then opens an assistant to check their reading.
- Tests written before the implementation, so the junior decides what the behaviour should be rather than accepting what generated code happens to do.
One or two such tickets per sprint is a reasonable starting point to adjust. Count them as planned work, so a junior does not look slow on a board that only shows throughput.
Ask for the reasoning before the merge
Explain-before-merge turns review into a teaching moment without adding a separate course. For changes a junior authored, the pull request description is written in their own words and answers four things: what changed, why this approach, how it was tested, and what would break first. The reviewer then asks at least one question that cannot be answered by rereading the diff, usually about a failure case.
For a few changes a month, replace the written answer with a ten-minute conversation in which the junior walks the mentor through the change with the AI chat closed. Prather and colleagues found that struggling novices can believe they have done better than they have; a live walk-through shows the gap to both people before production does.
Rotate mentoring so it does not depend on one senior
One of the two public questions behind this article, an Ask HN post, worried that juniors were losing their contact with seniors as well as their skills (Ask HN, 22 March 2025). An assistant answers instantly, so juniors stop asking people; planned pairing restores the contact.
Rotate each junior through a different senior every six weeks or so, with the junior at the keyboard and the senior asking questions. Rotation spreads the teaching load, shows the junior more of the system, and stops one generous senior from becoming the team’s whole development programme. The other question, posted on the r/ExperiencedDevs forum in December 2025 by an experienced developer whose company still hires graduates, asked how to mentor them out of exactly this dependency; a pairing rotation is one answer that does not rely on the goodwill of a single person.
A twelve-month plan with milestones you can observe
Give each junior a written plan, owned by their engineering manager or lead, with milestones a mentor can see in normal work rather than in a test.
- Months 0 to 3: read and trace. Explains how a request moves through one core module; writes tests before implementation on practice tickets; describes every merged change in their own words.
- Months 3 to 6: debug. Diagnoses a real defect without the assistant within the time box; reproduces a production issue locally from logs.
- Months 6 to 9: decide. Writes a short design note comparing two approaches for a change, and a senior accepts or challenges it in review.
- Months 9 to 12: own. Owns a small feature end to end, reviews other people’s pull requests with substantive questions, and pairs with the next new joiner.
The timings are a starting point to adjust; what matters is that another engineer has seen the evidence.
Written conventions shorten the path
Juniors learn faster when the codebase explains itself: reviewed module documentation, written conventions and recorded decisions answer questions a junior would otherwise put to an assistant that does not know the team’s reasons. The same material gives the AI tools better context, and repeated questions become documentation instead of chat (New developers ask the AI the same questions every week).
Eliyce’s AI Delivery Programme produces that material with a team: reviewed project and module documentation, written conventions, and a record for each change of the rules applied and checks run, which gives a mentor something concrete to discuss. It is not a training course for juniors, there is no evidence that its workflow improves junior skill development, and no customer has completed it yet. A structured workflow can also let someone pass every check without understanding the change, so judging understanding stays with your seniors. If you want written conventions and per-change records that your mentors can teach from, explore the Programme and request a fit conversation.
Frequently Asked Questions
How should we develop junior developers who rely on AI?
Treat it as a development plan with a named owner, not as a tool policy. A rule about which assistant juniors may use changes little if nobody checks, month by month, what each junior can now do alone.
What exactly are our juniors not learning, and where does it show?
Usually debugging, reading unfamiliar code, writing meaningful tests and weighing design trade-offs. It shows in pull request descriptions that restate the diff, tests that mirror the implementation, changes reopened after merge, review questions answered by re-prompting rather than reasoning, and incidents where the junior escalates before forming a hypothesis.
Which limits are fair without making juniors slower or singling them out?
Attach limits to the task, not to seniority: any engineer learning an unfamiliar area can work in tutor mode, and seniors also explain high-risk changes before merge. Agree the practice tickets openly, plan them into sprint capacity, and judge them on what was learned rather than on speed.
How could explanation requirements and learning tasks fail?
They become box-ticking when the explanation itself is generated, so keep some explanations live. They overload seniors when every pull request gets a walk-through, so cap walk-throughs per junior and rotate mentors. They push AI use out of sight when using it is punished, so keep it allowed and openly discussed, and make the tutor-mode tickets the only exception.
What would show progress over six to twelve months, and who owns it?
Compare each junior with their own earlier quarter, since no external benchmark for this exists: a real defect diagnosed alone, a design note that survived review, substantive review comments on other people’s work. The engineering manager or lead owns the plan; rotating mentors supply the observations.
