You Can’t Lead What You’ve Stopped Understanding

Most of the code on my teams now begins as a draft I didn’t write. An agent produces the first pass — the scaffolding, the migration, the function that looks right — and a person picks it up from there. The obvious conclusion is that this is the moment leadership gets to step back from the code for good. The work is getting done; the leader can just lead. I’ve watched myself reach for that conclusion more than once, and I’ve come to think it is exactly backwards.

When output gets cheap, the job stops being about producing code and starts being about judgment — the specific judgment to catch what the agent got confidently wrong. The architecture that reads beautifully and won’t survive the next order of magnitude. The dependency imported with total assurance that does not exist. The model never hedges; it hands you the sound and the broken in the same even tone. The scarce thing is no longer the code. It’s the person who can look at a finished-looking draft and feel, a beat before they can defend it, that something underneath is wrong.

You cannot do that from a distance. That feeling — the one that fires before the reasoning arrives to justify it — isn’t abstract knowledge you can keep in a slide. It’s a kind of touch. You can’t smell a bad abstraction you haven’t put your hands on in years. The leader who reviews from altitude, who reads the summary and the test names and the reassuring green check, is precisely the leader who will wave through the confident wrong thing — because the instruments that catch it are the ones that go dull the moment you stop using them. Distance doesn’t make you a cleaner judge of the work. It makes you a more trusting one, at the exact moment trust is the liability.

So I still build every day. Not much, and not on the critical path — but I am in the codebase, with my own hands, every day. I want to be honest about why, because this is easy to dress up as something nobler than it is. It is not to prove anything; I have nothing left to prove in a pull request. It is not because the team needs me in the code — they don’t, and a leader who needs to be needed there is a problem wearing the costume of a virtue. I build because you cannot lead what you’ve stopped understanding, and understanding is not something you keep by having once had it. It decays the moment you stop touching the material.

There is a real cost here, and a real way to get it wrong, and I’d be lying to skip past them. The cost is hours — time spent staying fluent is time not spent on the things only the leader can do. The failure mode is worse: the executive who stays “hands-on” by reaching into other people’s work, rewriting a junior’s branch to feel sharp again, pulling rank inside a code review. That isn’t staying close to the craft. It’s taking ownership that belongs to someone else and calling the theft diligence. The discipline is to build in my own corners — the spike nobody is waiting on, the prototype, the thing I will throw away — so the instrument stays calibrated without my thumb ever landing on work that isn’t mine. Stay fluent; don’t colonize.

A post by Kevin Solomon, on staying hands-on as you climb, is what set this loose in my head — and the longer I sat with it, the less it read like a point about AI at all. The gap between the people who decide and the people who understand is the oldest quiet hazard of seniority. You get promoted up and away from the work, and a few years on you are making confident calls about a thing you can only see from the outside. AI did not invent that gap. It widened it and made it comfortable — it let you ship more while understanding less, and dressed the trade as progress. The machine took the oldest failure of leadership and made it cheap, fast, and clean enough to mistake for a win.

I’m not romanticizing the code, and I don’t think the agent is the enemy; I take the velocity, I lean on the draft, I’m glad the boilerplate is finally someone else’s problem. The thing I’m holding onto is narrower and more stubborn than nostalgia. Keep one hand on the material. Stay close enough to the thing you’re accountable for that you could still build it yourself — because the day you can’t is the day your judgment has quietly become someone else’s, the model’s or the last engineer who actually understood it, and no one will tell you it happened. I still build every day for the same reason I still read the diff: not to do the work, but to stay someone who can.