Skip to content
AI & Governance · July 14, 2026 · 12 min read

Never-skilling:
the risk nobody measures in your company

AI fixed my bug without me understanding why. Research on doctors and developers shows this pattern has a name: never-skilling. And it is already playing out in every company that uses AI.

🤖 Agent-friendly (.md)
Illustration for article: Never-skilling: the risk nobody measures in your company

TL;DR

  • Never-skilling is newer than deskilling. You don't unlearn a skill, you never build it in the first place — because AI already takes over the task before you get the chance to learn it.
  • The research is solid. Anthropic had 52 developers code with and without AI: the AI group scored two letter grades lower, especially on debugging questions, for a two-minute time saving.
  • Even Anthropic is on the curve. More than 80% of their own production code is now written by Claude — the same pattern, at the company with the best engineers in the world.
  • No KPI measures this. While turnaround time and customer satisfaction go up, the expertise you need the moment a file isn't standard quietly disappears.

In May 2026 I got stuck on a single bug in Cursor for three hours. The error pointed at something that, as far as I could tell, could not possibly be broken, and I couldn't get past it. So I did what I always do. I threw the problem back at the model. That didn't work. I switched to a heavier model. That didn't work either. Eventually I switched providers, and there it was found and fixed.

That code runs fine now. And if you ask me today what exactly was wrong, I owe you an answer I don't have. I don't know. I never knew.

That left me with an uneasy feeling, and I kept thinking about it afterwards. Not because it went wrong, because it actually went right. But because for the first time I felt sharply that I had solved a problem without understanding it. I'm one of the people who now build without a developer background on a daily basis, and it works surprisingly often. Only this time it felt different. And the question I asked myself is the question I want to answer in this piece.

How bad is that, really?

We often don't understand what we use, and that's fine

Let's start with the sober side, because there is one.

Start with your own phone. I used to know maybe twenty phone numbers by heart. Home, my parents, a handful of friends. Today I know zero. I type a name and press call. Is that bad? I don't think so. It costs me nothing, and the space in my head is spent on something else.

It's the same everywhere. You probably drive a car without being able to overhaul the engine. You fly to Barcelona in a plane that's flown by a computer for most of the flight, and the pilot up front genuinely cannot sketch out the control algorithms of that system for you. Your GP reads a blood test result from a device he can't calibrate. And the programmers of the past had to manually manage their computer's memory, something no developer today gives a second thought to because the software handles it itself.

This is not new and it's not an accident. It is exactly the mechanism through which we make progress. Every layer you stack on top makes the layer beneath it invisible, and that is precisely what lets more people do more. An entire generation of skills evaporated among programmers, and nobody mourns it anymore.

So if you ask me whether it's bad that I don't know exactly what my code does, the first honest answer is: not in itself. I'm using an abstraction layer, like everyone else. Anyone who panics about that hasn't looked closely at how technology has always worked.

Except that answer is only half right. And the other half is where it gets interesting.

Why never-skilling is different from not knowing how your engine works

Look at that phone number again. I no longer know it by heart, yet I can always retrieve it. It's on my phone, it's in the backup, and if everything else fails I can still look it up. The knowledge isn't gone, it's stored somewhere I can find it again. That's why it doesn't matter.

An abstraction layer is only safe once three conditions are met, and I only realised this once I held my own situation up against them.

The first condition is that the layer behaves predictably. Your contacts list returns the same number every single time. A language model does not. That's exactly why I could switch models, and why it suddenly worked on the third attempt. I wasn't using a reliable tool, I was querying a probability distribution until something usable came out.

The second condition is that somewhere in the chain there is still someone who actually understands it. You don't need to be able to overhaul your engine, because the mechanic can. The pilot doesn't need to be able to program the autopilot, because there's a team of engineers behind it who understand the system, and an investigation board behind that which takes it apart when something goes wrong. The knowledge hasn't disappeared, it has moved.

The third condition is that the failure mode is bounded. If the autopilot fails, the pilot takes over, and he can do that because he's required to keep flying by hand in the simulator. Aviation is almost obsessive about this, and that's no accident.

My bug met none of those three. The layer didn't behave predictably, since I had to switch three times before anything came out. There was nobody underneath the layer who understood it, because that should have been me. And the failure mode wasn't bounded, because if none of the models had found it, I would simply have been stuck.

The phone number I forgot is stored somewhere. The fix for my bug is stored nowhere. Nobody knows it, not even me, and there's no backup I can retrieve it from.

That's no longer an abstraction. That's hope.

And that is the difference between not knowing how your engine works, and no longer being able to learn how it works. There's now a word for the second one, and I heard it for the first time in a theatre.

The curve I saw on screen in Leusden

On July 7th I was at the VIP re:Invent Congres. Erik Scherder was on stage, and a graph appeared on the screen behind him that I haven't been able to shake since.

Scherder is a professor of neuropsychology, and his message was about something I hadn't factored in until that moment. I had assumed this was a story about skills. About knowledge you fail to pick up. He told a story about biology instead.

His point is that your brain needs mental effort to stay in shape. Stop doing that structurally, and the quality of your white matter declines. That's the tissue that maintains the connections in your brain, and it isn't an abstract concept but measurable material. That decline costs you resilience, it costs you the ability to think critically, and it dulls your mental filters.

And then came the part that hit me hardest. According to Scherder, humans, driven by an evolutionary urge to conserve energy, almost always choose the path of least resistance. Thinking costs energy, so if there's an easier route, we take it. Not out of laziness, but because that's how we're built. And AI is the smoothest path of least resistance ever built.

I sat on that bug for three hours. Not once did I consider unravelling it myself. I handed it to a machine three times. That felt like efficiency. According to Scherder, it was my brain choosing the easiest route.

Erik Scherder on what outsourcing your thinking does to your brain.

The graph he showed comes from a piece by Tyler Berzin and Eric Topol, published in The Lancet on October 18, 2025. Berzin is an endoscopist in Boston, Topol is one of the best-known voices on technology in medicine. Their question was simple: how do doctors keep their skills sharp in an age where the algorithm is watching along?

They distinguish three ways this goes wrong when you outsource your thinking.

The first is deskilling. You could do it, and you unlearn it because the machine takes over.

The second is mis-skilling. You adopt the system's errors and biases and start believing them yourself.

The third is the most uncomfortable one, and it's never-skilling. You never reach the level, because the machine was already there before you could learn it.

Potential effects of AI on skill level over time. After Berzin and Topol, The Lancet 2025.
The curve I saw on screen. On the left, the build-up of proficiency for those trained before AI. On the right, three possible paths afterwards: AI makes you better, you slowly unlearn it, or you never reach the dotted line at all. After Berzin and Topol, The Lancet, October 18, 2025.

On the graph you see those three as curves side by side. Doctors trained before AI climb to their level and then slowly slide back down. Doctors trained after AI never even get close to that dotted line. They never reach the level, because they never had to reach it.

I sat there in that theatre and thought: that's me. I never learned to debug by hand. I skipped it. I'm the green line.

Follow me on LinkedIn

Follow my updates on AI, strategy and entrepreneurship on LinkedIn

From endoscopists to developers: the same pattern, two sectors

Now, a graph in a presentation isn't proof, and I'm the last person to take a nice picture as truth. So I went looking. And there is now solid material on both sides.

For the deskilling side there's an observational study by Budzyń and colleagues, published in Lancet Gastroenterology and Hepatology (opens in new window)00133-5/abstract) in 2025. They followed experienced endoscopists at multiple hospitals who worked with AI support during colonoscopies for a period, and then without it. When that support was switched off, their ability to find polyps measurably declined. So not beginners, not theory, but experienced specialists losing something they could previously do. Simply because they hadn't had to do it themselves for a while.

And for the never-skilling side, there's been research from Anthropic itself (opens in new window) since late January 2026, conducted by Judy Hanwen Shen and Alex Tamkin. They set 52 mostly junior software engineers to work with a Python library they didn't yet know. Half were allowed to use an AI assistant, the other half weren't. Afterwards, everyone took a quiz on the concepts they had just applied.

The group with AI scored fifty percent. The group that did it by hand scored sixty-seven. That's a gap of nearly two full letter grades, and it's statistically significant.

But the detail that really matters comes further into the study. The biggest gap between the two groups was on the debugging questions. Precisely where you need to be able to see that something is wrong, and why. Precisely the skill you need to check AI-generated code. And precisely the skill I never built myself.

The time saved, incidentally, was about two minutes. Not significant.

Two minutes faster. Two letter grades dumber.

Why this affects your company, not just doctors and programmers

Now you could read this as a story about doctors and programmers and conclude it doesn't concern you. That would be a mistake, and I think it's about to become an expensive one.

Because the curve isn't medical or technical. The curve is about what happens when someone never has to do a task fully by themselves again. And that is happening across your entire company right now.

Your underwriter, who has a model draft the risk assessment. Your claims handler, who gets served the first analysis of the file. Your marketer, who no longer writes a brief but a prompt. Your newest employee, who has never built a quote entirely from scratch, because there was always already a draft.

All of these people get faster because of it. And most of them get away with it just fine, because most files are standard and most assessments are routine.

Until the file comes in that is not standard.

That's the moment you find out whether anyone in your organisation is still underneath the layer. And here's the point that keeps nagging at me: there is no KPI that measures this. You measure turnaround time, you measure customer satisfaction, you measure cost per file. All of those numbers move in the right direction when you deploy AI. There's no dashboard that says: can we still do this without it.

In most organisations I see up close, that conversation hasn't been had even once. Not in the management team, not in the supervisory board, not in the risk report. This risk sits on nobody's boardroom agenda, and that's striking, because it is exactly the kind of creeping operational risk a regulator will be asking hard questions about within a few years. The EU AI Act already requires AI literacy across your workforce. The next question, logically, is whether your workforce still has enough domain expertise left.

The paradox Anthropic is publishing about itself

Now it gets genuinely uncomfortable, and this is the part I think almost nobody has noticed.

Because the same organisation that published in January that junior developers learn worse with AI, followed it up with a second piece. This time about itself. It's called When AI builds itself (opens in new window), it comes from the Anthropic Institute, and it's about how hard AI is accelerating the development of AI.

The numbers in it are striking. Since May 2026, more than eighty percent of the code Anthropic ships to production is written by Claude. Before the launch of Claude Code in February 2025, that figure was a few percent. The average engineer now merges roughly eight times as much code per day as in 2024, not because he types faster, but because he barely types anything himself anymore. He directs and he reviews.

One employee is quoted in the piece saying he hasn't written a line of code himself in roughly five months.

So this isn't a background-free vibecoder like me. These are the best engineers in the world, at the company that builds the model itself. And they're on exactly the same curve.

Anthropic also describes where that's heading, and they're honest about it. Once AI-written code is just as good as human-written code, people stop writing and start only reviewing. That's their own choice of words. And right behind it comes the observation that human review then becomes the bottleneck, because a human cannot check as fast as a model can produce.

Read that again slowly, because that's where the knot sits.

The future role of the human is to review. Reviewing means being able to see that something is wrong, and why. That is exactly the skill Anthropic's own research identifies as the skill that declines hardest in people learning to work with AI. The biggest gap in that quiz was on the debugging questions.

So collectively, we're building a future in which the only thing left for humans to do is precisely the one thing humans are unlearning.

There's another quote from an employee in that piece that I can't get out of my head. He says that on days when everything works, he feels like nothing he does matters anymore. And that there are also days when everything breaks, that he doesn't understand why, and that he then realises he no longer has any idea what he was actually working on.

That's my bug. Just said by someone who actually knows what he's talking about.

To be fair: Anthropic doesn't hide this. They write it down plainly, caveats included. That's to their credit. But it doesn't change the conclusion. The company that measured the curve is the one accelerating fastest along it.

What does work, and it's the most striking finding in the research

Now the good news, because it's in that same Anthropic study and I think it's the most important part.

Not everyone in the AI group scored badly. Some scored high. And the difference wasn't in how much they used AI, but in how they used it.

The low scorers just let the assistant do the work. They asked for code, pasted it in, and moved on. The fastest group in the entire study was simultaneously the dumbest group in the entire study. Another group used AI only to debug without ever asking why something was broken, and they also scored badly.

The high scorers did something different. They asked follow-up questions. They asked for explanations of the code they received. They asked conceptual questions about how the library actually worked. And the group that asked only conceptual questions wasn't just the best-scoring group, they were also faster than almost every other group.

Same tool. Same time. Opposite outcome.

And if you put this next to Scherder's story, everything clicks into place. Asking for code is the path of least resistance. Asking why that code works is mental effort. It's the same tool, you just choose the smooth route in one case and the route where your brain still has something to do in the other. And the research shows that the second route doesn't even cost you time.

That changes the question you, as an executive, should be asking. The question isn't whether you allow AI, because that ship has sailed. The question is whether you have any idea in which mode your people are using it. And whether you've ever shown them there's a difference between "write this for me" and "explain why this works".

That costs you five minutes in a team meeting. It's the cheapest intervention I know.

Back to my bug

My code still runs. I still don't know what was wrong.

And after everything I've read, I feel less relaxed about that than when I started. Not because it went wrong that time, but because I can see what happens when that situation repeats itself a hundred times. To me, and to everyone currently entering a profession where the machine was already there.

I'm not going to stop vibecoding, that would be a ridiculous conclusion. What I am going to do is, on the next bug, ask what's going on before I ask whether it can be fixed. Two minutes slower. Two letter grades smarter. And according to Scherder, a brain that gets something to do as well.

That's the whole lesson. The path of least resistance is right there, it's free, and it's tempting. You just don't have to take it every time.

Sources