The missing mentor
Think about the best code review comment you ever received. I'll bet you actual money it wasn't "missing semicolon."
It was something like: "This works, but you've named it processData, and in my experience a function that can't be named is a function that hasn't decided what it is yet." Or: "Before you touch this file, know that it's called from the billing cron — a bug here doesn't throw an exception, it silently undercharges customers for a month." Or just, ominously: "Hmm. What happens if two of these run at once?"
None of those comments are about the diff. They're about everything around the diff — twenty years of accumulated instinct, delivered in one sentence, at the exact moment you could absorb it. A senior engineer wasn't reviewing your code. They were, one comment at a time, installing their judgment in your head.
That installation channel is going quiet across the entire industry. And here's the problem with losing it: nobody ever backed up what it carried.
The curriculum that was never written down
There are two kinds of knowledge in engineering. The explicit kind lives in docs, books, style guides — teachable, googleable, and, notably, in the training data. Then there's the tacit kind: naming smells ("a boolean parameter called flag means the author gave up"), blast-radius instincts ("anything touching auth gets three reviewers, I don't care how small"), the archaeology of your specific system ("we tried exactly this in 2021; ask me about the outage"), the meta-skill of knowing which corners are safe to cut this month, in this codebase, given what's on fire.
The tacit kind was never written down — not out of laziness, but because it may not be writable. It's judgment, indexed by situation, and the index is the hard part. The only transmission mechanism anyone ever found for it was apprenticeship: a junior does the work, a senior watches the work, and at precisely the moments when a heuristic is relevant, the heuristic gets spoken. Code review was the delivery vehicle. When Bacchelli and Bird studied modern code review at Microsoft, this is exactly what they found hiding under the process: everyone said review was for finding defects, but the measurable outcomes clustered around knowledge transfer and team awareness — review functioning, in practice, as the firm's continuously running school.
Nobody designed the school. It came free with the workflow. Which means nobody noticed it was load-bearing, which means nobody is noticing it close.
How the channel dies (three small cuts, no villain)
Cut one: the student stopped bringing their own work. Apprenticeship transmits judgment by correcting the learner's decisions. When the junior's PR is generated, the senior's comment lands on the model's decision, not the junior's. "Why did you structure it this way?" — "I didn't." The teaching moment fizzles; there's no wrong belief in a human head to fix, because the human head never formed a belief. You can't apprentice a prompt.
Cut two: the teacher ran out of class time. Mentorship-by-review was funded by slack in the review budget. At AI volume (Part 4), that budget collapsed. A senior skimming their ninth generated PR of the day does not stop to say "let me tell you about the 2021 outage." The war story costs twenty minutes; the queue is charging interest by the hour. The tacit curriculum was always the first thing sacrificed to throughput — it just used to be sacrificed occasionally, and now it's sacrificed structurally.
Cut three: the students found a faster oracle. Why wait a day for Dana's review comment when the model answers in four seconds? For explicit knowledge, honestly — fair. The model knows the docs better than Dana. But the junior can't tell which of their questions were the explicit kind and which were the kind where Dana would have said the thing no document contains: "the code is fine; the approach is going to hurt you in six months, here's why." The model answers the question asked. Dana answered the question you should have asked. That difference is invisible until year three, which is exactly when it's too late to have been getting it.
(Notice there's no villain. Every individual choice — junior saving time, senior clearing queue, org celebrating throughput — is locally rational. The channel dies of a thousand sensible decisions. That's what makes it a systems problem instead of a discipline problem.)
What's actually lost, itemized
Let's be concrete about the cargo, because "mentorship" sounds soft and this cargo is not soft:
- Naming and shape smells — the compressed pattern-matching that flags a design problem from its silhouette, years before it becomes an incident. This is Ousterhout's material: his A Philosophy of Software Design is one of the few serious attempts to write the tacit layer down, and even he frames it as taste that must be developed through iterated design-and-critique, not absorbed from the page.
- Blast-radius instinct — the internal map of which code is load-bearing, which failures are cheap, and where "move fast" quietly becomes "gamble the company." Seniors carry this as felt sense; it's why their review attention is so unevenly, so correctly distributed.
- System theory — Naur's point again: the real program is the theory in heads, and review comments were one of the few mechanisms that copied theory between heads while there was still time to use it. Kill the channel and each departure (Part 1) becomes total loss instead of partial.
- Calibration itself — the junior's sense of "how sure should I be?" was tuned by thousands of micro-corrections. Remove the corrections and calibration is set instead by the model's tone, which (Part 6) is a flat, serene, meaningless line.
The uncomfortable inheritance math
Here's the generational ledger. Current seniors: educated on the old channel, fully loaded with tacit judgment, fine. Current juniors: producing more code than any cohort in history, receiving less judgment-transmission than any cohort since the invention of the profession. The gap doesn't hurt today — the seniors are still here, still quietly catching things. It hurts in five to ten years, when today's juniors are the seniors, and what they have to transmit is… what, exactly? Prompting fluency, genuinely valuable. And a blast-radius instinct that was never installed, teaching a naming sense that was never formed, guarding systems whose theory no one ever held.
An industry that eats its seed corn doesn't starve at dinner. It starves at planting season.
Rebuilding the channel on purpose
You can't mandate war stories, and reinstating slow review is throughput suicide. What you can do is rebuild the channel's two halves deliberately, because both halves can survive the new era in modified form.
Half one: make the tacit explicit where it's cheapest — not the un-writable taste, but the local, factual layer under it. Which modules are load-bearing. Which failures have happened before. Which code is genuinely dangerous versus merely ugly. Most companies store this exclusively in senior hippocampi; every departure is a library fire. Some of it can simply be measured instead of remembered: blast radius, for one, is not actually a mystical instinct — it's traffic, error economics, and position on the hot path, and instruments can hold that map with no attrition risk. (In CodeNSM's fleet, "which functions would hurt us" stopped being oral tradition and became a ranked list; the seniors' instinct, checked against it, is usually right about the top three and wrong about at least one of the next seven — which is itself a mentorship moment.)
Half two: recreate the correction loop. The apprenticeship worked because consequence found the learner. If review can't deliver that anymore, production can: put juniors in front of the live behaviour of what they shipped, and have the seniors narrate that instead of the diff. "Your function's latency doubled under Thursday's load — let's figure out why together" is a 2026-native war story. It's even better than the old kind, in one way: it's about code the junior owns, happening now, with the mentor present.
The mentor isn't obsolete. The mentor's classroom got demolished. Build a new one — deliberately this time, so that when it's load-bearing (it's already load-bearing), somebody knows.
References
- Bacchelli, A. & Bird, C. (2013). Expectations, Outcomes, and Challenges of Modern Code Review. ICSE / Microsoft Research.
- Naur, P. (1985). Programming as Theory Building.
- Ousterhout, J. (2018). A Philosophy of Software Design.
- Forsgren, N., Storey, M-A. et al. (2021). The SPACE of Developer Productivity. ACM Queue.