Leadership Garden
A staff engineer on my platform team spent the better part of three weeks on a design document. Moving a set of services off a shared Postgres instance in an order that wouldn’t take the whole thing down. Careful work. Failure modes were listed out, migration order was argued for rather than asserted, and the parts he wasn’t sure about were left standing as open questions.
The first substantive comment came from someone in a different domain entirely. It opened with, “I ran this past Claude, and it flagged a few things.”
Nine things. Numbered, confidently worded, formatted better than the doc itself. Two were fair. One was a real catch, and I’m glad it got raised. The other six were a language model pattern-matching to a generic database migration and missing everything specific to ours, which was the entire content of the document.
He answered all nine. It took him most of a day.
That day is what this post is about.
What you can do, and what you can judge
Start with two measures, not one.
You’re good at a few tasks and bad at nearly everything else. Rank yourself across every task your company performs, and your proficiency falls off a cliff. I can run a planning conversation, and I can usually tell you why a team is stuck. I can’t design our billing schema, produce a Figma file anyone would want to look at, or close the books for a quarter.
Now take a second measure: how well you can judge the output of a task rather than perform it. That one falls off much more slowly. I haven’t written production code in our main repository in years, and I can still tell when a design doc is dodging its own hard question or when someone’s confidence about a migration isn’t supported by anything that has ever happened here.
The reason I can do that has nothing to do with being clever. I have sat through the postmortem for the version of that migration that went badly twice at two different companies. Judging is memory and memory is experience.
The band between the two, the work you can assess but not produce, is where management lives. A PM who can’t write a line of Go will still catch that the error states are wrong and be right about it. None of that requires being able to do the work. It requires being able to see it.
Every org chart I’ve ever drawn assumes that band exists and holds still.
Then an agent lifts what you can do across most of that range. Not to expert level anywhere, but to roughly competent on a great many tasks where you used to sit at zero, and over a wide stretch of them producing now runs ahead of assessing.
You know that part. It’s been written a dozen times, and I don’t have a better version of it.
What I have is what comes after.
You can’t locate the edge of your own judgement
The comforting response is that sensible people know their limits and ask for help. I believed some version of that for years. The research isn’t kind to it.
Kahneman and Klein spent a long time disagreeing about expert intuition and then wrote a joint paper in 2009 about where they’d converged. Buried in it is something they call fractionation of skill: professionals with real expertise in some tasks get asked to make judgements in adjacent areas where they have none, and the boundary between the two is hard to see. Hard for the professional, and, they add almost in passing, hard for anyone watching. Nothing in the experience of making a judgement tells you which side of the line it came from.
That second half is the one that should bother you if you run performance reviews, because it means I cannot see my engineers’ boundaries either. I have been rating people on judgement for a decade using a method that amounts to noticing when they sound sure.
Most writing on this reaches for Dunning-Kruger about here. I’d rather not, for two reasons.
The literature is genuinely contested and has been for twenty years. Gignac and Zajenkowski ran the analysis in 2020 using tests designed to rule out regression to the mean and failed to find the effect at all. Later work goes back and forth. The pattern replicates, the mechanism is disputed, and citing it as settled is exactly the sort of borrowed confidence this post is about.
It’s also the wrong shape. Dunning-Kruger describes people at the bottom of a single domain. What I’m describing is people who are genuinely excellent in one domain walking into another without noticing they crossed anything. The engineer who sent those nine comments is excellent at what he does. That was never the issue.
The part of the Kahneman and Klein paper I keep returning to is a smaller observation. Subjective confidence, they write, is driven by the internal consistency of the evidence a judgement rests on, rather than by the quality of that evidence. Evidence that’s flimsy but internally coherent produces judgements held with far too much confidence, stated too assertively, and believed by others more than they deserve to be.
Read that again as a description of what comes out of a language model.
Coherence is the thing it’s optimised for. Coherence is also the only instrument most of us have for gauging our own confidence. So the tool now produces, at industrial volume, exactly the input that defeats the gauge.
Your judgement isn’t fixed. It shrinks.
Here’s the assumption I hadn’t examined: that my judgement is a property of me, earned once, sitting there permanently.
Kahneman and Klein are specific about where skilled judgement comes from, and it takes two conditions. The environment has to be regular enough for valid cues to exist, and you need prolonged practice with feedback that arrives fast and unambiguously. Chess has both. Firefighting mostly has both. Long-range strategy has neither, which is why confident five-year forecasts from senior people are worth approximately nothing.
Your ability to judge a code review was built by writing code and then finding out what happened (FAFO, in other words). The ‘finding out’ is the part that did the work. Take it away, and the band narrows.
We now have a measurement of how fast, and it’s worse than I expected.
Anthropic ran a study on 1,053 paid testers using Claude Code, swapping one ordinary permission prompt partway through each session for an obviously dangerous command. Human reviewers caught it 13.6 percent of the time, against 89 percent for the automated classifier. The number I care about is buried under those two: human catch rates ran near 17 percent early in a session and fell to about 5 percent after fifty prompts, while the classifier held flat.
Fifty prompts is one afternoon.
Treat it with the suspicion it deserves. This is vendor data supporting a vendor’s product decision, and Anthropic has published two different figures for how often users approve prompts, 93 percent in one post and 97 percent in another, with no sample size disclosed for either. I would rather have this study run by somebody with no product to ship. Until then, the direction agrees with everything else available. Sonar surveyed over 1,100 developers and found 96 percent don’t fully trust that AI-generated code is functionally correct, while only 48 percent always check it before committing. Thirty-eight percent said reviewing AI output takes more effort than reviewing a colleague’s.
The reviewing costs more, we do it less, and we get worse at it the more of it we do.
And then it happens to other people’s work
Everything above is about judging your own output. The version that cost my engineer a day is second-order, and I think it’s the more serious one.
The standard reassurance here is that people distrust machines, so a bot-sourced objection should land softer than a human one. Logg, Minson and Moore tested that in 2019 across six experiments and found close to the opposite. Laypeople shifted their estimates further toward a piece of advice when they believed an algorithm produced it than when they believed a person did. Algorithm appreciation, they called it.
The detail I like best is that the researchers ran their own materials past a mailing list of judgement and decision-making academics, who predicted the opposite result. The people who study this for a living got the direction wrong.
The effect weakened in exactly one group: experienced professionals forecasting in their own field. Those people took less advice from anyone, and the paper is blunt that their accuracy suffered for it.
Sit with what that combination does to a room. The least qualified person’s objection arrives pre-weighted because a machine produced it. The most qualified person is the one least likely to update on anything, including the occasional time the machine is right. As a distribution of who gets listened to, it’s close to the worst one available.
Then there’s volume, and the workslop research covers that well enough that I won’t repeat it: 40 percent of people surveyed had received AI-generated filler in the previous month, costing them roughly two hours each. But that work is about output being dumped on colleagues, and critique is a worse object than output. You can ignore a bad document. A numbered list of objections against your design creates an obligation, and declining to answer it looks like you can’t.
The cost of generating a plausible objection has gone to roughly zero. The cost of answering one hasn’t moved at all. Anyone in the company can now open an unbounded line of credit against a specialist’s week, and the specialist has no standing to refuse.
That asymmetry is what cost my engineer his day. The quality of the AI output barely mattered.
What I’m actually doing about it
Eighteen months in, I’m running experiments rather than reporting results. Some have earned their place.
Predict, then look
The only way to find out where your judgement actually stops is to make a call and then learn whether it was right. So make the call in writing, before the answer is available.
Concretely, on my team: before you open the agent’s review of your own diff, write down the two things you think it will flag. Before the incident review, write your one-line causal hypothesis. Before you read the vendor’s benchmark, write the number you expect. Keep them in a file with dates on them.
Look at the file every few weeks. Your hit rate, split by domain, is your judgement rendered as data instead of as a feeling, and it’s the only version of it you’ll ever get, because subjective confidence is measuring the wrong thing.
The failures teach more than the hits. If you sit down to write the prediction and find you’ve got nothing to write, you’ve located the edge of your competence precisely in about fifteen seconds, without needing anyone’s permission or a framework or a workshop. That blank line is the entire diagnostic.
There’s a companion question I now ask before approving anything: what would have made me reject this? When I couldn’t answer, what I did was processing rather than review. I’ve been on the wrong side of that distinction plenty of times, usually on a Friday.
Calibrate the machine before trusting it as a judge
Using AI to review AI is the obvious move, and it isn’t automatically wrong. Look again at why Anthropic’s classifier beat their humans. It’s a different model from the one proposing the action; it evaluates a tool call it didn’t generate, and it was measured against 1,053 planted known-bad commands. Independence and ground truth.
Most in-house AI reviews have neither. It’s the same model family reading its own output, and nobody has ever checked whether it catches anything.
The failure mode there is not that the reviewer misses things. Researchers at Emory and Tokyo watched code models gate their own training data using their own confidence signals, and the gate slid into what they call a rubber-stamp regime: acceptance scores climbing while benchmark correctness fell. The reviewer got more satisfied as the work got worse. A metric that improves while the thing it measures degrades is the most expensive kind of instrument to own, and every team I know that has bolted AI review onto their pipeline is currently flying on one without having calibrated it.
The fix is cheap, and almost nobody does it. Once a month, hand your AI reviewer a diff with a known bug in it. Flip a comparison operator. Delete an authorisation check. See whether it says anything at all. If you’ve never run that test, what you have isn’t a reviewer; it’s a reassurance generator. The same test works on your test suite, incidentally, and there it’s called mutation testing.
Write down who decides
This is the one I resisted longest because it sounds like the sort of process a company adds shortly before it loses the ability to ship anything.
For most of my career, the right to overrule someone was rationed by a friction nobody ever wrote down. You didn’t challenge the database expert on index strategy because assembling a credible counter-argument would have cost you a week you didn’t have. That friction was doing real organisational work. It allocated decision rights without anyone having to be explicit about them, and because it was invisible, nobody noticed it doing the job or thought to replace it.
It’s gone. Ninety seconds now buys a credible-looking counter-argument on any topic in the company.
So the allocation has to become explicit, because the mechanism that used to handle it quietly has been removed. Who has the final call on schema changes, on what ships this quarter, on who carries the pager, and on when an incident is over? Written down, in the boring place where such things live.
And one rule attached to it, which is the part that actually helps: an AI-generated critique is an input to the owner, not a claim on the owner’s time. The owner reads it and decides. No point-by-point rebuttal is owed to anyone, and silence on item seven is not a concession.
That reads like bureaucracy. In practice, it’s permission to not respond, which is currently the scarcest resource your specialists have.
The strongest objection
A tech lead I work with pushed back on all of this, and her version was sharp enough that I’ve changed my mind about part of it.
Her argument: this is gatekeeping with better manners. Experts have always deflected challenges with “you don’t have the context,” and a decent fraction of the time the challenge was right and the deflection was self-protection. AI has handed a voice to people who were locked out of technical conversations entirely. And now here’s the head of engineering, explaining why their objections should be easier to dismiss.
She’s right about the old system. I’ve watched it work exactly the way she describes. A principal engineer once killed a proposal from a junior on my team by out-arguing her in a design review. He wasn’t right. He was faster and had more standing, and she didn’t have the vocabulary to defend a good instinct. I said nothing at the time. I’ve thought about it a lot since.
The repair for that was never to make objections free, though. Free objections don’t transfer power to the junior engineer with the good instinct. They transfer it to whoever has the most spare time to generate them, and in my experience that isn’t the person with the sharpest read on the system. What she was actually asking for was that the decision-maker’s reasoning be legible and their record visible. Both of those come from writing predictions down and comparing them to outcomes, which is where this started.
Where this leaves me
I don’t have a number for how often I’m right about work I couldn’t do myself. Neither do you. Nobody has ever measured it, partly because until recently the question had no consequences and partly because the answer would be unflattering to a lot of people whose authority rests on the assumption.
Start measuring it on yourself. Write the prediction down before you look. You’ll find the edge of what you can actually judge inside a month, which is considerably faster than thinking about it will ever get you there.
Then hold the same standard outward and stop accepting critique from people who have never checked where their own edge is. Including, on a bad week, me.