A junior developer opens a ticket, pastes it into an assistant, and ten minutes later has a working pull request. The tests pass, the reviewer approves it, and the ticket closes. Nothing went wrong, and that is exactly the problem, because nothing in that sequence required the developer to understand what was just merged.
Teams that adopt AI coding tools tend to notice the speed first and the skill gap much later, usually when a junior is asked to debug something at 4pm on a Friday without the assistant's help and cannot reason about the code they supposedly wrote. This article is about preventing that outcome without banning the tools, which rarely works and wastes a real productivity gain.
What actually goes missing when the first draft is free
Writing a first draft by hand is where most of the learning happens. You pick a data structure, discover it does not fit, backtrack, read the documentation for a function you have never used, and slowly build a mental model of the problem. That friction is not a tax on the work. It is the work, from a learning point of view.
When an assistant produces the draft, the junior skips straight to the review stage, a skill that normally comes years later because it depends on having written plenty of code first. Reviewing code you could not have written yourself is hard, and the result is often a shallow skim that confirms the code looks plausible. Plausible is the one thing AI-generated code always is.
Separate shipping speed from learning speed
The first useful mental shift is to stop measuring a junior's growth by how many tickets they close. Ticket throughput will go up with an assistant regardless of whether the person is learning anything. A junior who closes twice as many tickets while understanding half as much has not improved, they have just moved the risk somewhere less visible.
Track learning separately. Ask what the developer could explain, modify, or rebuild without help, and treat that as the real signal. A quick weekly check where the junior walks a teammate through one change they shipped, including why it works and what they would change, tells you far more than a velocity chart does.
Photo by Nataliya Vaitkevich on Pexels
Make "explain it back" part of the pull request
The cheapest habit with the biggest effect is requiring a short written explanation in every pull request description, in the author's own words. Not a summary of the diff, which the assistant can write too, but an account of the decisions: why this approach, what alternatives were considered, and what could break.
Reviewers can then ask one or two pointed questions that an assistant-written explanation would struggle to answer convincingly. "What happens if this list is empty?" or "Why a map here instead of an array?" are not gotchas. They are the same questions a mentor would ask over a shoulder, and the junior's ability to answer them is the thing you are actually trying to build.
Use the assistant as a tutor, not a vending machine
How a junior prompts matters as much as whether they use the tool at all. Asking an assistant to produce a complete solution trains copy-paste. Asking it to explain an error, compare two approaches, or critique a draft the junior wrote first trains understanding, and the tool is just as good at both jobs.
Teach this explicitly. A short team guideline such as "write your own attempt first, then ask the assistant to review it" costs nothing and flips the dynamic. The assistant becomes a fast, patient reviewer of the junior's thinking rather than a substitute for it. If your team already keeps a project instructions file for its assistants, you can encode some of this directly in the way the tool is told to respond to newer team members.
Protect some tasks from assistance on purpose
Not every ticket needs to be a speed run. Pick a regular slot, say one task a sprint, that a junior does without an assistant, ideally a small but real piece of work like a bug fix in an unfamiliar module. The goal is not to be strict about tooling. It is to keep the underlying muscles from atrophying, the same way pilots still hand-fly part of a flight even though autopilot is available.
Choose these tasks deliberately. Good candidates are bugs that require reading existing code, small features that touch two or three files, and anything involving a part of the system the junior has not seen before. Avoid assigning purely mechanical work, since there is little to learn from it with or without a tool.
Rebuild code review as a teaching tool
Reviews of AI-assisted work should look different from reviews of hand-written work. A reviewer who only checks that the code works is leaving most of the value on the table, because working code is the baseline for an assistant, not an achievement.
Shift review comments toward reasoning. Instead of "rename this variable," try "what would a future reader need to know to trust this function?" Point out where the assistant made a choice the junior should have questioned, such as pulling in a dependency for a three-line task or swallowing an exception silently. Reviews are where seniors can transfer judgment, and that transfer is exactly what is at risk. A practical review process for AI-generated code helps keep these conversations from becoming rubber stamps.
Photo by Tiger Lily on Pexels
Pair on the hard parts, not the easy ones
Pairing is more valuable than ever precisely because the easy parts are now automated. Seniors should spend their time with juniors on the parts an assistant handles badly: ambiguous requirements, tradeoffs between competing designs, debugging across systems, and deciding what not to build.
Those are the skills that separate a developer who can operate a tool from one who can run a project. A thirty-minute pairing session on how to break down a vague request will do more for a junior's career than a month of watching an assistant fill in function bodies. Calendar it deliberately, because without a slot on the schedule it will lose to deadlines every time.
Build a ladder of increasing independence
Juniors benefit from knowing what growth looks like in an AI-assisted team. Without a clear ladder, the path from "can prompt an assistant" to "can design a system" is invisible, and people tend to optimize for what is visible and rewarded, which is output.
A simple version has four rungs. First, the developer can explain and safely modify assistant-generated code. Second, they can spot when generated code is wrong or risky without being told. Third, they can design a small feature, decide what the assistant should and should not produce, and verify the result. Fourth, they can mentor others in doing the same. Review each junior against that ladder in regular one-on-ones, and talk about which rung they are working on.
"The risk with AI assistants is not that juniors write worse code. It is that they stop being the person who understands it. A team full of people who can approve code but cannot explain it has quietly lost its ability to fix anything under pressure." - Dennis Traina, founder of 137Foundry
Watch for the warning signs early
Some patterns show up reliably before a team notices a real skill problem. A developer who cannot describe their own pull request without rereading it, who responds to review comments by asking the assistant instead of thinking, or who gets stuck on tasks they could have done a year ago are all signals worth acting on.
None of these are reasons to take the tool away. They are reasons to adjust the balance, add a protected task, or schedule more pairing. Catching it in the first month costs a conversation. Catching it after a year costs a hard performance discussion and a lot of avoidable frustration on both sides.
Guardrails help juniors too
Clear boundaries make an assistant safer for newer developers, who are the least equipped to notice when it goes somewhere it should not. Restrict what the tool can touch, require human sign-off for authentication, billing, and data migration code, and make the review checklist for those areas explicit. Put those limits in writing and enforce them in the repository, not just in a wiki page.
These guardrails double as a teaching device. When a junior asks why they cannot let the assistant edit a payments module, the answer is a short lesson on risk, ownership, and why some code deserves a human who understands every line.
Make learning visible and rewarded
People do what the team rewards. If promotions, praise, and standup attention all flow to whoever ships the most, juniors will lean on the assistant to maximize output, because that is rational. If you also recognize the person who wrote a clear design note, found a subtle bug during review, or taught a teammate something, the incentives shift.
Small gestures work. Call out good explanations in pull requests, ask juniors to present a short writeup once a month on something they learned, and let them run a retro on what worked and did not about their use of the tools. For reading material, the GitHub Copilot documentation and Anthropic's Claude Code overview both describe how their tools are meant to be used, which is a useful starting point for team norms. The Stack Overflow Developer Survey tracks how developers across experience levels are actually using these tools, and the ACM publishes research on programming education that is worth a look if you want to go deeper on how people learn to code.
Putting it together
None of this requires a big program. Start with three changes in the next sprint: require a written explanation in every pull request, schedule one assistant-free task per junior, and add a weekly fifteen-minute walkthrough where they explain something they shipped. Review how it is going after a month and adjust.
If your team is working through the broader question of how to roll these tools out safely, 137Foundry's AI automation team helps engineering groups set up the workflows, review practices, and guardrails that make AI-assisted development sustainable. You can also see the full range of work on the 137Foundry services page, or get in touch through the 137Foundry homepage.
