The short version: the research on cognitive offloading and AI does not show that these tools make engineers lose skill. It shows a calibration problem. People leaning on an automated aid tend to rate their own output more highly than it deserves, and the gap between confidence and accuracy is where the cost lands. The fix is structural verification, not willpower.
You open a file you shipped five weeks ago, find a function sitting under your own commit, and realise you cannot say why it works. Not that you forgot the details; you never had them. The suggestion looked right, the tests went green, you moved on.
That feeling deserves an accurate name, and the headline version is the wrong one. Cognitive offloading (handing mental work to an external tool so you don’t have to do it internally) is not making engineers stupid, and nothing in the research below shows AI use causing lasting skill loss. What the literature on cognitive offloading and AI does document is narrower, and more useful: when you pass a judgement to an automated aid, your confidence in the result comes loose from its accuracy, and the checking that would have caught the difference quietly gets shorter.
Cognitive offloading is not the problem
Writing the meeting time down is cognitive offloading. So is letting the type checker remember the shape of an object. Risko and Gilbert’s 2016 review in Trends in Cognitive Sciences gave the concept its modern framing, and it establishes early that offloading is ordinary and usually a good trade. Nobody is arguing you should recompute a hash in your head.
The interesting part is the second half. That review (a synthesis of prior work, published years before anyone shipped an LLM into an editor) describes offloading decisions as driven partly by your metacognitive judgement of your own ability, and notes those judgements are frequently inaccurate. Get the estimate wrong and you offload the wrong things. The failure mode isn’t the tool. It’s a bad read on what you could have done unaided, and therefore on how hard you needed to look at what came back.
The confidence gap, measured in actual code
The most direct evidence for that mechanism inside a programming context comes from Perry, Srivastava, Kumar and Boneh, published at ACM CCS 2023. In a controlled study of security-related programming tasks, participants who had an AI code assistant wrote significantly less secure code than participants who did not, and were more likely to believe their code was secure. Worse output, higher confidence, in the same population.
Be clear about what that study can carry. The participant count was modest, the tasks were constrained security exercises rather than open-ended feature work, and the assistant ran on codex-davinci-002, a 2022-era model nobody uses now. It demonstrates a mechanism; it does not measure how bad things are with the model you opened this morning. Anyone quoting it as a live statistic about current tools is overreaching.
Alongside it sits Lee and colleagues’ CHI 2025 survey of 319 knowledge workers, covering 936 self-supplied task examples. Higher confidence in generative AI was associated with less critical thinking effort; higher confidence in one’s own expertise was associated with more. Participants also described their effort moving away from producing work and toward verifying and integrating what the model produced. That is a self-report survey and it is correlational: it measures what people say about their own thinking, which is precisely the faculty in question. It cannot show that AI reduces anyone’s ability to think critically, and it does not claim to. What it does is put a second, independent finger on the same variable: how confident you are in the tool tracks how little you scrutinise it.
This problem has a name, and it predates the IDE
Here is the part most AI coverage skips, and it is the part that actually helps you. Human factors research has been characterising this exact failure for decades in cockpits, control rooms and process plants, under the names automation complacency and automation bias. Parasuraman and Manzey’s 2010 synthesis in Human Factors pulls the experimental work together, and four of its conclusions transfer straight into a software team.
- It shows up in novices and in experts. Domain skill does not confer immunity.
- When the automated aid is imperfect, it produces errors of omission (you miss what the aid missed) and errors of commission, where you follow the aid into an action you’d never have taken alone.
- It emerges specifically under multi-task load, when attention is being split across several things at once.
- Simple practice, training and instructions do not reliably prevent it.
An imperfect aid, an expert operator, three Slack threads and a standup: the conditions those experiments describe look a lot like an ordinary Tuesday afternoon. The fourth point is the load-bearing one, because it rules out the advice everyone reaches for first.
If training and instructions don’t reliably fix automation complacency, then “be more careful with AI output” is not a mitigation. It’s a wish.
The studies you have already seen quoted
Three of these circulate constantly, and you should know what each one is before you cite it in a design review. Our full standard for what counts as usable evidence is on the how we research page.
The MIT Media Lab EEG work, “Your Brain on ChatGPT”, is the source of nearly every “AI rots your brain” headline. It is a non-peer-reviewed preprint. The sample is small, and a published comment has raised methodology and reproducibility concerns. Its widely repeated phrase “cognitive debt” is the authors’ framing of their own results, not an established finding, and it should not be passed around as one.
The METR trial is the one where experienced open-source developers were 19% slower with AI tools while believing they had been 20% faster. It is also a non-peer-reviewed preprint, with 16 developers working on repositories they already knew intimately. Treat it as a vivid anecdote about the unreliability of self-assessment (which is the theme of this article) and not as evidence about productivity in general or about anyone’s health.
Gerlich’s 2025 paper in Societies reported a negative correlation between self-reported AI tool use and critical thinking scores across 666 participants, statistically mediated by cognitive offloading and larger among younger respondents; it is cross-sectional, self-report, self-selected, correlational only, and a formal correction to it was later published, so it can support no causal claim whatsoever.
Further back sits Sparrow and colleagues’ 2011 “Google effects” study in Science, which reported that people expecting continued access to information recalled where to find it rather than the information itself, though that work sits inside the broader psychology replication debate, so it belongs here as the ancestor of the question rather than as settled fact.
Note what is missing from all of it: there is no good evidence that these tools cause lasting cognitive decline or permanent skill loss. Nobody has shown that. If you came here worried about it, the honest answer is that the question is open and the alarming version is unsupported. The nearer risk is the one this piece is about: trusting your own sense of sharpness. That same trap shows up after a bad night’s sleep, where caffeine restores how alert you feel without restoring procedural accuracy.
Make verification structural, because willpower is the wrong tool
What follows is my reading of how the human factors conclusion applies to software work, not a finding from any of the studies above. The evidence says complacency resists training and instruction. The inference is that whatever you do about it has to live in your process, where it happens whether or not you feel sharp that afternoon.
- Write the assertion before you ask for the implementation. A test you specified yourself is a check the model did not get to define.
- Separate generation from review in time. Accepting a diff in the same keystroke that produced it collapses two different cognitive acts into one, and the second one loses.
- Flag AI-heavy changes in review so a second person knows to read for logic rather than style. Complacency is individual; a review process is not.
- Watch for load. The research locates this failure under multi-task conditions, which is an argument for not accepting non-trivial generated code while you are half in a meeting.
- Periodically solve something unaided, not as self-improvement theatre but as calibration data. You cannot correct an estimate of your own ability that you never test.
One boundary worth stating plainly: if what actually prompted you to read this is a real change in memory or concentration that shows up away from the keyboard, that is a conversation with a doctor, not a tooling question. Nothing in this literature diagnoses anything, and this article is not medical advice. See our medical disclaimer.
Common questions
Does daily AI-assisted coding make me a worse engineer over time?
No study in this area has shown lasting skill loss, and the ones people cite for it are either correlational or non-peer-reviewed preprints. The documented effect is about calibration in the moment (confidence outrunning accuracy on the task in front of you), not about deterioration you carry around.
What is cognitive offloading?
Cognitive offloading is the use of an external tool or physical action to reduce the mental work a task demands: a written note, a calendar reminder, a compiler, an AI assistant. Risko and Gilbert’s 2016 review treats it as ordinary and usually beneficial. The complication they identify is that the decision to offload rests on your judgement of your own ability, and that judgement is often wrong.
I already review everything the assistant writes. Isn’t that enough?
Possibly not, and that is the uncomfortable finding. Parasuraman and Manzey describe complacency as a failure of attention allocation toward an aid you have come to trust, which means the review can happen and still be shallower than the one you would give unfamiliar human code. Structuring the check (a test you wrote first, a second reader) does more than intending to look harder.
Does seniority protect against this?
The automation literature reports the effect in expert operators as well as naive ones, so experience alone is not a defence. One suggestive detail from the CHI survey: confidence in your own expertise was associated with more critical thinking effort, not less, but that is a correlation in self-reported data, so hold it loosely.
Should I turn the assistant off for security-sensitive work?
The CCS study is the one result here that came from an actual controlled comparison, and it found less secure code plus higher confidence in it, with the caveats that the tasks were narrow and the model is now several generations old. That is a reasonable case for heavier review on security-critical paths. It is not a reasonable case for claiming today’s tools produce insecure code at any particular rate.
The number to watch is not how much you offload
If you take the confidence-accuracy framing seriously, the question stops being how much of your thinking the machine is doing. Plenty of it should be. The question becomes whether you can still tell the difference between code you have genuinely checked and code that merely looked right on the way past, because everything documented here says that distinction goes quietly, without announcing itself.
That is a calibration problem, and calibration problems have a fix that has nothing to do with trying harder. You build the check into the path so it happens on your worst afternoon, in your fourth hour of context switching, when you feel most certain you don’t need it. That is precisely when the research says you do.
Leave a Reply