The Disappearing Apprenticeship
The feature shipped. Nobody checked whether its author could explain the important decisions.
What it is
The Disappearing Apprenticeship is a team process that counts AI-assisted delivery as evidence of learning without checking whether engineers are developing judgment. Implementation gets faster while opportunities to diagnose failures, weigh tradeoffs, and own decisions can disappear. The team controls the assignments, review process, and time available for learning. Shipping alone does not tell it which skills are growing.
How it happens
The senior is busy. The AI is available. The engineer ships the feature, the review checks the diff, and everyone moves on. Nobody has to say “cancel mentorship” for mentorship to vanish from the calendar. Throughput has a dashboard. Understanding has a vague assurance that people are picking it up as they go.
Consider an illustrative retry handler. An engineer uses AI to add retries around an order-creation request. The happy path works. In review, the mentor asks: “What if the server created the order but the response timed out?” Predicting the second request’s effect, checking the API’s duplicate-request behavior, and testing that case are the learning opportunity. Manually typing the retry loop was never the point.
Why it’s dangerous
A team needs people who can explain why a design fits, notice when its assumptions stop holding, and challenge a generated solution. If nobody gets practice doing that, a growing pile of shipped work can conceal a shortage of people ready to own the next difficult decision.
AI can also make learning easier: an engineer can investigate unfamiliar code, ask for counterexamples, and try approaches that would otherwise take too long. A feature produced with extensive AI help says little either way. Look at what the engineer can diagnose and adapt when the next problem differs from the example they just completed.
How to prevent it
Name the skill to practice on selected work. For the retry example, simulate the lost response in a sandbox and ask the engineer to trace what happened. Then vary the case: two requests arrive concurrently, or the retry arrives after the deduplication record expires. Let them use AI and documentation, but ask them to choose the next check and interpret its result. Reciting a generated explanation is a much easier task than diagnosing a changed situation.
Do not turn every task into an oral exam or make avoidable struggle a virtue. Use AI freely for routine delivery. Protect time for practice where someone needs to learn a concept, including small exercises that are safe to get wrong. A tutoring prompt is a useful tool; it is not evidence that learning happened.
The serious team fix
- Assign both work and a learning goal. “Implement retries and explain what prevents duplicate orders” gives an engineer and mentor something concrete to discuss. Adapt the goal to experience; a senior learning a new domain needs practice too.
- Use AI for questions, examples, and feedback. Ask it to challenge a proposed design, offer a hint before a solution, or generate a failure case to investigate. Review its advice against documentation and observed behavior. Keep a human mentor responsible for the learning plan.
- Make room to demonstrate understanding. Reserve pairing time and let engineers own bounded decisions with support. Return to a related problem later and see whether they can diagnose and adapt the approach. Use that evidence to choose the next assignment, not to rank people by how polished their explanations sound. The mentor needs time allocated for this work, not just responsibility for fitting it around a full delivery schedule.