What is capability overhang, and what should an organization do about it?

What capability overhang means

In a recent interview, Professor Jaewook Lee of Seoul National University's Department of Computer Science raised the idea of capability overhang: AI models mature very quickly, while the skill of the average person using them grows far more slowly. The consequence he drew is that the productivity gap between power users and average users keeps widening.

Take the words apart. Capability is what the tool can do. An overhang is the part of a structure that juts out over what is below it, like the eaves of a roof. Put together, the phrase names the performance a tool already has but that people have not yet learned to draw on — capability hanging over our heads, unused.

An analogy: a company hands everyone the latest camera. The cameras improve every year, but photography skill does not improve at that pace. Most people shoot in automatic mode, and a few learn aperture and shutter speed and pull out what the camera was always able to do. The better the camera gets, the further apart those two groups' photos become. That is what is happening with AI tools right now.

The important part is that an overhang is not a defect in the tool. The tool is doing its job. The unused capability piles up because the judgment needed to draw on it has not grown as fast. Which means buying a better tool does not solve it.

Why a better tool widens the gap

Intuition says the opposite. Smarter tools should flatten the difference between novices and experts, and in some domains they do. Where the correct output is fixed — spell checkers, translation — everyone converges as the tool improves.

But with AI tools, the human decides what to assign. As the list of assignable work grows, results diverge according to how much of that list you know about. When the tool can do ten things, the gap between knowing and not knowing spans ten things. When it can do a hundred, the gap spans a hundred. Rising capability increases the amplitude of 'you use it as far as you know it.'

Then compounding sets in. Strong users buy time with the tool and spend that time learning the tool. Average users free up less time and so have less time to learn. A month later the two are further apart than when they started.

What strong users actually do differently

Professor Lee named two conditions. First, knowing the range of tasks the tool can actually take on. Second, knowing where it stops working. Those two separate power users from average ones.

Note what is absent: any mention of writing elegant prompts. This is not a matter of phrasing but of how much of the tool's map you hold — where its territory ends and yours begins.

Of the two, limits are the harder half. The list of what works grows just by watching others. What does not work is different. How far you can trust a delegation is known only to someone who delegated and got back an answer that was confidently wrong. That instinct does not come from a lecture.

In practice the difference shows up like this.

Why a company-wide license changes so little

Many companies frame AX as a tool rollout: sign the contract, distribute logins, track adoption. Rising adoption reads as success. Once you understand overhang, the flaw is visible — distributing accounts equally does not distribute capability equally.

What actually happens is familiar. A few people who were always quick to adopt get dramatically faster. The middle majority keep the login and use it as a better search box or a phrasing cleanup. Some try twice, get a strange answer, and quietly stop. Adoption numbers rise while output concentrates in a handful of people.

Left alone, this creates two costs. The visible one is unused seats. The invisible one is that whatever the strong users figured out stays inside them. An individual learned something; the organization did not.

So the real question changes. Not what to roll out next, but who is using what is already here, how far, and how to close the distance between them.

For individuals: limits are learned by failing

At the individual level the remedy is simple. Take one real task you have in front of you and hand the whole thing to the AI. If it works, your list of what works grows by one. If it comes back wrong, your list of what does not grows by one. Either way you gained something.

Professor Lee gave the same advice to people outside computer science: assume that most of the problems you face can be solved with AI, then actually try to solve one small real project that way. Repeat it enough times and you develop a feel for what the tool is good at and what it is not.

Concretely: pick a repetitive task this week that takes more than thirty minutes. Hand it over the way you would hand it to a junior colleague, with the material and the criteria attached. Do not ship the first result — point out what is wrong and run it again. If it still fails after about three rounds, write it down as 'not yet.'

That last step is the one people skip. Most quietly give up and record nothing. But the not-yet list is exactly what you want to pull out again once the tools improve. Six months later, half of it will already work.

Measure distribution, not adoption

If the gap is the problem, the measurement has to look at the gap. Adoption tells you who logged in, not who can now do what. Averages have the same flaw: a few strong users can lift the mean while the middle stands still.

So look at the distribution. Not what the top few pulled off, but what the person in the middle can do this month that they could not do last month. An organization that can answer that is managing AX. One that cannot has merely bought a tool.

Measuring it need not be elaborate. Two lines per person per quarter is enough: one task successfully delegated to AI, one that was delegated and failed. Stacked up, those lines reveal where each person stands and which kinds of work the whole organization is stuck on.

If you want a number, count how many kinds of work a person can now handle alone — a far more honest indicator than usage counts. Frequency measures habit; range measures capability.

Four mechanisms that close the gap

First, put the strong users' screen on display — the process, not the artifact. What they asked, how the first answer was wrong, what they said to fix it. Sharing only the finished prompt teaches nothing. What people need is the order of judgments, not the sentence.

Second, treat failures as assets. Keep the not-yet list at team level and re-test it every quarter. As noted, each tool improvement converts a chunk of that list into work that now succeeds. Organizations that delete their failures never collect that return.

Third, hand out time as policy. Much of the gap comes not from talent but from time allocation. Strong users already bought time and reinvest it in learning; those still behind have none to reinvest. Thirty minutes a week of experimentation inside working hours beats telling people to learn on their own after hours.

Fourth, put domain knowledge in front. Professor Lee noted that many recent AI competition winners were people who held a good problem from a specific domain. The same holds internally: results come from the person who knows which problem is worth solving, not from the person who knows the tool best.

Three common misreadings

'Training will fix it.' Half true. The range of what works can be taught quickly. The sense of limits only comes from delegating and receiving a wrong answer, so training sticks only when people bring their own real work rather than sit through a lecture.

'A better model will let everyone catch up.' The opposite. As models improve, the list of assignable work widens, and so does the distance between those who know that list and those who do not. Tool progress is a force that widens the gap, not one that closes it.

'Just concentrate the work on whoever is good at it.' Efficient in the short run. The problem is that what that person knows never enters the organization. When they leave, the capability leaves with them. Gap management is not primarily a fairness question — it is the question of whether what was learned stays.