Does AI pair-programming make you a worse debugger?

The short answer is: it can, and the mechanism is not mysterious. In the one randomised trial that has directly measured it, developers who learned a new library with an AI assistant scored lower on debugging and code-reading questions than those who worked by hand, and were not meaningfully faster. Other controlled studies show a second effect that is arguably worse: people using assistants tend to believe their code is better than it is. Neither finding means the tools are net harmful for working developers. They mean the skill you delegate is the skill you stop practising, and the practical fix is to keep debugging without the assistant some of the time rather than to give it up.

This piece is narrower than our general article on cognitive offloading and the AI confidence gap. That one covers knowledge work broadly; this one is about debugging and code comprehension for people who write code for a living. Sources were accessed on 11 September 2026.

The mechanism: offloading is fine until your self-assessment drifts

Cognitive offloading is a well-described behaviour. Risko and Gilbert’s 2016 review defines it as “the use of physical action to alter the information processing requirements of a task so as to reduce cognitive demand”. Writing a reminder, using a calculator, letting autocomplete finish a function: all of it is offloading, and most of it is sensible.

The problem is in what governs it. Offloading is steered by a metacognitive judgement about your own ability, and that judgement can be wrong: the review argues that some offloading patterns “arise because individuals rely on an erroneous metacognitive evaluation of demand.” In plain terms: you decide how much to lean on the tool based on how good you think you are, and that self-estimate is unreliable, especially once the tool has been doing the job for a while.

The automation literature explains why you then under-check the output. Parasuraman and Manzey’s 2010 review of decision aids found that “Automation complacency occurs under conditions of multiple-task load, when manual tasks compete with the automated task for the operator’s attention”, that it “is found in both naive and expert participants and cannot be overcome with simple practice”, and that automation bias “results in making both omission and commission errors when decision aids are imperfect”. A code assistant is an imperfect decision aid; a developer with three tickets open is under multiple-task load. The review’s most uncomfortable line is that automation bias “occurs in both naive and expert participants, cannot be prevented by training or instructions”. Seniority is not a shield.

What the coding studies show

The most direct evidence comes from a January 2026 arXiv preprint, “How AI Impacts Skill Formation”, by two researchers at Anthropic. That is a vendor-authored study, though its result runs against the vendor’s commercial interest. The authors “conduct randomized experiments to study how developers gained mastery of a new asynchronous programming library with and without the assistance of AI” and report: “We find that AI use impairs conceptual understanding, code reading, and debugging abilities, without delivering significant efficiency gains on average.” Anthropic’s own write-up quantifies it: “participants in the AI group scored 17% lower than those who coded by hand, or the equivalent of nearly two letter grades. Using AI sped up the task slightly, but this didn’t reach the threshold of statistical significance.”

Two caveats sit in the same paper. First, the effect depended on how people used the tool: “We identify six distinct AI interaction patterns, three of which involve cognitive engagement and preserve learning outcomes even when participants receive AI assistance.” Second, the study used a chat-style assistant, and the authors expect that agentic tools, which write and run code on your behalf, would have a larger effect: “we expect that the impacts of such programs on skill development are likely to be more pronounced than the results here.” This is a preprint about people learning something new; it is not a measurement of what happens to a senior engineer’s existing skills over a year. That study has not been done.

The confidence gap shows up in a security study from Stanford (Perry and colleagues, presented at CCS 2023 and available as an arXiv preprint). Participants with an assistant “wrote significantly less secure code than those without access”, and “participants with access to an AI assistant were more likely to believe they wrote secure code than those without access to the AI assistant”. The mitigating detail matters for practice: “participants who trusted the AI less and engaged more with the language and format of their prompts (e.g. re-phrasing, adjusting temperature) provided code with fewer security vulnerabilities.”

The same gap appears in the METR randomised trial from mid-2025 (arXiv preprint). Sixteen experienced open-source developers completed 246 real tasks in projects they had worked on for an average of five years, mostly using Cursor Pro with Claude 3.5 and 3.7 Sonnet. “Before starting tasks, developers forecast that allowing AI will reduce completion time by 24%.” Afterwards, they “estimate that allowing AI reduced completion time by 20%. Surprisingly, we find that allowing AI actually increases completion time by 19%”. METR describes this as “a snapshot of early-2025 AI capabilities in one relevant setting” and has since published data on late-2025 tools; the models have moved on, and so may the numbers. What is unlikely to move is the direction of the perception error. People felt faster while being slower.

A survey of 319 knowledge workers by Microsoft Research and Carnegie Mellon (2025, CHI) reports the same pattern from self-report: “higher confidence in GenAI is associated with less critical thinking, while higher self-confidence is associated with more critical thinking.” That is a Microsoft-authored paper about a category of product Microsoft sells, and a survey rather than an experiment, so treat it as consistent with the trials rather than as independent proof. Its qualitative finding is the useful part: with an assistant, critical thinking shifts “toward information verification, response integration, and task stewardship”. Verification is a skill. If you never form your own hypothesis about a bug before reading the assistant’s, you are not practising it.

The productivity studies are a different question

The number most often quoted in favour of the tools is 55.8%. It comes from a 2023 arXiv preprint by authors at Microsoft Research and GitHub, in which “Recruited software developers were asked to implement an HTTP server in JavaScript as quickly as possible” and “The treatment group, with access to the AI pair programmer, completed the task 55.8% faster than the control group.” That is a vendor-funded study of a greenfield toy task against a stopwatch. It measures speed on a task with a known answer. It does not measure whether the developer understood the server they built, or could fix it a month later. Speed and skill are separate outcomes, and the two vendor studies discussed here point in opposite directions on them, which is itself informative.

What this means for a working developer

Put the evidence together and the picture is consistent rather than alarming. Delegating the mechanics of code is a normal offload. Delegating the diagnosis of why code is wrong is the part that costs you, because diagnosis is the skill you need to supervise the tool, and it decays when unused while your confidence in it does not.

Some practical responses follow directly from the studies, none of which require abandoning the assistant:

• Form a hypothesis before you ask. Read the stack trace, guess the cause, then prompt. The Anthropic preprint’s learning-preserving patterns all involved engaging with the problem before or alongside the assistant.
• Debug without the tool on a schedule. Not every day, but regularly enough that the muscle exists. The offloading literature is clear that the skill you never exercise is the one whose self-estimate drifts most.
• Treat the assistant’s fix as a claim, not a result. The security study found that lower trust and more prompt engagement produced fewer vulnerabilities. Run the failing test yourself. Read the diff line by line.
• Measure yourself against the clock, not against how it felt. The METR developers were wrong by nearly 40 percentage points about their own speed. Your feeling of fluency is the least reliable instrument you have.

The popular story is overstated in both directions. AI assistants do not make you stupid; a preprint on novices is not a verdict on professionals, and the productivity picture is unsettled. But “pure upside if you use it well” is not what the evidence says either, because the studies keep finding that people are poor judges of whether they are using it well. Keep the tool. Keep the skill. For how we weigh vendor-funded research against independent work, see how we research.

Common questions

Does using GitHub Copilot or Cursor make you a worse programmer?

The controlled evidence is limited to learning tasks. A 2026 arXiv preprint found developers learning a new library with an AI assistant scored 17% lower on comprehension, with debugging the weakest area, and were not significantly faster. Whether existing skills in experienced developers decay over time has not been measured directly. The mechanism (offloading plus inflated self-assessment) is well established.

Why do developers think AI makes them faster when it does not?

In METR’s 2025 randomised trial, experienced developers predicted a 24% speed-up, felt afterwards that they had achieved 20%, and were measured at 19% slower. Cognitive offloading research shows that the self-assessments governing how much we rely on a tool are “potentially erroneous”, and automation research shows people under-check aids they trust. Fluency is not speed.

Is AI-generated code less secure?

In a Stanford user study, participants with an AI assistant wrote significantly less secure code and were more likely to believe it was secure. Participants who trusted the assistant less and engaged more with their prompts produced fewer vulnerabilities. The lesson is about review behaviour: treat generated code as unreviewed until you have read and tested it.

How do I keep my debugging skills while using AI tools?

Form your own hypothesis before prompting, debug without the assistant on a regular schedule, and verify fixes by running tests and reading diffs rather than accepting explanations. The Anthropic preprint found that interaction patterns involving cognitive engagement preserved learning even with AI help. The goal is deliberate practice of diagnosis, not abstinence from the tool.

Are the AI productivity studies trustworthy?

The widely cited 55.8% speed-up comes from a 2023 preprint by Microsoft Research and GitHub authors, using a short greenfield task. An independent 2025 randomised trial by METR found experienced developers 19% slower on real tasks, though METR calls this a snapshot of early-2025 tools. Vendor-funded speed results and skill outcomes are different questions; read both with the funding in mind.