What did the task you just automated used to teach the person doing it?

I ask business owners this question a lot when they tell me how much time AI has saved their team, and it usually stops the conversation for a second. Nobody's calculated it. Everyone's calculated the hours.

That's not a criticism. Hours saved is an easy number to put in a board pack. What a task quietly taught the person doing it is much harder to measure, so it gets left out of the sums entirely. I think that's the biggest blind spot in how organisations are approaching AI adoption right now, and it's one I don't hear discussed nearly enough on the speaking circuit or in the leadership rooms I work in.

For as long as I've been in business, junior roles have worked as an informal apprenticeship, whether anyone designed them that way or not. You built the clumsy first version of the spreadsheet yourself, and in doing so you found out which numbers actually moved the outcome. You sat with someone else's broken code until you understood why it broke, and that's how you started spotting the same failure before it happened again. The task was often slow, and the result was often average. That slowness was doing something useful, even if nobody ever put it on the job description.

Hand the same task to AI and you get the good version straight away. What you don't get is the person standing behind it who actually understands how it was built.

The trade nobody's pricing in

I call this capability debt, and it works exactly like technical debt. You take a faster route today, the invoice doesn't arrive today, and by the time it does, it's expensive and hard to unwind.

The effects don't show up in year one. Reports still land on time. Presentations still look sharp. Productivity dashboards still go up and to the right. What quietly erodes is the number of people in your business who can tell you why an answer is wrong, or notice that it's incomplete, when the situation stops matching anything the model has seen before.

That's the moment this actually bites. A pricing model shifts, a customer segment behaves in a way nobody trained the system on, an edge case appears that no example in the training data prepared for. In those moments you don't need someone who can operate the AI. You need someone who understands the problem well enough to know the AI has got it wrong. That understanding used to come from doing the boring, repetitive, occasionally frustrating version of the job first. Take that away without replacing it, and you're left with people who are excellent at supervising a tool and increasingly unable to work without it.

There's a paradox sitting underneath all of this. The professionals who get the most value out of AI today are usually the ones who built their judgement before AI existed. They know what a weak assumption looks like because they've built enough models by hand to have made that mistake themselves. The next generation is being asked to supervise AI output before they've had the chance to make those mistakes at all.

What I'm not arguing

I'm not suggesting we bring back pointless drudgery for its own sake. Nobody needs to manually reformat a slide deck to develop strategic thinking, and no developer needs to hand type every repetitive line of boilerplate to understand a codebase. Automate that without a second thought.

The harder job, and the one most organisations are skipping, is telling the difference between the parts of a task that are just friction and the parts that are actually where the learning happens. Building a financial model badly for the first time is inefficient. It's also often where someone learns how the business actually works. Automate the data wrangling. Don't automate the moment where the analyst has to decide which assumptions matter.

What to actually do about it

A few practical shifts I'd put in front of any leadership team wrestling with this:

Distinguish between routine work and developmental work and treat them differently. A recurring monthly report is fair game for full automation. A new strategic analysis is a different category, because the point isn't just the output, it's building the muscle to produce one.

Ask for an independent first pass before the AI gets involved on the assignments that matter. Not the whole task by hand, just enough that the employee has formed their own view of the problem before they see the machine's answer. Comparing their own thinking against the AI's output teaches more than accepting the output ever will.

Change what your managers are reviewing. Less time on formatting, more time asking which assumptions mattered, where the employee pushed back on the AI, and which part of the work they'd struggle to redo without it. That last question tells you almost everything about whether real capability is building underneath the output.

And measure something other than throughput. Time saved and tasks completed tell you about productivity. They tell you nothing about whether your junior people are getting better at the things that actually matter, which are explaining assumptions, spotting flawed conclusions and working through problems that don't look like anything the AI has seen before.

The question worth asking in your next AI review

Every AI initiative removes some human effort. That's the whole point of it. The harder question, the one I opened with, is what that effort used to build in the person doing it, and what's now going to build it instead.

If you've got a confident answer to the first question and nothing for the second, you're not just saving time. You're financing it with debt your business will eventually have to repay, at a moment you don't get to choose.

---

Frequently asked questions

What is capability debt in the context of AI adoption?

Capability debt occurs when an organisation automates tasks without considering what those tasks quietly taught the workforce. Much like technical debt, using AI for speed today erodes the number of people who truly understand how problems are solved. Eventually, employees lose the ability to spot mistakes or handle novel edge cases when the AI model fails.

Why are experienced professionals currently getting more value from AI than junior staff?

Experienced professionals built their judgement before AI tools existed. They previously performed slow, manual work and made their own mistakes, which taught them to recognise weak assumptions. In contrast, junior staff are now asked to supervise AI outputs before they have had the chance to build that foundational understanding themselves through practical experience.

How does automating junior roles impact an organisation in the long run?

Junior roles traditionally function as an informal apprenticeship. Automating these early tasks gives immediate good results, but it removes the slowness where learning actually happens. Over time, organisations risk creating employees who are excellent at supervising AI tools but increasingly incapable of working independently or catching incomplete and wrong answers.

What is the difference between routine work and developmental work?

Routine work involves repetitive friction, such as generating recurring monthly reports or reformatting slide decks, which can be automated without loss. Developmental work, like creating a new strategic analysis, is where crucial learning happens. The value of developmental work lies in building the mental muscle to understand assumptions, not just producing the final output.

How can leaders ensure employees build skills while using AI tools?

Leaders should ask employees for an independent first pass on critical assignments before involving AI. Managers should also shift review focus from formatting to testing assumptions and identifying work staff could not redo manually. Finally, organisations must measure whether junior staff are getting better at problem solving, rather than relying solely on throughput metrics.