Your best senior engineer spent all of Tuesday reviewing AI-generated pull requests. Not writing anything, not designing anything, just reviewing. Two desks over sits a sharp junior who could carry some of that load, except she is not ready yet, and nobody has the time to get her ready. So the senior keeps drowning, the junior keeps waiting, and the tool burying one of them is the exact tool that could be developing the other.
That last part is the whole opportunity, and most teams walk right past it. We aimed AI at the work. We never thought to aim it at the worker.
Why "they'll learn as they go" stopped being true
Here is the belief worth retiring. We tell ourselves that handing a junior an AI tool makes them productive, and that productivity will turn into skill on its own. It will not. Productivity and development used to travel together because the work contained struggle; remove the struggle and you keep the output and lose the learning.
Used the default way, AI is an answer machine. The junior asks, it answers, the junior pastes, the work ships. Nothing in that loop builds the instinct to question, and the instinct to question is the entire job a senior does that a junior cannot yet. In LeadDev's 2025 survey of more than 880 engineers and leaders, 38% already say AI has reduced the direct mentoring juniors receive. The answer machine is quietly filling the space the mentor used to occupy.
Source: LeadDev AI Impact Report 2025: https://leaddev.com/the-ai-impact-report-2025
Aim the tool at judgment, not output
James Clear put the principle plainly in Atomic Habits: mastery comes from deliberate practice paired with a system for reflection, not from repetition alone. A junior who pastes AI output is repeating. A junior who interrogates AI output is practicing. Your job is to design the second thing.
This is also why the panic about cutting juniors is solvable rather than fatal. McKinsey's Rewired makes the point that generative AI is a partial substitution that reconfigures a role, not a clean replacement; the work changes shape and the people need retraining. Retraining is a choice you can make this week, with the tool you already pay for.
Four ways to point AI at a junior's judgment
None of these require a new tool or a budget. Each one takes something AI does badly for development, handing over answers, and redirects it into something AI does well, generating endless practice. Test them on your own team before you scale them; the prompts below are starting points, not scripts to worship.
1. The flawed-code review drill
Ask AI to generate working code that hides a realistic flaw, then have the junior find it before they are allowed to fix it. This trains the reviewer instinct on low stakes, which is exactly the instinct AI-assisted teams are short on.
The failure mode to watch: AI sometimes plants a flaw so obvious it teaches nothing. If that happens, tell it to make the flaw subtle and plausible, the kind that passes a demo. Pair this with our walkthrough of the common AI code anti-patterns so the junior knows the families of failure to look for.
2. Make it question me, not answer me
Most of the dependency problem disappears with one instruction at the start of a session. Tell the AI to coach, not solve.
The failure mode here is human: the junior gets frustrated and opens a fresh chat for the quick answer. That is fine, and worth naming out loud; the goal is reps, not purity. A senior checking the work once a week keeps the practice honest.
3. The skeptical-stakeholder simulator
Judgment is not only technical. A junior who cannot separate what a stakeholder asked for from what they actually need will write the wrong thing faster with AI, not slower. Use AI to rehearse the conversation.
This builds the product-thinking muscle, separating the problem from the requested solution, which is where most early-career misfires actually begin.
4. The post-mortem sparring partner
When AI-generated work gets reworked, that rework is a free lesson if someone captures it. Have the junior draft the post-mortem and use AI to push them past the first easy answer.
The failure mode here is the dangerous one: AI will happily agree with a wrong root cause stated confidently. So this drill only counts after a senior reads the result. The machine generates the practice; the human still certifies the judgment.
Three ways this backfires
The first is letting AI stay in answer mode. If the junior can get the solution handed to them, they will, because deadlines are real. The fix is the coaching instruction above, set once at the start of a session.
The second is skipping the human debrief. AI can run a thousand practice reps and still certify a confident wrong answer, so practice without a senior closing the loop can teach bad instincts faster than no practice at all. Fifteen minutes of a senior reviewing the junior's reasoning is the part that makes it real.
The third is making it generic. A Scrum Master, a product owner, and an engineer should drill different judgment, because their work is different; one curriculum for everyone is a curriculum for no one. I made that case for AI skills in general, and it applies double here.
Try this next week
Pick one junior and run the flawed-code drill once. Use the first prompt above to generate a working function with a hidden flaw, hand it over, and ask them to find it before fixing it. Give them ten minutes, then spend fifteen comparing notes on what they caught and what they missed.
It works because it rebuilds the exact loop AI erased: attempt, miss, get corrected, improve, with the senior present for the correction that matters. Once that one drill is a habit, rotate in a second one the next week. You are not adding a program; you are aiming a tool you already own at the person you were about to give up on.
If you want a structured version of this for product roles, our AI for Product Owners micro-credential builds the same evaluation skill on real product artifacts rather than toy examples, and you can find the schedule on our public courses page.
Once a junior can actually review AI output, the next question is who signs their name to it. This is the reviewer-of-record model that turns developed judgment into real accountability.