A colleague told me recently that he could no longer write a regex without asking a model. He did not sound worried, and maybe he should not be: regexes are exactly the kind of thing worth delegating. But then he added that he had also stopped reading the stack traces. He pastes them in and waits.

That second habit is different. Reading a stack trace is not a chore that sits between you and the work. It is the work: it is how you build the mental model of a system that lets you debug the next problem faster, and the one after that without help.

Psychologists have a name for handing mental work to the outside world: cognitive offloading. Humans have always done it, and it is often smart. The question for 2025 is narrower and more practical: which offloading to AI makes you better, which quietly makes you worse, and how do you tell the difference while still shipping on time?

This post summarizes what the research actually says (including what it does not say yet) and ends with a concrete protocol for engineers.

1. Cognitive offloading is old and mostly good

Risko and Gilbert (2016) define cognitive offloading as using physical action to alter the information processing requirements of a task so as to reduce cognitive demand. Writing a shopping list, tilting your head to read rotated text, setting a phone reminder, keeping a TODO file: all offloading.

Key points from that literature:

  • Offloading is a decision. People offload more when they doubt their own memory, even when that doubt is wrong. Metacognition (your belief about your ability) drives the choice as much as your actual ability.
  • Offloading improves immediate performance. You remember more items with a list than without one.
  • It can reduce what you retain internally. When people expect information to stay available, they invest less in remembering it.

None of this is new or alarming. Engineers offload all the time: IDE autocomplete, documentation, Stack Overflow, git log instead of memory. The question is never "offload or not" but "what am I offloading, and do I still need to be able to do it myself?"

2. The Google effect, and a caution about it

Sparrow, Liu and Wegner (2011, Science) reported that when people expect to have future access to information, they recall the information itself less and recall where to find it better. The paper popularized the "Google effect": memory adapting to search engines as an external store.

Two caveats worth knowing:

  • Replication is mixed. A large replication project of social science experiments in Nature and Science (Camerer et al., 2018) did not replicate one of the paper's experiments, and a later independent replication also failed to find the effect. The broader idea (we remember sources instead of content when content is easy to retrieve) remains plausible, but the specific findings are less solid than the headlines suggested.
  • Search and generation are different. A search engine gives you documents you still have to read, judge and combine. A chatbot gives you the combined, judged answer. The amount of thinking you can skip is much larger, which is why the question has come back in 2025.

3. What the 2025 evidence says

Three pieces of research got most of the attention this year. They point in the same direction, but they are very different kinds of evidence.

Study Design Main finding How much to trust it
Lee et al. (Microsoft Research and Carnegie Mellon), CHI 2025 Survey of 319 knowledge workers, 936 real examples of GenAI use at work Higher confidence in GenAI is associated with less critical thinking; higher self-confidence with more. Critical thinking shifts toward verification, integration and "task stewardship" Peer reviewed, realistic tasks, but self-reported perceptions, not measured skill
Gerlich, Societies (January 2025) Surveys of 666 participants plus interviews Significant negative correlation between frequent AI use and critical thinking, mediated by cognitive offloading. Younger participants more dependent; higher education associated with better critical thinking regardless of AI use Peer reviewed, larger sample, but correlational: it cannot show that AI use causes lower critical thinking
Kosmyna et al. (MIT Media Lab), "Your Brain on ChatGPT", arXiv, June 10, 2025 54 participants writing essays with an LLM, a search engine, or no tools, over several sessions, with EEG; 18 completed a fourth, swapped session Brain-only writers showed the strongest, most distributed connectivity; LLM users the weakest. LLM users reported the lowest ownership and "struggled to accurately quote their own work" A preprint, not peer reviewed, released a week ago. Small sample, one task type. Interesting, not conclusive

And one from 2024 that is closer to a causal answer:

Study Design Main finding
Bastani et al. (Wharton), "Generative AI Can Harm Learning", 2024 working paper Field experiment with about 1,000 high school math students in Turkey Students with unrestricted access to a GPT-4 based assistant did 48% better on practice problems but 17% worse than the control group on the exam without AI. A "GPT Tutor" version with guardrails (hints, not answers) improved practice by 127% and showed no significant exam drop

What these studies support

  • Confidence in the tool, not the tool itself, predicts disengagement. In Lee et al., the people who trusted GenAI more reported thinking less critically. This is a metacognitive effect, the same mechanism Risko and Gilbert describe.
  • Getting answers during practice can hurt learning, and the design of the assistant matters. In Bastani et al., the same model used as an answer machine harmed learning; used as a tutor, it did not.
  • The work changes shape. Knowledge workers report spending less effort on producing and more on verifying and integrating. That is only an upgrade if verification is actually done.

What they do not show (yet)

  • That AI use causes lasting declines in general intelligence or critical thinking. The correlational data cannot show that, and the experiments are short.
  • That the EEG differences in one essay-writing study generalize to engineering, or reflect harm rather than reduced effort on a task that was delegated. Less brain activity while a tool does part of the job is partly expected.
  • That the effect is the same for experts and novices. The learning studies are about students acquiring a skill; seasoned engineers delegating familiar work may be in a different situation.

The balanced reading: there is a consistent signal that passive use reduces engagement and learning, and good evidence from learning science (below) about why. There is no good evidence yet for the alarming version of the claim.

4. Why it happens: desirable difficulties and the generation effect

Two well-established findings from learning science explain most of the pattern, and they are much better replicated than any of the AI-specific studies.

Desirable difficulties (Robert and Elizabeth Bjork). Some conditions that make learning feel slower and harder produce better long-term retention and transfer: retrieving from memory instead of re-reading, spacing practice over time, mixing problem types (interleaving), and generating answers before seeing them. The catch is that these conditions make performance during practice look worse, so learners (and tools optimized for smooth experience) tend to avoid them.

The generation effect (Slamecka and Graf, 1978). Information you generate yourself is remembered better than information you read. Producing an answer, even a wrong one, encodes it more deeply than receiving it.

Retrieval practice (Roediger and Karpicke, 2006). Testing yourself beats re-studying for long-term retention, even though re-studying feels more productive at the time.

Put these together and the mechanism is clear. An AI assistant that hands you the finished answer removes exactly the difficulties that produce learning: retrieval, generation and struggle. It is optimized for performance now. Your skill is built by effort now.

There is also an older engineering version of this argument. Lisanne Bainbridge's "Ironies of Automation" (1983) pointed out that when automation handles the routine work, operators lose practice in the skills they need when automation fails, and they are expected to step in precisely in the hardest situations. Replace "operator" with "on-call engineer" and "automation" with "coding assistant" and the paper reads as if it were written this year.

5. Offload vs keep: a quick map

Not all offloading is equal. A useful test: would I need to do this myself, under pressure, without the tool? And: is this the skill that makes me valuable?

Usually fine to offload Keep doing yourself (at least some of the time)
Boilerplate, scaffolding, config syntax Designing the data model and system boundaries
Regexes, one-off scripts, format conversions Reading stack traces and forming the first hypothesis
Recalling API signatures and flags Deciding what the code should do and why
First drafts of docs, commit messages, tests you will review Reviewing code for correctness and security
Translating between languages you already know Learning a new language, framework or domain
Summarizing long threads you would skim anyway Writing the design doc that forces you to think

The right column is not "never use AI". It is "do not let AI be the only one who did it".

6. A practical protocol for engineers

These are habits, not rules. Pick the ones that fit how you work.

1. Think first, then ask

Before prompting, spend two minutes writing your own hypothesis, plan or answer. A sentence or a bullet list is enough. Then ask the model and compare. This keeps the generation effect on your side, and the comparison is where you learn: you notice what you missed, or what the model got wrong.

2. Explain it back

After accepting AI output, explain it in your own words: in the PR description, a code comment, or out loud. If you cannot explain why the fix works, you do not own it yet. The MIT preprint's finding that LLM users struggled to quote their own essays is a reasonable warning sign here, even with its limitations.

3. Use AI as critic and tutor, not only as author

The Bastani study's tutor condition is the model to copy. Useful prompts:

  • "Here is my approach. What are the weaknesses? Do not rewrite it."
  • "Give me a hint, not the answer."
  • "Ask me questions until I find the bug myself."
  • "Review this PR as a strict senior engineer. List issues by severity."

Writing first and asking for critique keeps you as the author and still gets you most of the value.

4. Do deliberate no-AI reps

Pick small, regular tasks you will do without assistance: a weekly kata, the first hour of debugging an incident, a small feature in a codebase you want to learn deeply, a technical interview practice problem. Pilots still fly by hand to keep the skill; engineers can do the same.

5. Review AI code actively, not passively

Passive review is scrolling until it looks plausible. Active review:

  • Predict what the code should look like before reading it.
  • Run it, and write or read the tests that would catch it being wrong.
  • Check edge cases, error handling, security (injection, secrets, permissions) and dependencies the model added.
  • Ask "why this way?" about every non-obvious choice, and check the answer against the docs, not against the model.

Lee et al. found that confidence in the tool predicts less critical thinking. Active review is how you keep confidence from replacing verification.

6. Calibrate your trust per task

Keep a rough mental record of where the assistant is reliable for you (boilerplate in a popular framework) and where it is not (your internal APIs, concurrency, recent library versions). Trust should be earned per domain, not granted globally.

7. Protect learning phases

When you are learning something new, lean toward the tutor mode and the no-AI reps. When you are executing on something you already master, delegate more freely. The cost of offloading is highest exactly when you have the most to learn.

7. For team leads

  • Do not measure only output speed. If juniors ship twice as fast but cannot debug their own code, the team is borrowing against the future.
  • Ask for the reasoning in reviews. "Why this approach?" is a fair question whether a human or a model wrote the first draft.
  • Make space for unassisted work in onboarding and learning tasks, and say so explicitly so it does not look like slowness.
  • Run incident reviews that test understanding, not only timelines. The engineer on call at 3 a.m. needs the mental model, not a chat history.

Why this matters

  • Offloading is normal and often smart. The question is what you offload, not whether.
  • The 2025 evidence points one way but is still early. Survey and correlational data, one small unreviewed EEG study, and one strong field experiment. Treat it as a signal, not a verdict.
  • Passive use is the risk. Confidence in the tool reduces critical engagement; answer-giving during practice reduces learning.
  • Learning science explains why. Desirable difficulties, generation and retrieval are the mechanisms that AI can remove if you let it.
  • Small habits fix most of it. Think first, explain back, ask for critique, practice without the tool, and review actively.

Final Thoughts

AI assistants are the most powerful tools for thought most of us have ever had, and refusing to use them is not a serious option for a working engineer. But a tool that can do your thinking will, if you let it, and the cost does not show up in this sprint's velocity. It shows up the day the tool is wrong, unavailable, or out of its depth, and you are the one who has to know.

The goal is not to use AI less. It is to stay the person in the loop who understands what is going on. Use the model to go faster on what you already know, and to learn faster what you do not, and keep doing enough of the hard parts yourself that you could still do them tomorrow.

Sources