Who Trains the Next Expert?

I ended a recent essay by dodging a question. This is me coming back to it, still without an answer, because the question got sharper the longer I looked at my own org chart.

The consensus move in AI-era hiring is to buy judgment fully formed. Hire seniors only. Why pay someone to learn on work the tooling already does?

I did the opposite, and I should be honest that it was conviction and circumstance in roughly equal parts. My four-person team is a mix, and most of them are not senior. One was still in college. One was fresh out of a CS degree. They are, by every measure I have published, the best team I have ever led.

I have spent half a year writing about why that worked. This piece is about the part I cannot verify yet, and might not be able to for years.

Where judgment actually comes from

Ask any senior engineer where their judgment came from and you will not get a book title. You will get a list of scars. The production incident they caused. The thousand code reviews, given and received. The years of boilerplate that taught them, through sheer repetition, what normal looks like, which is the only way anyone develops a feel for what abnormal looks like. Judgment is the residue of ten thousand low-stakes repetitions, most of them boring, many of them done badly the first time.

I wrote last week about the difference between knowledge and experience, and the shortest version is that everything I am actually good at, I could not write down, because nobody did. Expertise is like that. The valuable part was never in the documentation. It accumulated through contact with a world that kept disagreeing with the documentation.

Now look at what AI absorbed on my team. The boilerplate. The routine changes. The first draft of nearly everything. Precisely the low-intensity repetitions that used to be the forge. We did not automate expertise. We automated the thing that produced it, and we did it at the exact moment demand for expert judgment went up.

Two problems wearing one name

There are two distinct failures in here, and both of them live on my own team.

The first is renewal. I have written proudly that my newest engineers shipped production PRs in their first week, because the workflow carries the standards. That is true and I stand by it. But shipping in week one is not the same as forming judgment in week one. The thousand small failures that used to happen in a junior engineer's hands now happen inside the model, invisibly, resolved before anyone learns anything from them. The work gets done. Whether the forming happens with it is the thing I cannot yet see.

The second is erosion, and it applies to the other end of the team, and to me. Judgment is a fluency, and fluency decays without contact. My whole system depends on comprehension gates, on someone at each stage who can tell genuinely good work from confidently plausible work. That distinction is exactly the kind of perceptual skill that dulls with disuse. The gates assume the gatekeeper stays sharp. Nothing about the system guarantees it.

Everyone keeps finding this question

I keep watching unrelated people arrive here from different directions. Pierre-Marie Leprince, the Maître Cuisinier whose comment prompted my last piece on this, put it plainly: expertise is one of the critical barriers keeping humans meaningfully in the loop, and it has to be protected, nurtured, and renewed. A room of engineering leaders in Austin landed on the same worry a couple of weeks ago without any prompting from me. And I tripped over it while thinking about my own hiring.

When a master chef, a CTO, and a room full of practitioners keep converging on the same question from unrelated starting points, it is probably the real one.

The industry-level version worries me more than my own. Hiring only seniors is available to every company and rational for each one, and it is what most of the market is doing. But the sum of individually rational moves is a commons problem. Everyone harvests judgment. Nobody farms it. The existing stock of experts ages out on a schedule, and the pipeline behind them is the thing we just automated.

By accident and conviction, I signed up to farm. That does not make me virtuous. It makes me the experiment. My youngest engineers are forming judgment, or failing to form it, inside a gated workflow instead of inside a pile of grunt work, and I will not know which for years. Neither will anyone else running a version of this experiment, because judgment reveals itself slowly and output reveals itself immediately. The dangerous part is that the output looks identical either way.

What I am actually doing, and what I cannot verify

The gates force engagement: nobody on my team advances work they cannot explain, which keeps understanding mandatory even when production is optional. Our debugging workflow refuses guess-and-check and walks a real root-cause investigation, so the thinking still happens even when the typing does not. I stay in the codebase myself. Release ownership rotates, so nobody's hands leave the machinery for long.

And the experienced end of the team mentors, deliberately. I think this is the part most organizations will get wrong. Mentorship reads as extra work, a tax on your most productive people. But the same compression that removed the grunt work also freed the hours it used to consume. The apprenticeship that once happened passively, through a thousand incidental corrections in the flow of production, now has to happen on purpose. That is not additional work. It is the same work, relocated, and seniors who skip it are pocketing the time savings while the pipeline behind them empties.

For the senior end of the team, the gates and the rotation are erosion defenses, and I can watch them work in real time. For the junior end, all of it together is a renewal hypothesis. The bet is that deliberate mentorship, plus being forced to understand, explain, and investigate, can stand in for some real fraction of the repetitions that used to do the forming. I want that to be true. Wanting it does not make it true, and the honest status is that the results are years out.

What I have in the meantime are early signals, and I will take them for what they are. Ownership is arriving earlier than on any team I have led. The youngest engineers have gone from using our workflow to building tools that improve it, and you cannot build tooling for a process you do not understand. The refinements keep coming out of the team's retros rather than out of me. None of that proves judgment is forming, but it is the evidence you get before proof exists, and it points the right direction.

So I am leaving the question open, on purpose, which is not something I enjoy doing in print. The only thing I hold with real confidence is a disposition rather than a solution: stay open to changing the practice, and act when the change earns its case. We are rewriting a large share of how software gets made, and the surest way to fumble the renewal problem is to let legacy practice veto the experiments that might solve it.

We know exactly how experts were made. We automated the forge, for good reasons, every team including mine. Then I hired apprentices anyway and pointed them at the gates instead. Ask me in three years whether that counts as farming or just a slower way of harvesting. What replaces the forge may be the most important open question in this whole transition, and I distrust everyone who currently claims to have the answer, including the version of me that wanted to end this essay with one.