What Good Apprenticeship Looks Like When AI Does the Work

You went to fill a senior role last month and found you could not fill it from inside. The people you would normally tap, the ones who can make the architecture call or smell the risky integration before it ships, are the same handful of names they were two years ago. Below them is a team that ships plenty. You just cannot hand any of them the hard judgment yet.

That is not a hiring problem you can fix in a quarter. It is a development problem you stopped solving without noticing, and it has been compounding quietly while everyone celebrated how fast the team was shipping.

The assumption that quietly broke

Here is the belief that got us here. We assume development happens on its own, as a byproduct of doing the work. Give a junior enough tickets, the thinking goes, and judgment shows up eventually. That was always a little bit of a myth, but AI just turned it into a real liability.

The byproduct theory worked because the work used to contain friction. A junior wrote the code, got it wrong, and a senior marked it up. The friction was the lesson. When AI produces a first draft that passes the demo, the friction is gone, and the learning that rode along with it is gone too. Shipping fast and developing people quietly stopped being the same activity.

This is not a hunch. In LeadDev's 2025 survey of more than 880 engineers and leaders, 38% said AI tools have already reduced the direct mentoring juniors get from seniors. A 2025 Stanford study added the other half of the picture: employment for developers in their early twenties has fallen sharply since late 2022, while older cohorts held steady. The bottom of the pipeline is thinning at the exact moment the judgment above it gets more valuable.

Stop developing people by accident

So stop treating development as something that happens while people work, and start treating it as something you design. This is where the old apprenticeship model earns a second look. Not for nostalgia, for its structure.

Notice what that means in an AI-assisted shop. The execution layer, the part AI now handles, was never where apprentices built judgment anyway. They built it in the reasoning around the work: why this design, what could go wrong, what the customer actually meant. That reasoning is still entirely human, and it is still entirely teachable. You just have to assign it on purpose.

I made a version of this case about AI literacy a few weeks back, that people learn skilled judgment by watching it in context, on real work. Apprenticeship has always worked for the same reason. The tools changed; the way judgment forms did not.

A development experience menu: 10 assignments that build judgment

Here is a menu I use with organizations that want to develop people on purpose. None of these require the junior to hand-write the code AI now generates. Every one builds judgment or institutional knowledge that survives whatever the tools do next. Pick from it; you do not run all ten at once.

1. Code review ownership. Make the early-career person the named reviewer on AI-generated pull requests, with a senior reviewing their review. They learn to spot the plausible-but-wrong before they ever learn to prompt; the common AI code anti-patterns make a ready-made first checklist.
2. Architecture decision records. Have them write the why behind a design choice, not just the what. The reasoning is the part that transfers to the next decision, and it becomes institutional memory for the team.
3. Hypothesis writing. Turn a feature request into a testable bet: we believe this change will cause that outcome, measured by this signal. It teaches product judgment, not just delivery.
4. Retrospective facilitation. Have them facilitate a retro, not just attend one. Reading a room and surfacing the real issue is a senior skill, and it can be practiced early.
5. Stakeholder interview synthesis. Send them to interview a stakeholder, then separate the problem the person actually has from the solution they asked for. That gap is where most product judgment lives.
6. Post-mortem authoring. When something breaks, including reworked AI output, have them write the short post-mortem. Causal reasoning is a muscle, and naming a miss safely is a culture you build at the same time.
7. "Spot the flaw" drills. Hand them AI output with a planted weakness and have them find it. It is a low-stakes way to train the reviewer instinct before the stakes are real.
8. Estimation and slicing. Have them break a large item into thin, valuable slices and reason out loud about the uncertainty. This is where the difference between a bet and a guess gets taught.
9. Documenting institutional memory. Assign them to capture why a past approach was abandoned. The tacit knowledge that usually walks out the door with a senior gets written down, and the junior learns the system's history.
10. Teaching it back. Have them run a short session teaching the team something they just learned. Nothing exposes the gaps in your own judgment like having to explain it out loud, which is the whole reason I have spent my career teaching.

Three ways this goes wrong

The first trap is calling it apprenticeship while still handing out tickets. If the assignment is something AI could do, it is execution, not development. The fix is to assign the judgment, not the output.

The second trap is making development one senior's unpaid side quest. "Go mentor the junior" with no time carved out is a wish, not a system. Put the experience and the debrief on the calendar, and protect that time the way you protect a release.

The third trap is measuring the program by activity instead of judgment. Sessions held and hours logged feel like progress, but the only question that matters is whether the person can now make a call they could not make before. Define what that judgment looks like, then watch for it.

Try this next week

Do a five-minute audit. Pull up the menu above and mark, honestly, which of the ten experiences your early-career people actually got in the last month. Most leaders find the answer is one or two, almost always code adjacent.

Then pick one person and one experience, and name the senior accountable for the debrief. Put both on the calendar before Friday. It works because development that is scheduled happens, and development that is merely hoped for does not. Once you have run that single loop and debriefed it honestly, add a second experience the following week.

If you want a structured way to build the evaluation skill specifically for product roles, our AI for Product Owners micro-credential works through it with real product artifacts rather than toy examples, and you can always find me at one of the upcoming public courses.