My fastest reflex these days: open the question, bring in the model, read the answer, adjust, move on. It is often productive. It also has a cost: I start on my own less often.
I notice it when I write SQL, think through an architecture problem, or build an analysis without asking for a first draft. The skill is still there, but switching it on takes more effort than it used to.
Does AI make you worse at critical thinking?
There is a strong association, but it does not prove cause. Gerlich found in 2025, with 666 participants, a strong negative correlation between frequent AI use and critical thinking: r = −0.68 (Societies, volume 15, issue 1). The link runs through cognitive offloading. The more often you hand off the thinking, the less you train the skill.
Cognitive offloading means moving a thinking step outside your head: to a calculator, a search engine, or now a language model. For mental arithmetic that is rarely a problem. For judgement and reasoning it is, because you use that skill every working day.
A correlation of that size is high for behavioural research. The more often people used AI, the lower they scored on critical thinking on average. That does not settle the direction: it could also be that people who think less critically reach for AI sooner.
It is one study. I do recognise the mechanism in myself, and that is enough to take it seriously. The number and its source are on my AI statistics page.
Why does critical thinking wear down?
Because you keep it in shape through friction: forming a first position, ordering arguments, connecting loose pieces of information. Skip that friction by default and the skill is less available when you need it.
There is a second effect underneath. The time AI frees up for me does not go to thinking or rest by itself. It goes to more projects. If you do not choose deliberately what that time is for, you mostly get more work in return, and even fewer moments to think something through yourself.
Who is most at risk?
Probably the people who gain the most on paper. In an NBER study of roughly 5,000 support staff, the least experienced gained around 35% in productivity, against 14% on average. That is good news for their output. It also means they are the ones handing off the most thinking steps while they are still building the skill.
That link is my own interpretation; neither study measures it directly. For a team it is still a reason to work differently with juniors than with people who have done the job for ten years.
Why do better tools make the risk bigger?
Because checking feels less worthwhile the more often the model is right. AI agents now run without errors 95 to 99 percent of the time. At that rate every check feels like wasted time, yet someone still has to spot the one mistake. That takes exactly the skill that this trust trains less.
Users often react to such a mistake with distrust: if nobody explains it, they start working around the tool. The better reaction is a person who sees the mistake, understands why the model got it wrong, and corrects it. That only works if the person still knows the craft.
When should you bring in the model?
After you have a position of your own. If you ask first, then read, then adjust, you are editing the model’s position. It feels like thinking, but you skipped the step where you pick a side yourself.
My order:
- Write your own answer first.
- Put your assumptions next to it.
- Then let the model attack, improve, or add to it.
That way the model stays a sparring partner that responds to your reasoning.
Create no-AI zones
Some pieces I deliberately start myself. Now and then I read the paper instead of the summary, write a query without autocomplete, or debug code without a copilot. It is slower, and that is the point: it keeps the muscle under tension. Every paper I have summarised for me is friction I avoid. Sometimes that is the right call; I just want to make it on purpose.
My rule of thumb for what belongs in such a zone: anything you will have to give the final judgement on. The model may write a first draft of a routine email. Whether a project goes ahead, how an analysis is set up, and what caused a failure, I start on myself.
What does this mean for teams?
Measure, next to speed, whether people can still judge for themselves. In trainings from my previous role we measured whether people got faster with AI. Whether they stayed sharp, we did not measure, and that was a blind spot.
What I now advise teams:
- In a review, have people write down their own conclusion first, and only then put the AI version next to it.
- Build points into AI applications where a person has to judge before the system moves on. Have the application show its sources and say what it does not know, so checking is actually possible.
- Twice a year, have a normal case worked out without AI and discuss the reasoning, not just the outcome. That shows whether the judgement is still there.
- Set ground rules before the tools arrive. A one-page policy on day one keeps people from quietly using personal ChatGPT accounts for work documents.
More on checkpoints and adoption is in my memo on 35+ implementations.
To start tomorrow: at your next analysis, write down your own conclusion first and only then open the model.
Want to read on?
The memo collects the lessons from 35+ AI projects: where pilots got stuck and what I do differently because of it. A 14-minute read.
30 minutes · free, no obligation