Imagine you've handed a reasonably complex task to two people in your organisation. Both are fluent with AI tools, both write a good prompt, and both have access to the same information. One is a senior partner with twenty years' experience. The other is a recent graduate. I don't need to tell you how this ends: the senior produces something close to client-ready; the junior produces something plausible, polished, and probably wrong.
That gap tells us what "good at AI" actually measures. Most of the advice a leader receives is to get fluent with the tools, learn to prompt, build the habit of reaching for AI. This puts the emphasis on operating skill, which is useful as far as it goes (it's advice I often give). But it describes the steering wheel, not the destination. The real test is whether the tool enables you to produce something you otherwise could not, faster or at a higher standard. Measured that way, the senior and the junior are not separated by their command of the tool - they are separated by their expertise. Getting better at a tool does not close a gap made of something else.
This ground is now well trodden, as is the related commentary on the enduring importance of domain judgement and what it means for your junior pipeline. Less explored is what it means one level up. Executive judgement (your ability to make wise choices in complex situations) is itself largely a matter of skilled intuition. These are the calls that reach your desk precisely because there is no rule or check that would allow you to delegate them (is this the right hire, the right market, the right moment). So the question underneath our partner and the junior is really a question about expertise and intuition: when they can be trusted, when they cannot, and what AI does to the difference.
It was these questions that led me to a paper Daniel Kahneman and Gary Klein published in 2009. The two of them had spent their careers approaching expertise from opposite ends: Kahneman documenting how intuition misleads us, Klein documenting how experts read a situation at a glance and mostly get it right. The paper is their attempt to work out where they disagreed (the title gives it away: they mostly didn't). I won't recap the full discussion here, but their ideas have helped me understand the patterns in AI adoption I've observed since I started working closely with executives almost a year ago.
One such idea: when does experience produce real skill, and when does it only produce confidence? Kahneman and Klein's answer turns on two conditions: (1) there has to be genuine signal in the environment - real, repeating regularities that link what you see to what happens; and (2) you have to get feedback clearly and quickly enough to learn what they are. Where both conditions are met, experience compounds into something you can trust. Where either fails, experience may still produce confidence, but it doesn't produce skill. The troubling part is that we often can't tell which is which from the inside, so how sure we feel is no guide to whether our certainty has been earned.
What struck me is that this paper doesn't just apply to people. The first condition, genuine signal in the environment, says nothing about the expert. It's a fact about the task. Where the regularities aren't there, no amount of experience will find them. Neither will a machine because there is nothing to learn. A human and an AI are not built the same way; the partner learned from her own years of experience, the model from a corpus assembled before it ever saw your work. But they answer to the same environment. Where the signal is real, each can become reliable, the human through experience, the machine through training. Where it is not, both can produce fluent, confident output with nothing underneath it.
The clearest place to see this is software engineering, the field furthest along in AI use. It would be easy to dismiss that as irrelevant to your work, or a weak signal at best. In fact it is the most instructive case we have, because the same line runs through the work an executive does. Watch how experienced engineers use AI and a split appears, not between the tasks they give it and the tasks they keep, but between two ways of using it. Where the work can be checked cheaply and at once (does the code run, does the test pass), they hand it over and let it run, because a mistake surfaces in seconds. Where it can't (is this the right architecture), they don't delegate. They think it through with the AI instead. The checkable work, the AI does for them. The work that turns on judgement, it helps them do.
Your work has fewer "checkable" tasks, and not by accident. The high-signal, fast-feedback tasks, the kind an engineer lives in, have been handed off as you've risen. What is left to you is the residue that cannot be cheaply checked: the critical hire, the partner who needs managing, the client who is quietly unhappy. Often, you will never know if the decisions you make or the presentations you give are optimal (or sometimes even good), and you can rarely trace an outcome back to the decision that produced it. But there are parts of your work where the conditions Kahneman and Klein laid out can be created, and parts where they can't.
For once the sheer volume of emails sent and received helps us out. Start with what you can hand over. You can teach an AI to sort your inbox and draft the routine replies, and you teach it by supplying the cues: examples of what each kind of message is and how you answer it. Where the pattern is strong and sits on the surface, a handful of examples is enough. Where it is subtler, you need more, and more varied ones, before the AI can find it. The larger and more diverse the set you give it, the wider the slice of your inbox it can take off your hands. What you cannot do is conjure a pattern that is not there: where the signal is absent, no volume of examples will find one.
Then there are the emails where you hold the pen. You know which they are without necessarily knowing why. Reading between the lines, you can tell that a client is quietly signalling she is about to leave, or that a regulator's "quick clarifying question" is nothing of the sort. Nothing on the surface separates them from the two hundred the AI handles well. What separates them is something you sense rather than see. AI does not have this type of skilled intuition and you can't teach it. It still has a role to play, just in another mode, as a partner to think the email through with, to test what she is really saying and sharpen your reply. What you cannot do is hand it over. In these cases it's the junior, not the senior.
Step back from the inbox and the same shape governs your whole desk. For any piece of work, the question is not whether to use AI but in which of two modes. Where you can cheaply check the result, you hand it over and let the AI carry it. Where you cannot, you keep the pen and use the AI to think against, not to decide for. The hard part is not learning how to work with AI in each mode. It is telling, in the moment, which one the work in front of you calls for. The costly error is not refusing to use AI. It is delegating, in full confidence, a judgement you could never have verified, and only the same instinct that flagged the client's email will tell you that you have done it.
So being good at AI turns out to be downstream of being good at judgement, and not in the way the advice assumes. It is not the skill of working the tool. It is the older skill of knowing which of your decisions have a right answer you could check, and which only ever had your judgement standing behind them. How you build and trust that judgement, when the machine can imitate its output but not its source, is where this goes next.
Sources
Kahneman, D., & Klein, G. (2009). Conditions for intuitive expertise: A failure to disagree. American Psychologist, 64(6), 515-526. https://doi.org/10.1037/a0016755