The Fluency Trap: How AI Fakes Learning
By Vikas Malpani. I run two companies where AI writes most of the first draft of everything, code included. For a while I told myself I was learning faster than I ever had. Then a model was down for an afternoon, I had to work through a problem it usually handled, and I discovered I could not actually do the thing I thought I had learned. This is what I found out about why that happens, and how to stop it.
The early data on AI and learning is in, and it is not good. Scientific American ran the headline. A randomized trial from Anthropic put a hard number on it: engineers learning a new library with an AI assistant scored 50 percent on a comprehension quiz afterward, while the group that wrote the code by hand scored 67 percent. That is close to two letter grades, and the widest gap was on debugging, the exact skill you reach for when something breaks. A June survey found 77 percent of physicians and 70 percent of nurses worried they are losing their own skills to the tools. Radiologists at one clinic got 6 percent worse at spotting tumors on their own three months after an AI tool arrived.
You could read all of that as one more “AI is making us dumber” story and move on. That is the wrong lesson, and the right one is more useful. The problem is not that AI erodes skills you already have. It is that AI can quietly stop you from building the skills you think you are learning right now, and it does it while making you feel like the best student you have ever been.
That gap between feeling and reality has a name and a mechanism. I call it the fluency trap.
Table of Contents
- You have never felt like a faster learner
- The framework: the fluency trap
- What the machine actually took: the struggle was the lesson
- The fluency illusion: why “I get it” is the least reliable signal
- The tutor line and the doer line
- The debugging hole: your recovery skill goes first
- Why you cannot feel it happening
- The compounding cost for founders
- Five difficulties AI removes, and how to put them back
- The fluency map: where your learning actually lands
- The contrarian take: the tool is not the enemy
- What to do Monday morning
- FAQ
You have never felt like a faster learner
Here is the strange part. Ask people whether AI is helping them learn, and most say yes, emphatically. They are shipping things they could not have shipped a year ago. They are wading into unfamiliar libraries, unfamiliar domains, unfamiliar tools, and coming out the other side with working results in an afternoon. It feels like a superpower, and in one narrow sense it is.
The trouble is that “I produced something good” and “I learned something” are two different outcomes, and AI has quietly decoupled them. You can now produce excellent work in a field you do not understand. That was almost impossible before. Before AI, output was evidence of understanding, because the only way to produce the output was to build the understanding first. Now the output can be borrowed, and the understanding can stay exactly where it was.
The Anthropic study is the cleanest picture of this I have seen. Fifty-two engineers, all with real Python experience, all learning Trio, an async library none of them knew. Half used an AI assistant freely. Half worked by hand. During the task, the AI group produced better code. They looked like faster learners. Then everyone took a quiz with the AI turned off, and the hand group beat them by seventeen points. The people who looked like they were learning faster had learned less.
That is not a rounding error. Seventeen points is the distance between a solid grade and a failing one. And the point is not that the AI group was lazy or careless. They were doing exactly what the tool invites you to do. They asked, they got a good answer, they moved on. The asking and getting felt like learning. It was not.
This is a distinct problem from the one I wrote about in cognitive debt, where the concern is skills you already own slowly rusting from disuse. This is upstream of that. This is about the skill never forming in the first place, on the exact day you sat down to learn it, feeling the whole time like it was working.
The framework: the fluency trap
Every learning session produces two things, not one. It produces output, the thing you made. And it produces absorption, the understanding that stays in your head after the work is done and the tab is closed. Before AI, these two moved together, because the only path to output ran straight through absorption. AI cut a new path. Now you can get the output without the absorption, and here is the cruel mechanical part: the feeling of learning tracks the output, not the absorption.
So the better your AI-assisted output, the more you feel like you learned, and the less you may have actually absorbed. The signal you trust is wired to the wrong meter.
| The two yields | Output | Absorption |
|---|---|---|
| What it is | The thing you made this session. | The understanding that stays after the tab is closed. |
| How it feels | Instant and obvious. The work is on the screen. | Nothing. There is no live signal that it happened. |
| What the feeling tracks | This one. Confidence rides the output. | Not this one. It stays invisible until tested. |
| When you find out it is empty | You never do. The output was real. | The day you have to do it without the tool. |
| Who keeps it | The project. | You, if you earned it. The model, if you rented it. |
The fluency trap is the gap between those two lines. Look at how a learning loop is supposed to work, and where AI cuts across it.
The law is simple to state and hard to feel in the moment. AI hands you the answer and skips the struggle, but the struggle was the lesson. You keep the output and lose the understanding, and you will not notice until something breaks, because the part of you that decides whether you learned is reading the output, not the understanding.
Name it and you can hunt it. The rest of this piece is about the mechanism underneath the trap, why the feeling is so convincing, the one variable that decides whether AI teaches you or robs you, and what to actually do about it on a Tuesday when you have real work to ship.
What the machine actually took: the struggle was the lesson
Learning scientists have a phrase that sounds like a contradiction and turns out to be one of the most reliable findings in the field: desirable difficulties. Robert and Elizabeth Bjork named it in 1994. The paradox is that the conditions which slow down learning while you are doing it are often the exact conditions that make the learning last. Effort during acquisition is not a tax on learning. In many cases it is the thing that produces the learning.
The most direct example is the generation effect. In 1978, Slamecka and Graf ran a study where one group read pairs of related words and another group generated the second word themselves from a hint. The generators worked harder and were slower. On the later test, the generators crushed the readers, even though the readers had literally been shown the answer. Producing the answer yourself, even badly, even slowly, cut a deeper track than being handed it.
The testing effect says the same thing from another angle. A large body of work from Roediger and Karpicke shows that trying to retrieve something from memory, and even failing, teaches you more than rereading it. A meta-analysis across dozens of studies puts the effect size around 0.74, which in this field is enormous. Pyc and Rawson refined it: hard retrieval helps most, as long as you eventually succeed. The strain is the mechanism.
Now line that up against what an AI assistant does to your day. It removes the generation. You do not produce the attempt, it does. It removes the retrieval. You do not dredge the answer out of your own memory, you ask. It removes the productive failure. You almost never sit in the state of being stuck, because being stuck is a five-second problem now. Every desirable difficulty, the specific set of frictions that decades of research says builds durable skill, is exactly what the tool is designed to delete.
This is why the effect is so quiet. Every individual removal feels like pure gain. Why would you struggle for twenty minutes to generate a bad first attempt when the model gives you a good one instantly? The answer is that the twenty minutes of bad attempts were not overhead on the way to the code. They were the code being written into you. Cut them and you still get code on the screen. You just do not get the version of it that lives in your head.
The fluency illusion: why “I get it” is the least reliable signal
If AI-assisted learning left you feeling uncertain, this would fix itself. You would sense the gap and go back and shore it up. The reason the trap holds is that it does the opposite. It leaves you feeling more confident, not less, precisely when you have learned less.
Karpicke and Roediger ran the study that should be taught in every school. They had students learn material by different methods, then predict how well they would do on a later test, then take the test. The students who reread the material until it felt smooth and familiar predicted the highest scores. They then delivered the lowest. The students who had quizzed themselves, who had sat in the discomfort of not-quite-remembering, predicted lower and scored higher. The re-readers were confidently wrong about their own minds.
The researchers gave the culprit a name: fluency. When something feels smooth and familiar, your brain reads that smoothness as a signal of mastery. But fluency is measuring the wrong thing. It measures how easily you can recognize the material, not how well you can reproduce it without help. Recognition and recall are different circuits, and only one of them shows up when the AI is closed and the problem is real.
AI is a fluency machine. Its whole job is to make hard things feel smooth. A perfectly worded explanation slides into your head with zero friction, and that frictionlessness is exactly the sensation your brain has learned to trust as “I understand this now.” You do not. You understand that the explanation was clear. Those are not the same, and the gap between them is invisible from the inside.
This is the deep reason the fluency trap is dangerous rather than merely inconvenient. A trap that felt like a trap would spring rarely. This one feels like competence. It feels like the best learning day of your life. That good feeling is the bait.
The tutor line and the doer line
Here is where the story turns from grim to useful, because the same Anthropic study that measured the damage also measured the escape. The AI group’s average hid an enormous spread, and the spread was not random. It tracked one variable: how people used the tool.
Developers who used AI to ask conceptual questions, to understand why something worked, to check their own reasoning, scored 65 percent or higher. Developers who delegated the actual code generation, who asked the model to just produce the thing, scored below 40 percent. Same tool, same task, same afternoon. The grip on the tool decided everything.
This is the single most important finding for anyone trying to learn with AI, and it maps straight onto everything above. Using AI as a tutor keeps the desirable difficulties intact. You still generate the attempt, you still retrieve, you still sit in the productive confusion, and you use the model to check and to explain rather than to replace the work. Using AI as a doer deletes all of it. The model generates, the model retrieves, the model resolves the confusion, and you supervise.
The tutor line and the doer line are two completely different activities that happen to use the same chat box. One of them makes you sharper. The other makes you faster today and hollower tomorrow. And the tool, by default, nudges you toward the doer line, because the doer line is what ships work in the next ten minutes and feels amazing while it does. Staying on the tutor line is a choice you have to make against the grain of the product.
The debugging hole: your recovery skill goes first
Of everything in the Anthropic data, one detail should worry you more than the headline number. The comprehension gap was not evenly spread across the quiz. It was widest on the debugging questions. The AI group was worst, relative to the hand group, at exactly the skill that matters when things go wrong.
There is a mechanism for this, and it is brutal in its logic. Debugging is a skill you can only build by living inside a specific painful loop: you hit an error you did not expect, you form a theory about why, you test the theory, you are wrong, you form another. That loop, repeated a few hundred times, is what turns into the instinct experienced engineers have where they read an error and already half-know where the bug is. When you paste the error into an AI and it hands you the fix, you complete the task and skip the entire loop. You never build the instinct, because the instinct is made of the loop you just outsourced.
Now stack that on top of everything else. Debugging is not just any skill. It is your recovery skill. It is the thing you use when the happy path fails, when the AI’s answer is wrong, when the system is doing something nobody designed. It is the human version of what I wrote about in the agent reliability paradox, where the whole argument is that agents fail in production and something has to catch the fall. In a company running on AI, you are the fallback. And the fluency trap goes after your fallback skill first and hardest.
That is the asymmetry that should keep founders up at night. The skill AI erodes fastest is the exact skill you need on the day AI fails you. This is a cousin of the argument in fallback competence, where I made the case for deliberately maintaining a reserve you can still run when the tools go down. That piece was about protecting skills you already have. This one is about a worse case: the junior engineer, the new founder, the person who never built the debugging instinct at all, because AI was there from day one. You cannot maintain a reserve you never deposited.
Why you cannot feel it happening
People smart enough to worry about this often assume they are immune. They are not, and the reason is structural, not a matter of willpower or intelligence. The fluency trap is invisible from the inside because the two feedback signals arrive on wildly different schedules.
Output feedback is instant. You ask, you get a good answer, the code runs, the document reads well, the problem is solved. That hit lands in seconds, and it is genuinely real. You did produce something good. Absorption feedback is delayed by weeks or months, and it only ever arrives in one narrow situation: the moment you have to do the thing without the tool. Until that moment comes, there is no signal at all telling you the understanding is missing. Silence is not evidence of learning. It is just the absence of the only test that would reveal the gap.
So your brain does what brains do. It optimizes for the signal it can see. It feels the instant output reward, reads it as learning, and keeps repeating the behavior that produces it. By the time the delayed absorption signal finally arrives, in the form of you sitting frozen in front of a problem you thought you knew how to solve, you have run the pattern hundreds of times. The trap is not sprung by a single lazy afternoon. It is sprung by hundreds of good, productive, satisfying afternoons that each felt like progress.
This is the same shape as the velocity illusion, where AI pays you in the feeling of shipping rather than actual shipped throughput. The fluency trap is its twin for learning. There, the counterfeit currency is the feeling of productivity. Here, it is the feeling of understanding. Both feel like the real thing. Both are only exposed by a test you are not running.
The compounding cost for founders
For a solo founder or a small team, this stops being an abstract cognitive-science problem and becomes a direct risk to the business, because you do not learn one skill with AI. You learn dozens. You pick up just enough of a new framework to ship the feature. Just enough tax structure to file. Just enough marketing copy to launch. Just enough SQL to pull the number. Each one feels learned. Each one may be borrowed fluency, competence you are renting from the model and do not actually own.
A stack of borrowed fluencies is a fragile thing. It works beautifully right up until the moment you need to combine two of them in a way the model has not seen, or judge whether the model’s answer is wrong in a domain where being wrong is expensive. That is when you discover that “I learned this” was actually “the model knew this and I was nearby.” The whole appeal of the AI-native founder is doing the work of a team of ten. The hidden condition on that appeal is that you can tell when any of those ten borrowed competences is about to fail you. Borrowed fluency cannot tell.
I have argued elsewhere, in the founder operating system and its AI-age update, that the founder’s job is shifting from doing the work to judging the work. That shift only works if your judgment is real. Judgment is a skill like any other, and it is subject to the exact same trap. If you learned to judge marketing copy by having AI judge it for you, you did not learn to judge marketing copy. You learned to agree with a model. The day its taste and your interests diverge, you will not see it coming.
This connects to the reps argument I made in the reps problem. Delegation without deliberate practice does not just leave your skills flat. Under the fluency trap, it can leave you believing they grew while they stayed exactly where they were, or worse, while they quietly failed to form. That belief is the expensive part. A founder who knows they cannot do something is careful. A founder who falsely believes they can is dangerous to their own company.
Five difficulties AI removes, and how to put them back
The good news buried in the learning science is that the difficulties which build durable skill are well understood and few in number. There are five, they are named, and every one of them can be deliberately added back into an AI-assisted workflow without giving up the tool. You are not choosing between fast and deep. You are choosing where to spend friction on purpose.
| Desirable difficulty | What it does | What AI removes | How to put it back |
|---|---|---|---|
| Generation | Producing an answer yourself cuts a deeper track than reading one. | The model produces the answer before you attempt it. | Write your own attempt first, then ask the model to critique it. |
| Retrieval | Pulling from memory, even failing, teaches more than rereading. | You look it up instead of recalling it. | Answer from memory before you open the chat. Check after. |
| Productive failure | Being stuck primes the brain to absorb the eventual solution. | Stuck is now a five-second state, so you never sit in it. | Timebox the struggle. Give yourself ten minutes before you ask. |
| Spacing | Revisiting after a gap forces reconstruction, which strengthens it. | You solve it once, ship, and never return to it. | Redo one thing from last week without the model, cold. |
| Explanation | Teaching it back exposes the holes recognition hides. | You accept the fluent answer without reprocessing it. | Explain it out loud to someone, or to nobody, without notes. |
Notice that none of these say stop using AI. Every one of them keeps the tool and changes the grip. That is the whole move. The fluency trap is not a property of the tool. It is a property of how you hold it, and the five columns on the right are the tutor grip written out step by step.
There is a cost, and it is worth naming honestly. All five of these make the current task slower. That is the point, and it is also the reason almost nobody does them, because in the moment they feel like a step backward when the model is right there offering the fast path. You have to decide, before you sit down, that this particular skill is one you intend to own rather than rent. You cannot own all of them. Choosing which is a strategy question, and it overlaps heavily with the argument I made in what to actually learn in the AI era.
The fluency map: where your learning actually lands
Put the two yields on two axes and the whole situation becomes a map you can locate yourself on. On one axis, the quality of the output you produce. On the other, the absorption you walk away with. Every learning session lands in one of four quadrants, and only one of them is a lie.
The map makes the danger legible. Both bottom-left, honest struggle, and top-left, slow mastery, feel like hard work, because they are. The fluency trap in the bottom-right feels like the best of all four, because it hands you high-quality output with none of the strain. That good feeling is the entire problem. Every other quadrant tells you the truth about itself through how it feels. Only the trap lies, and it lies by feeling wonderful.
The target is the top-right, real learning, and it is reachable. It is the tutor grip. It produces good output and keeps the absorption, which is why the tutor group in the study scored right up next to the hand group while shipping better work along the way. You do not have to choose slow mastery to escape the trap. You have to choose the grip that keeps you out of the bottom-right.
The contrarian take: the tool is not the enemy
The obvious conclusion from all of this is the wrong one. Read the studies, feel the alarm, and the instinct is to swing back to doing everything the hard way, to treat AI as a corrupting influence to be minimized. That reaction is not just joyless, it is contradicted by the data that produced the alarm in the first place.
Remember the fork. The tutor group did not avoid AI. They used it heavily, and they came out at 65 percent, right next to the hand group’s 67, while producing better work during the task. Used correctly, AI did not damage their learning at all. It let them learn about as well as the hard-way group while shipping more. That is not a tool to minimize. That is a tool to grip differently. The enemy was never the AI. The enemy is the delegation of the struggle, and delegation is a choice, not a feature.
In fact, a properly gripped AI can create more desirable difficulty than working alone, not less. A model that refuses to give you the answer and instead asks you three questions that force you to reason toward it is running a better generation exercise than you would have run by yourself. A model that quizzes you cold on yesterday’s problem is running spaced retrieval you would never have bothered to schedule. The same technology that makes the trap possible makes the best tutor most people have ever had available for free. Which one you get is decided entirely by the prompt and the discipline behind it. This is the same lesson taste turned out to have in building taste when AI makes everything: the machine is not the threat to the human skill, the passive use of the machine is.
Here is the honest counterweight, because the tutor grip is harder than it sounds. The default pull of every AI product runs the other way. The interface, the speed, the dopamine of instant good output, all of it steers you toward the doer line, because that is what demos well and what feels good in the moment. Choosing the tutor grip means fighting the product’s own incentives every single time you open it, on the exact days you are most tired and most tempted to just get the thing done. Most people will not win that fight most of the time. That is not a reason to give up on it. It is a reason to build the discipline into your process instead of relying on willpower, which is what the Monday section is for.
What to do Monday morning
None of this matters unless it changes what you do the next time you open a chat window with something to learn. Here is the practice, built to survive a real workday rather than an idealized one.
Run the close-the-tab test before you call anything learned. After you finish something with AI that you intended to learn, close the tool and rebuild the core of it once from scratch. If you cannot, you did not learn it. You produced it. That is fine, as long as you know which one happened, and the test is the only thing that tells you.
Set a tutor rule for skills you mean to own. Decide in advance which handful of skills you are learning versus merely using. For the ones you are learning, make the rule explicit: ask the model to explain and to critique, never to produce. Ask why, not what. The rule has to be set before you start, because in the moment the doer line will always look faster.
Attempt before you ask. This is the generation effect turned into a habit. Write your own version first, however bad, then bring it to the model. A critique of your attempt teaches you far more than a replacement for it, and it costs you ten minutes.
Retrieve before you look up. Before opening the chat to get something you have seen before, try to produce it from memory. Failing to recall it and then checking is worth more than smoothly reading it again. The strain is the mechanism.
Protect your debugging reps. When you hit an error, resist the paste-and-fix reflex. Timebox it: give yourself ten minutes to form and test a theory yourself before you hand the error to the model. Debugging is your recovery skill. It is the last one you want to rent.
Teach it back. The cheapest absorption test there is. Explain the thing you just learned to a colleague, or out loud to an empty room, with the tab closed. The holes show up in the first thirty seconds. This is also the fastest way to feel the difference between recognition and recall in your own head, which is the entire skill this piece is trying to build.
Do these and you are not fighting AI. You are using it the way the best learners in the study used it, and getting the shipped work and the retained skill at the same time. Skip them and you will keep having wonderful, productive, satisfying days that teach you almost nothing, and you will not find out until the afternoon the model is down and the problem is real.
FAQ
Does using AI actually make you worse at learning?
Using AI does not, but a specific way of using it does. In the Anthropic trial, people who delegated the work to the model scored below 40 percent on a comprehension quiz, while people who used the model to explain and check their own reasoning scored 65 percent or higher, right next to the 67 percent of people who worked entirely by hand. The damage comes from delegating the struggle, not from touching the tool. Same tool, opposite outcomes, decided by how it is used.
What is the difference between the fluency trap and cognitive debt?
Cognitive debt is about skills you already have quietly rusting from disuse, the use-it-or-lose-it problem. The fluency trap is upstream of that: it is about a skill failing to form in the first place, on the day you sat down to learn it, while you felt like it was working. One is erosion of an existing skill. The other is a skill that never gets built even though you believe it did. They compound on each other, which is why the combination is dangerous.
Why does learning feel so good with AI if I am learning less?
Because the feeling of learning is wired to fluency, the sense that material is smooth and familiar, and AI is a fluency machine. Learning research has shown for decades that fluency measures how easily you recognize something, not how well you can reproduce it without help. A clear AI explanation slides in with zero friction, and your brain reads that frictionlessness as mastery. It is actually just the smoothness of recognition, which is a different circuit from the recall you need when the tool is gone.
If AI-assisted learning is worse, should I just learn everything the hard way?
No, and the data argues against it. The group that used AI as a tutor learned about as well as the hard-way group while producing better work during the task. The goal is not to avoid AI, it is to grip it as a tutor rather than a doer: ask it to explain and critique, attempt things yourself first, retrieve from memory before looking up. Done that way, AI can create more useful difficulty than working alone, not less.
Why is debugging the skill that suffers most?
Debugging is built entirely from a painful loop of hitting an unexpected error, forming a theory, testing it, and being wrong until you are right. That loop, run hundreds of times, becomes an experienced engineer’s instinct. When you paste an error into AI and get the fix, you complete the task and skip the whole loop, so the instinct never forms. It matters more than other skills because debugging is your recovery skill, the one you need precisely when the AI’s answer is wrong.
Does the fluency trap apply outside of coding?
Yes. The mechanism is about learning in general, not code specifically. Founders hit it when they pick up just enough of a new domain to ship, tax or marketing or SQL or hiring, and mistake the shipped result for owned understanding. Any skill you learn by having AI do it for you is subject to the same trap. Coding is just where it was measured most cleanly, because comprehension there is easy to quiz.
How do I tell if I actually learned something or just produced it?
Run the close-the-tab test. Close the tool and rebuild the core of the thing from scratch. If you can, you learned it. If you cannot, you produced it with help, which is fine as long as you know which one happened. A faster version is the teach-back: explain the thing out loud with no notes and no tab open. The holes surface in the first thirty seconds, and the exercise itself is a form of the retrieval that builds the skill.
Are experienced experts safe from the fluency trap?
Less exposed, not safe. Experts already have a floor of hard-won skill that lets them catch a wrong AI answer and recover, so borrowed fluency sits on top of real competence. The acute danger is for people building a skill for the first time with AI present from day one, who never deposit the underlying competence at all. You cannot draw on a reserve you never built, which is why the trap is most costly for juniors, career-switchers, and founders entering unfamiliar domains.