Capability Debt: The Skills You Stop Practicing Don't Wait for You

The Capability You Can't Tell You've Lost

Imagine a director putting a recommendation in front of three colleagues.

It took her twenty minutes to produce. The structure is clean. The numbers reconcile. The risks are ranked, the alternatives compared, and the conclusion looks sound.

Then someone asks a straightforward question: why this option and not the second one?

She knows the answer is in the document. What she cannot do, standing in the room without reopening the AI conversation, is reconstruct the reasoning that produced it. She reviewed the recommendation, agreed with it, and presented it. She did not build the argument herself.

Nothing necessarily went wrong. The recommendation might be entirely correct. The problem is that her organization measured the quality of the output, not whether the person responsible could still account for it.

That gap has a name that's starting to circulate in workforce and training circles: capability debt.

It's the understanding you gradually stop exercising because a tool has started doing the work for you, even though you're still expected to catch its mistakes, make the decisions, and own the results.

Software developers will recognize the shape of it from technical debt: a shortcut that makes development faster today but creates work that has to be paid back later. Capability debt follows the same pattern, except the debt isn't buried in the code. It builds up in the people who rely on the tool: the engineer who can approve code but struggles to explain its logic, the analyst who recognizes a convincing forecast but can no longer challenge its assumptions, the manager who signs off on reasoning that has become someone else's.

And unlike a broken application, capability debt doesn't announce itself with an error message. The code works. The report looks right. The decision gets approved. Nobody notices the difference between having a capability and having access to one.

The debt comes due when access is not enough: when something unexpected happens and you can no longer explain, repair, or defend what the system produced.

Figure 01

The gap you can't see from the output

None of this is an argument that AI fails to make us more productive. It does. In a 2023 randomized experiment published in Science, Shakked Noy and Whitney Zhang gave 453 college-educated professionals occupation-specific writing tasks and granted half of them access to ChatGPT.

Giving those gains back would be a strange prescription.

But that experiment measured performance with the tool in hand. It never asked what participants would retain after months of delegation. Which leaves a different question:

If you have stopped performing the reasoning yourself, what exactly are you still qualified to supervise?

An Irony We Discovered Forty Years Ago

In 1983, psychologist Lisanne Bainbridge published a short paper in Automatica titled Ironies of Automation.

When engineers automate a process, she observed, they automate the frequent, predictable work first. Humans are left to monitor, recognize abnormalities, and intervene when the system can't cope. Those leftover tasks are the hardest ones, and the operator is expected to take over precisely when the situation is unusual and the routine no longer applies. Meanwhile, the automation has removed the regular practice that kept the operator prepared.

The more successful the automation, the fewer chances the person has to exercise the skills that matter during failure. The human stays accountable for the exceptional case while becoming steadily less practiced at handling it.

Bainbridge was writing about industrial process control, not generative AI, and her work doesn't show that AI is deskilling anyone today. But the structure transfers. An assistant drafts the code, builds the analysis, and proposes the decision. The human is left to verify it.

Verification, though, isn't detached from understanding. Recognizing a flawed recommendation takes enough knowledge to find the mistaken assumption. Detecting a faulty implementation takes a mental model of how the system should behave.

The ability to recognize wrongness depends, at least partly, on the understanding that repeated delegation may stop exercising.

That is the central risk of capability debt. And because exceptional situations are rare, the loss can stay hidden for years.

But We Don't Need to Remember Everything

There's an obvious objection. Nobody does long division by hand anymore. Calculators displaced routine arithmetic, navigation apps replaced memorized routes, and people still reach their destinations. Why should AI be different?

The objection is right about something important: losing a skill isn't automatically a problem. Evan Risko and Sam Gilbert described cognitive offloading in a 2016 review as using external tools and actions to reduce mental demand. It's an ordinary part of human intelligence.

The research doesn't support a simple story of decline, either. A 1986 review combining 79 studies found that students using calculators alongside instruction generally kept their paper-and-pencil skills. A 2024 review of 23 navigation studies found GPS use negatively associated with environmental knowledge and sense of direction, but not with reaching the destination. Those effects were small and the evidence limited, but the shape is telling: the visible outcome held while the skills underneath it changed.

Sometimes that trade is worth it. The distinction that matters is between a skill a tool permanently replaces and a skill you still need to evaluate or recover the tool's work.

You don't need to calculate square roots by hand. You do need enough numerical sense to spot an implausible result. A developer needn't write every routine function, but still needs to understand how data moves through a system, how it fails, and where it's open to attack once generated code reaches real users.

Capability debt isn't the loss of every unused skill. It's the erosion of a capability that remains necessary after its routine exercise has been delegated. The aim isn't to protect obsolete work. It's to identify the parts of human competence that automation still depends on.

When the Fallback Fails

On June 1, 2009, Air France Flight 447 disappeared over the Atlantic while flying from Rio de Janeiro to Paris. All 228 people aboard died.

Ice crystals temporarily blocked the aircraft's pitot probes, the sensors that measure airspeed, producing inconsistent readings. The autopilot disconnected, the flight-control system changed mode, and the crew had to manage an unexpected situation by hand at high altitude. The flight path destabilized, stall warnings sounded, and the crew did not recognize and recover from the stall, the point at which the wings stop producing enough lift.

The French BEA's final report, published in 2012, identified several interacting factors, including gaps in training for manual handling at high altitude, difficulty interpreting unreliable airspeed, disrupted crew coordination, and failure to recognize the stall. It did not conclude that automation caused the accident.

What the accident illustrates is a fallback problem. A system can perform reliably through ordinary operations while leaving its operators poorly prepared for the rare moment their intervention matters most. That is not an argument against autopilot, which has delivered enormous safety benefits. It is an argument against treating the presence of a human as proof that the human can take over.

In January 2013, the FAA issued Safety Alert for Operators 13002, Manual Flight Operations. It acknowledged the benefits of automation while warning that continuous use of autoflight systems does not reinforce manual handling knowledge and skills, and encouraged operators to give pilots regular opportunities to fly by hand. The answer wasn't less automation. It was deliberately preserving the human capability needed when automation could no longer carry the task.

A manager relying on AI faces nothing comparable to a pilot in an in-flight emergency. The analogy concerns the design problem, not the severity. When an organization keeps a human responsible for exceptional judgment, it has to preserve the conditions that make that judgment possible.

Responsibility without practiced capability is a fragile arrangement.

How Capability Debt Accumulates

Capability debt rarely arrives as obvious deterioration. It usually begins as improvement.

At first, the AI drafts and you edit. Then it structures the work and you choose among its options. Later it defines the problem, and you evaluate answers inside a frame it provided. Eventually it suggests which questions you should ask.

Each step makes the task easier, and some genuinely improve quality. None requires a decision to become dependent. But the human role has shifted from generating and questioning ideas to recognizing and approving finished-looking material.

Two findings help explain why the shift is hard to notice.

In a 2025 CHI study, Hao-Ping Lee and colleagues surveyed 319 knowledge workers about their use of generative AI and found a self-reported shift from gathering information to verifying it, from solving problems to integrating responses, and from doing tasks to supervising them. That isn't proof of lost capability, and supervising is a real skill. But it shows how the nature of work can change while people stay fully engaged.

A 2010 review by Raja Parasuraman and Dietrich Manzey described automation complacency as an attention problem: reliable systems, repeated positive experience, and competing workload all reduce the attention people give to monitoring. That combination should sound familiar. A good model produces useful work repeatedly, checking rarely turns anything up, deadlines tighten, and the user learns that a quick review is enough.

The problem isn't laziness. Successful automation creates the very conditions under which independent verification gets less attention.

Generative AI adds one more factor. A calculator returns a number and a search engine returns sources, but an assistant returns an argument, a plan, and an explanation, already polished into a coherent whole. The work no longer looks like raw material. It arrives looking complete, which makes reviewing feel more like understanding than it is.

The Difference Between Performance and Capability

One of the most revealing AI studies asked what happens after the tool disappears.

In a randomized experiment published in PNAS in 2025, Hamsa Bastani and colleagues gave high-school students GPT-4-based math tutors. Students using a relatively unrestricted interface performed better while they had it. When access was withdrawn, they scored about 17% lower than students who had never used it. A "scaffolded" tutor, designed to walk students through the problem rather than hand over answers, largely avoided that penalty.

Professional evidence is more mixed. In The Lancet Gastroenterology & Hepatology in 2025, Krzysztof Budzyń and colleagues found that in colonoscopies performed without AI, the rate at which doctors spotted precancerous growths (adenomas) fell after AI assistance was introduced.

Evidence also points the other way. Erik Brynjolfsson, Danielle Li, and Lindsey Raymond studied 5,172 customer-support agents after a generative AI assistant was introduced. Productivity rose about 15%, with the biggest gains among less experienced workers, as the assistant spread knowledge once concentrated among top performers. That isn't deskilling. It's capability being redistributed.

AI can support learning, change skill requirements, or create dependency, depending on the worker, the task, and the form of assistance. We still lack strong long-term evidence, from studies that follow the same people over time, establishing how sustained AI delegation changes independent judgment among experienced knowledge workers. But organizations don't need a complete record to start asking which capabilities their people are still expected to exercise on their own.

What organizations measure

• Speed of delivery
• Quality of the finished artifact
• Throughput per person
• Whether the output was approved

What they rarely measure

• Whether the owner can explain the reasoning
• Whether they could rebuild it another way
• Whether they can defend it under challenge
• Whether they could do it at all unassisted

Code That Only Works Under the Conditions It Was Written For

A solution can be technically correct and still fail in production. Often the problem isn't the implementation itself but an assumption about the environment it runs in. Tutorials, forum answers, and AI-generated fixes all carry those assumptions quietly.

The user is still logged in. The request arrives once, not twice. The outside service returns what its documentation promises. The user does what the designers expected.

In production, something usually doesn't.

AI makes that gap harder to see, because generated code arrives finished. It compiles, the types check, the tests pass. Consider AI-generated login code that works in every test yet quietly assumes the user's session is still valid, and breaks when that login expires partway through a request. Nothing in the code announces the assumption. Spotting it takes a working model of the system: what it trusts, what can change underneath it, and how it behaves when something goes wrong. Developers build that model by tracing failures themselves.

Passing tests tells us something about the conditions we've examined. It doesn't guarantee that the assumptions we never tested will hold in production.

That's where capability debt lives in software. Writing code is getting cheaper every month. Understanding how a system behaves, spotting hidden assumptions, and recognizing when it will fail remain much harder to automate. Those skills are built through active reasoning, and you can't measure them by counting how much working code a developer ships.

This is the individual version of a problem that scales. The New Business Skill Is Understanding Systems follows the same logic up to the level of a whole business, where the question becomes who understands the system well enough to notice when it is quietly wrong.

The Three Questions That Reveal the Debt

If capability debt accumulates quietly, how do you look for it?

Here's a simple heuristic. It isn't a validated test. It's a way to expose the gap between the quality of an output and your ability to account for it.

Pick something substantial you produced with AI help this month. Close the conversation, and ask:

• ✓Explain — can I say why this is right? Not why it sounds convincing: name the assumptions, evidence and constraints that support the conclusion.
• ✓Reconstruct — can I rebuild the reasoning another way? Approach the problem from a different direction, or say under what conditions the answer would change. Reconstruction is a different test from recognition.
• ✓Defend — can I hold it under challenge? If a knowledgeable colleague disputes an assumption or proposes an alternative, can I argue for the choice without going back to the AI for the argument?

A gap doesn't prove you've lost a skill. You may never have had it, or the task may sit outside your expertise. But if you're accountable for a conclusion you can't explain, reconstruct, or defend, you're relying on capability you haven't independently established. Three confident answers aren't proof of no debt, either; people can be confidently wrong.

The questions begin an audit. They don't certify competence. What they expose is something output reviews routinely miss: the quality of the artifact and the retained capability of the person who produced it are separate things.

What Teams Can Do About It

Organizations have spent considerable energy teaching people how to use AI. Far fewer have defined which capabilities people should retain after adopting it.

Aviation's response offers a design principle: preserve manual proficiency where it remains necessary, rather than assuming accumulated experience will be enough. For knowledge-work teams, three practices are worth testing.

1. Make reasoning visible, not just outputs

When someone presents a major recommendation, ask them to explain the core reasoning in their own words. Which alternatives were rejected? Which assumptions carry the most weight? What evidence would change the decision?

This isn't about banning notes or demanding performances from memory. It's about confirming that the person responsible understands the decision apart from its polished presentation.

2. Schedule occasional independent work

Pick a few representative tasks and complete them without generative AI. A developer traces a defect through an unfamiliar part of the system. An analyst builds a first model before consulting an assistant. A manager frames a decision before asking for recommendations.

Keep these proportionate, low-risk, and focused on capabilities the team actually needs. They shouldn't become productivity theater or punishment for using approved tools. The right time to discover a skill needs reinforcement is during a controlled exercise, not an urgent failure.

3. Separate output quality from independent readiness

Teams already measure speed, throughput, and outcomes. They should also ask whether the people responsible for critical decisions can handle the exceptions: through periodic code walkthroughs, reasoning reviews, independent diagnoses, or scenario exercises.

One team can use AI extensively and keep excellent independent judgment. Another can look highly productive while quietly concentrating its critical knowledge in its tools. The point is to tell those situations apart before something forces the distinction.

The objective is not an AI-free workplace. It is an AI-enabled workplace that knows which human capabilities it still depends on.

Capability Debt Is Not Inevitable

Technical debt can be a deliberate trade: ship quickly now, reinforce later. Capability debt can work the same way. Some skills will become less valuable, and a good organization should let obsolete work disappear. It should be equally deliberate about preserving the abilities that still matter when circumstances change.

That matters most for people early in their careers. An experienced professional delegates work they learned through years of practice. A newcomer may never do enough of that work to build the understanding in the first place. That's two problems, not one: maintaining established capability, and forming it at all. Both need more research, and we took up the second one in Who Will Train the Humans Who Supervise AI?

In the meantime, the guided-tutor result points to a design possibility. An assistant that asks you to make an initial judgment, challenges your assumptions, or helps you diagnose your own mistakes may preserve learning that an instant finished answer removes. Whether that holds for experienced professionals is still uncertain, but it avoids a false choice. Productivity and competence don't have to trade off against each other. We can design workflows that take both seriously.

The Work You Keep for Yourself

Return to the director in the meeting.

Her recommendation may still be right. The awkward moment didn't prove she was incompetent or that using AI was a mistake. It revealed the gap between reviewing a conclusion and being able to account for it.

Imagine that afterward she makes a short list. Not tasks she refuses to automate, but capabilities she intends to keep practicing.

She'll frame the central question herself before asking AI for alternatives. She'll examine the assumptions behind consequential recommendations. She'll reconstruct the reasoning behind decisions she's expected to defend. And now and then she'll work through a hard problem unassisted, not because the slow way is better, but because the skill still matters when the assistance fails.

She may keep using AI for nearly everything else. Her work may keep improving. But there is now a deliberate boundary between what she delegates and what she still knows how to do.

The danger is not that the machine becomes capable. It's that we stop noticing which parts of our own capability were keeping us qualified to trust it.

And the bill rarely arrives while everything is working.

Research Behind This Essay

These sources support different parts of the argument. Some are empirical findings; others are conceptual frameworks or historical cases. None measures a general rate at which AI-assisted professionals lose independent judgment.

• Bainbridge, L. (1983). Ironies of Automation. Automatica, 19(6), 775–779. Foundational human-factors analysis of monitoring, skill maintenance, and manual takeover. Predates generative AI.
• Noy, S., & Zhang, W. (2023). Experimental Evidence on the Productivity Effects of Generative Artificial Intelligence. Science. Randomized writing experiment with 453 professionals, measuring productivity and quality, not long-term skill retention.
• Risko, E. F., & Gilbert, S. J. (2016). Cognitive Offloading. Trends in Cognitive Sciences. Review of how people use external tools to reduce cognitive demand.
• Hembree, R., & Dessart, D. J. (1986). Effects of Hand-Held Calculators in Precollege Mathematics Education: A Meta-Analysis. Journal for Research in Mathematics Education. Synthesis of 79 studies.
• Parasuraman, R., & Manzey, D. H. (2010). Complacency and Bias in Human Use of Automation: An Attentional Integration. Human Factors. Review of monitoring and attention, drawn mainly from pre-LLM settings.
• Bastani, H., et al. (2025). Generative AI Without Guardrails Can Harm Learning: Evidence from High School Mathematics. PNAS, 122(26). Randomized math-tutoring experiment showing different outcomes after AI access was removed, depending on assistance design.
• Brynjolfsson, E., Li, D., & Raymond, L. R. (2025). Generative AI at Work. Quarterly Journal of Economics, 140(2). Field study of 5,172 support agents; gains concentrated among less experienced workers.
• Lee, H.-P., et al. (2025). The Impact of Generative AI on Critical Thinking. CHI 2025. Survey of 319 knowledge workers on perceived changes in cognitive effort and task responsibilities; not a direct measure of skill loss.
• Budzyń, K., et al. (2025). Endoscopist Deskilling Risk After Exposure to Artificial Intelligence in Colonoscopy. The Lancet Gastroenterology & Hepatology. Colonoscopy performance before and after AI introduction. Observational; cannot establish causation.
• Haslbeck, A., & Hoermann, H.-J. (2016). Flying the Needles: Flight Deck Automation Erodes Fine-Motor Flying Skills Among Airline Pilots. Human Factors. 126 airline pilots; recent manual flight practice versus experience. Concerns psychomotor flying skills.
• Miola, L., et al. (2024). GPS Use and Navigation Ability: A Systematic Review and Meta-Analysis. Journal of Environmental Psychology. Meta-analysis of 23 studies.
• Bureau d'Enquêtes et d'Analyses (2012). Final Report: Air France Flight AF447. Official investigation identifying multiple interacting technical, training, and operational factors.
• Federal Aviation Administration (2013). SAFO 13002: Manual Flight Operations. Guidance on maintaining manual flight proficiency alongside automation.

What the Evidence Does Not Establish

There isn't yet enough longitudinal evidence to quantify capability debt in knowledge work, or to conclude that regular AI use necessarily reduces professional expertise. Student-learning evidence isn't equivalent to evidence about experienced workers. Aviation accidents don't demonstrate the consequences of language-model use. Observational findings don't establish cause.

Capability debt is used here as a framework, supported by related research rather than measured directly. The claim is specific: where people remain accountable for supervising, correcting, or replacing automated work, organizations shouldn't assume that reliable outputs prove retained human readiness.

That is a proposition worth testing, not merely repeating.

For the groundwork on what these systems are and are not good at, see AI Literacy at Work, and for the capabilities that gain value as automation spreads, the human skills that matter more in an AI world.