The Cost of Convenience: When AI Help Becomes Cognitive Debt

Help is not always helpful.

Anyone who has managed a junior analyst, tutored a student, reviewed code, or trained a new employee knows the difference between solving a problem for someone and helping them become the kind of person who can solve the next one. The first option is faster. It feels generous. It clears the queue. It also quietly teaches the recipient a useful but dangerous lesson: difficult work should disappear as soon as help is available.

That is the uncomfortable center of AI Assistance Reduces Persistence and Hurts Independent Performance, a new paper by Grace Liu, Brian Christian, Tsvetomira Dumbalska, Michiel Bakker, and Rachit Dubey.¹ The paper does not merely ask whether AI improves performance while people are using it. That would be a short article, and not a very surprising one. Of course an assistant that has the problem and the answer can make a task easier. A calculator is also very good at arithmetic. Congratulations to the machine.

The real question is what happens after the help disappears.

Across three randomized experiments with 1,222 participants, the authors find a consistent pattern: AI assistance improves short-term performance during the assisted phase, but participants later perform worse without AI and are more likely to give up. The effect appears in fraction-solving tasks and then again in reading comprehension. In the second fraction experiment, the cost is especially concentrated among people who used AI for direct answers rather than hints or clarification.

For businesses and education platforms, the paper’s value is not the familiar warning that “AI may cause deskilling.” The sharper point is operational: an AI system can look successful under the usual dashboard metrics while accumulating cognitive debt inside the user.

The invoice arrives only when the user has to think alone.

The mechanism: immediate answers change the cost of effort

The tempting misconception is simple: if AI helps users complete more tasks correctly, then it must be improving learning or capability. That assumption is convenient because it makes evaluation easy. Count completed tasks. Count correct answers. Measure time saved. Declare productivity. Open champagne, preferably with a dashboard.

The paper shows why that metric can be misleading. During assisted work, AI can raise output by substituting for the user’s effort. That output can look like learning from the outside because the answer is correct. But capability formation depends on something less pleasant: the user must struggle enough to build procedures, judgment, and confidence in their own ability to recover from confusion.

The mechanism is not mystical. It is a reference-point shift.

When AI gives a complete answer in seconds, the user experiences the task as something that should be quickly resolved. Once the assistant is removed, the same task now feels slower, heavier, and less worth attempting. The effort has not necessarily increased in objective terms. The reference point has changed. A problem that previously felt like normal work now feels like friction.

That is why persistence matters. The paper measures not only whether people answered correctly, but also whether they skipped the problem. Skipping is important because participants were told that payment did not depend on the number of correct answers and that wrong answers carried no penalty. In that context, skipping is not just failure. It is disengagement.

A useful way to read the paper is to separate three layers:

This is the difference between a scaffold and a substitute. A scaffold leaves the learner more capable after it is removed. A substitute leaves a clean task record and a weaker human process behind it. The paper’s most business-relevant insight is that many current AI assistants behave more like substitutes because they are optimized to be immediately helpful, not developmentally useful.

What the experiments actually test

The study uses a clean experimental logic. Participants are randomly assigned either to an AI-assisted condition or to a control condition. The AI-assisted group receives access to a chat assistant during a learning phase. The assistant is then removed for a final unassisted test. The control group completes the same final test without having received AI assistance.

That final test is the key. The authors are not asking whether participants can produce correct answers while leaning on AI. They are asking whether brief AI-supported work leaves them better or worse when they must continue independently.

The paper contains three experiments, and each has a distinct evidentiary role:

This structure matters because it prevents a lazy reading of the paper. Experiment 1 is provocative. Experiment 2 asks whether the provocative result survives obvious objections. Experiment 3 asks whether the effect is only a math artifact. The usage-pattern analysis then points toward mechanism, but it should be treated carefully because people chose how to use the AI.

That careful distinction is not academic hair-splitting. It is the difference between “AI caused all users to become less persistent” and “brief AI assistance caused measurable downstream performance costs, and the most direct-answer-oriented use pattern appears especially risky.” The second sentence is less dramatic. It is also the one worth building policy around.

Experiment 1: the first warning sign is the post-AI drop

In Experiment 1, 354 U.S.-based Prolific participants were assigned either to an AI condition or a control condition. The task was fraction-solving. Participants in the AI condition had access to an AI assistant during 12 main problems; the assistant was pre-prompted with each problem and solution, so a participant could obtain accurate help with minimal effort. Then the AI was removed without warning for three final problems. The control group solved all problems without AI.

After exclusions, the final sample included 307 participants: 185 in the AI condition and 122 in the control condition.

The result is the paper’s basic pattern in miniature. During the AI-assisted phase, the AI group performed better and skipped less. Once AI disappeared, the advantage reversed. On the final unassisted test, the AI group had a lower solve rate than the control group: 0.57 versus 0.73. The difference was statistically significant, with Cohen’s $d=-0.42$. The AI group also skipped more: 0.20 versus 0.11, with Cohen’s $d=0.25$.

The interpretation is not that participants forgot fractions after ten minutes of chatting with a model. That would be too simple, and also a little theatrical. The more plausible interpretation is that the assisted phase changed how participants engaged with difficulty. The AI group learned, at least briefly, that the problem environment contained a shortcut. When the shortcut vanished, the remaining work felt less worth doing.

The authors identify an important limitation in this first experiment. Their exclusion rule removed participants who failed to solve at least three of the twelve learning-stage problems. But in the AI condition, lower-skill participants could have used the assistant to submit correct answers and avoid exclusion. That could selectively retain weaker participants in the AI group, inflating the apparent post-AI disadvantage.

This is exactly the kind of limitation that should change how we read a result. Experiment 1 is strong enough to motivate concern. It is not strong enough, by itself, to close the case.

Experiment 2: the replication removes the easiest objection

Experiment 2 is designed to address the main confounds from Experiment 1. It adds a pretest before AI is introduced, then uses pretest performance for exclusions. That means the study can filter for basic fraction ability before the AI has a chance to help anyone appear more capable than they are.

The authors also address a subtler interface issue. In Experiment 1, the AI condition had a sidebar that disappeared before the final test. Perhaps the disruption, rather than AI dependence, hurt performance. To control for this, Experiment 2 gives control participants a sidebar too: a reference panel containing worked pretest solutions they had already seen. This panel is also removed before the final test. In other words, both groups experience a tool-like panel disappearing; only one group had access to a generative assistant.

The sample is larger: 667 recruited participants, with 585 remaining after exclusions. The AI and control groups had similar exclusion rates, which supports the claim that the baseline-skill confound was reduced.

The main performance result replicates. On the final unassisted problems, the AI group again solved fewer problems than the control group: 0.71 versus 0.77, with Cohen’s $d=-0.19$. The effect is smaller than in Experiment 1 but still statistically significant.

The skip-rate result is more nuanced. The AI group skipped more than the control group, 0.10 versus 0.07, but this aggregate difference was not statistically significant. This is where a weak summary would either ignore the result or force it into the desired story. The better reading is that Experiment 2 strongly supports the independent-performance cost, while the persistence cost becomes clearer only when usage type is examined.

That brings us to the most useful part of the paper for AI product design.

Direct answers are the dangerous convenience layer

At the end of Experiment 2, participants in the AI condition reported how they used the assistant. Most reported using it primarily for direct answers: 61%, or 189 participants. Another 27%, or 82 participants, reported using it for hints or clarification. A smaller group, 12%, or 37 participants, reported not using AI.

The groups did not significantly differ at pretest in solve rate or skip rate. That matters because it weakens the obvious alternative explanation that direct-answer users were simply weaker or less motivated from the beginning.

At test time, however, the groups diverged. Participants who used AI for direct answers had the lowest downstream solve rate and the highest skip rate. Their test solve rate was 0.65, compared with 0.77 for control participants, 0.76 for hint-or-clarification users, and 0.89 for AI-condition participants who reported not using AI. Their skip rate was also higher: 0.13, compared with 0.07 for the control group and 0.05 for hint-or-clarification users.

The within-person change from pretest to test tells the same story. Direct-answer users’ solve rate fell by 0.10 from pretest to test. Control participants increased slightly by 0.01, hint users increased by 0.05, and non-users increased by 0.11. Direct-answer users also showed a larger increase in skipping than hint users.

This is the most actionable result in the paper, but also the one that needs the most discipline. The authors correctly state that this usage-pattern analysis is cross-sectional within the AI group and is not necessarily causal. Participants chose how to use AI. Direct-answer use may reflect unmeasured traits, even if pretest performance and skip rates looked similar.

Still, the pattern is not subtle. Hints and clarification look much less damaging than answer extraction. The practical implication is not “ban AI.” The implication is: stop treating all AI assistance as one category.

A direct-answer bot, a hinting tutor, a Socratic coach, a code reviewer, and a workflow copilot all sit under the same marketing umbrella. Cognitively, they are not the same product. One may preserve the user’s problem-solving loop. Another may quietly remove it.

Experiment 3: the effect is not just arithmetic anxiety wearing a lab coat

A skeptic might say fractions are special. Some adults dislike them. Some may remember school badly. Some may simply decide that fraction problems are not worth their time. Fair enough. Fractions have a talent for making otherwise competent adults suddenly inspect the ceiling.

Experiment 3 therefore moves to reading comprehension. Participants answer SAT-style questions based on paired short texts. The design again includes a pretest, a learning phase, and a final unassisted test. The AI group receives access to a chat assistant during the learning phase; the control group receives a reference panel with general reading tips, which is removed before the final test.

After exclusions, the final sample includes 168 participants: 85 in the AI condition and 83 in the control condition.

The same pattern appears. On the final test, the AI group’s solve rate is lower than the control group’s: 0.76 versus 0.89, with Cohen’s $d=-0.42$. The AI group also skips more: 0.08 versus 0.01, with Cohen’s $d=0.42$.

This matters because reading comprehension is not simply procedural arithmetic. It involves interpretation, comparison, and construction of meaning from text. If AI assistance weakens later unaided performance here too, the concern becomes broader than “people stopped practicing fractions.” It becomes a question about what happens when AI repeatedly occupies the space where effort, interpretation, and self-correction used to happen.

For business readers, this is where the paper leaves the classroom. Reading comprehension resembles many white-collar tasks more closely than fraction arithmetic does: reviewing memos, comparing claims, interpreting customer messages, summarizing policy changes, evaluating research, or deciding whether two documents actually agree. These tasks are not glamorous, which is precisely why organizations are eager to automate them. They are also where human judgment often lives.

The business problem is not productivity; it is capability accounting

The obvious business reading is: AI can make people faster today but weaker tomorrow. That is directionally useful, but too blunt.

The better reading is that organizations need capability accounting. They need to distinguish between output produced by the combined human-AI system and capability retained by the human after the system is removed, restricted, wrong, unavailable, or inappropriate for the task.

Most AI adoption metrics are system-level metrics. They ask whether work is completed faster, whether quality looks acceptable, whether users are satisfied, and whether costs fall. Those metrics are not useless. They are just incomplete. They do not reveal whether the human operator is becoming more capable, equally capable, or quietly dependent.

A more serious AI deployment should separate three evaluation questions:

This is especially important in roles where junior employees are supposed to learn by doing. If every rough draft, data-cleaning problem, bug, financial model, or research memo is immediately solved by AI, the organization may still receive acceptable short-term output. But the employee may lose repetitions that would have built durable judgment.

The dangerous part is that the loss is delayed. Managers may not notice until the person faces an ambiguous task where AI output is unavailable, unreliable, or politically unsafe to use without independent verification. At that point, the problem will be described as a talent issue. It may actually be a training architecture issue.

How to design AI help that does not become cognitive debt

The paper does not provide a complete product-design playbook, and it should not be treated as one. But its evidence points toward a practical distinction: AI systems should vary their help depending on whether the goal is task completion, skill formation, or decision support.

For pure throughput tasks, direct answers may be appropriate. Nobody needs to preserve the ancient human art of manually reformatting CSV columns. Civilization will cope. But when the task is part of capability development, direct completion should not be the default.

A business-facing framework could look like this:

The unpopular design move is refusal. Not safety refusal, not policy refusal, but pedagogical refusal: “I will not give you the full answer yet. Try this step first.” Current AI products often avoid this because it can reduce immediate user satisfaction. Users enjoy convenience. They also enjoy dessert. Neither fact proves nutritional adequacy.

For enterprise systems, the equivalent is not necessarily refusing help altogether. It may mean forcing a first attempt before AI suggestions appear, showing hints before answers, requiring users to explain the AI output in their own words, or periodically testing unaided performance. The goal is not to make work miserable. The goal is to prevent the tool from removing every useful struggle from the workflow.

What the paper shows, what we infer, and what remains uncertain

The paper directly shows that brief AI assistance can reduce later independent performance in controlled online tasks, and that persistence can also suffer. It shows this across fraction-solving and reading comprehension. It also shows that direct-answer use is associated with the worst downstream pattern in the second experiment.

Cognaptus’ business inference is broader but still bounded: organizations should not evaluate AI assistants only by assisted-task productivity. They should monitor whether users retain independent capability, especially in learning-heavy roles and judgment-heavy workflows.

What remains uncertain is the long-run curve. The experiments last roughly 10 to 15 minutes. They do not prove that months of AI use inevitably cause organizational deskilling. They do not compare many possible assistant designs. They do not test professional workers inside real firms. They do not show whether well-designed AI tutoring could improve long-term capability while still improving short-term output.

Those boundaries matter. The paper is not a warrant for theatrical anti-AI policies. It is a warning against shallow deployment metrics.

The right response is not to ask whether AI is “good” or “bad” for learning. That question is too broad to survive contact with reality. The better question is: what kind of help, for which task, at which stage of user development, with what measurement of later independence?

The strategic lesson: optimize for what users can still do without the machine

The most quietly devastating line of the paper is its design implication: AI should optimize not only for what people can do with AI, but also for what they can do without it.

That is a very different product philosophy from maximizing immediate helpfulness. It asks the system to care about the user’s future competence, not only the user’s current request. In practice, this means AI assistants may need memory of user progress, adaptive scaffolding, domain-specific teaching policies, and sometimes the courage to be less convenient.

For Cognaptus readers building AI into workflows, the lesson is straightforward: do not confuse convenience with capability.

If the goal is output, automate aggressively. If the goal is learning, scaffold carefully. If the goal is expert judgment, make the AI expose alternatives and failure modes rather than simply handing over a polished conclusion. And if the goal is to develop people, measure them after the assistant is gone.

Because the real cost of AI convenience is not paid when the answer appears.

It is paid later, when the user meets a hard problem, no shortcut appears, and the first learned response is to stop trying.

Cognaptus: Automate the Present, Incubate the Future.