Leading AI Is a Trust Discipline

A leader's job is to place trust well — to decide what to ship, what to believe, whom to back, and to be right often enough that others can rely on the judgment. AI makes this harder in a specific and underappreciated way. The tools produce work that carries every signal of being trustworthy without being trustworthy, and they fool the person closest to the work most of all.

That is the whole problem, and it has a whole answer, and the answer is not the one currently in fashion.

The case for stepping back, and where it breaks

The fashionable answer is to get off the keyboard. As the tools improve, the argument goes, a leader's hands on the work become a smell — craft nostalgia, or failure to delegate. The mature posture is oversight from above: set the objective, let the machine build and check its own output, step in only when it reports a problem.

For most of the work, this is correct. Reversible changes, low-stakes tooling, the scaffolding no one will read again — step back, and don't apologize for it. Supervising everything is its own failure; it doesn't scale and it insults the people you hired.

But the argument contains a quiet assumption that collapses under pressure: that you can judge work from its report. You cannot, because the report is the first thing the tools learn to make convincing. Oversight from a distance means trusting the summary — and the summary is exactly what now looks right whether or not it is right. Step back far enough and you haven't risen above the work. You've lost the ability to tell when it's lying to you.

The instrument scan

Pilots learn something that does not survive contact with intuition: in cloud, at night, with no horizon, your body lies to you. The inner ear reports level flight in a slow climb, straight-and-level in a turn. What keeps the aircraft out of the ground is the instrument scan — a trained, continuous sweep across the gauges, trusting the instruments over the sensation, cross-checking each reading against the others so that when one fails, the lie shows up as a disagreement instead of passing silently into the pilot's hands.

The scan is not knowledge you acquire once. It is a live skill, and it decays without use — fastest in the pilots who automate the most, because the autopilot flies so well for so long that scanning feels redundant. Until the day it feeds a wrong reading and there is no trained sense left to contradict it. The report never says the pilot lacked intelligence. It says the pilot had lost the scan.

An engineering leader who has stepped all the way back has lost the scan. Not the ability to write code — that is not the point. What is lost is calibration: the current, felt sense of what the systems do under load, where they are brittle, how the tools behave in the friction of this codebase rather than in a demo. That sense does not transfer by summary. It is earned by proximity, and it decays without it.

This is why a disengaged leader's failures never look like failures of intelligence. They look like a run of reasonable decisions that add up to a place no one meant to go. A platform gets standardized on a vendor demo and a team's summary; it performs beautifully in the controlled case and falls apart in the edge cases that turn out to be half the real work — and no one in the room had been close enough to know which question would have surfaced that.

The maker is the worst judge

There is a specific way the instruments lie, and it is the one a distant leader is least able to catch.

The most reliable finding in the recent studies of AI-assisted work is not that the tools make people faster. It is that people are wrong about whether the tools made them faster — and wrong in the optimistic direction. The work feels fast. The keyboard is busy, the suggestions land quickly, the flow is real. The brain reads the new texture as speed, and the clock disagrees.

The reason is structural. Generating code was never the slow part; only a fraction of engineering time went to it. The slow part — deciding what should exist, integrating it, proving it holds — is what the machine does not compress and is exactly where it pushes the work. So more gets produced, and the cost of sorting good from plausible moves downstream onto whoever reviews it. The person who generated the change is the person least able to see this, because to them it felt like progress the whole time.

Which is the flaw in oversight-from-above, stated precisely: it trusts the self-report of the party with the least reliable view. A leader inside that report sees rising output and calls it progress. A leader with the scan sees the same numbers and asks where the displaced cost went, and whether the thing shipping faster is the thing that matters.

What staying close actually means

"Stay close" is useless as advice if it means review more. Skimming a clean-looking diff and approving it is not proximity; it is the fooled version of it, performed at volume. Real proximity is depth at the few places where work is hardest to fake — and deliberate distance everywhere else.

In practice it looks like this. Build something real, occasionally. Take a live ticket end to end, a few times a quarter, with the same tools the team uses. Nothing else tells you where the tools lie here — what they botch in this codebase, how the review burden actually falls. It is flight hours, and there is no substitute. I still do this, and every time it corrects some belief about the tooling I had been holding confidently and wrongly.

Read the incidents, not the dashboards. Postmortems are where the gap between looked right and was right becomes visible; green dashboards are where it hides. Spend your judgment on the irreversible calls — the schema migration, the auth boundary, the dependency you can't back out of — and let the reversible rest go freely. Being wrong is cheap when you can undo it; that is where to extend trust, not withhold it. And make "how does this break" the first question, not the last — asked out loud, early, as a norm. The happy path always demos well. The failure modes are what you are actually being asked to trust.

None of this is about heroics or authorship. It is about staying calibrated enough to tell confidence from credibility — in the machine's output, in the team's velocity, and in your own sense that things are fine.

The precondition, not the job

Calibration is where this starts. It is not where it ends. Keeping the scan earns a leader the standing to judge — but judgment sitting in one head changes nothing on its own. The scan is a precondition for the harder work: deciding what, and whom, to actually vouch for, when the things asking to be trusted are a bold engineer moving faster than their judgment, a machine that grades its own work, and a generation of people who have not been hired yet.

That is the real job — where trust gets placed, not merely kept. But none of it is available to a leader being lied to by their own instruments. You cannot vouch for others while you cannot read your own gauges. Earn the scan first. Then the placing of trust becomes possible — which is the whole of the work, and what comes next.