The 'I Don't Know' Muscle
A study found that AI access dropped critical thinking to a third of baseline. Here's how I'm redesigning team flows to keep the judgment habit alive.
I was watching two engineers debate a code review the other day. The PR had a tricky ordering dependency—something about a batch job that could start before its migration ran. One engineer said "I think it's fine, let me check." The other said "I don't know, actually. Let me trace the execution path."
That second sentence—"I don't know"—is the most expensive sentence in software. And also the most valuable.
It's expensive because uttering it costs status. It's valuable because it's the precondition for learning. Every bug I've ever seen in production traces back to someone who thought they knew but didn't. Every time I've fixed something for good, it started with admitting a gap.
So when I read the new study from Capraro, Marcoccia, and Quattrociocchi, it hit differently than the usual "AI is making us stupid" takes. It forced me to think about what I'm actually building when I put AI into my team's daily flows.
What the study actually found
The researchers gave people questions that a typical LLM couldn't answer correctly—obscure visual details from films, things a frontier model would confidently get wrong. Half the participants had access to AI advice; half didn't.
The numbers tell a stark story.
People without AI said "I don't know" 44 percent of the time. People with AI said it 3 percent of the time. That's not a small change. That's the collapse of a cognitive habit.
The accuracy numbers are worse. Unassisted participants got 27 percent right. AI-assisted participants got 9 percent right. They were three times less accurate, yet they reported twice the confidence.
The researchers tried offering money for correct answers. It barely budged the needle: "I don't know" climbed from 3 percent to 8 percent. Accuracy from 9 percent to 16 percent. Still miles below the no-AI baseline.
This isn't about people being lazy or stupid. The study deliberately used a model that was usually wrong on these questions, so participants couldn't rationalize that they were sensibly delegating to a trustworthy tool. The suppression of critical thinking happened anyway.
What's really being suppressed
The finding that concerns me most isn't the accuracy drop. It's the "I don't know" collapse.
The capacity to recognize the limits of your own knowledge is a skill. It's a cognitive reflex you develop by exercising it. Every time you pause and say "actually, I'm not sure about that," you strengthen a neural circuit. Every time you reach for an answer before that pause happens, you let that circuit weaken.
What the study measures, I think, is not people blindly trusting AI. It's something subtler: the mere availability of an answer changes whether you bother to check if you know something in the first place. The question never gets asked internally because an external answer is already on its way.
The Wharton researchers who coined the term "cognitive surrender" earlier this year put a name on it. But the mechanism matters more than the label. It's not that people evaluate an AI answer and decide to accept it despite doubts. It's that the evaluation step itself gets bypassed.
Why this matters for team flows
As a tech lead, I've been thinking hard about how AI fits into engineering workflows. Code review, pair programming, architectural decisions—everywhere we put AI, we're changing the cognitive environment.
Here's the uncomfortable pattern I've started noticing in my own teams.
A developer gets a PR review suggestion from an AI coding assistant. The suggestion is plausible but subtly wrong—maybe it handles the happy path but misses an edge case. The developer approves it without tracing through the logic. Not because they're lazy. Because the AI-generated answer arrived pre-formatted with confidence, and evaluating it critically requires the same energy as saying "I don't know" in that study.
The cost isn't the wrong answer. The cost is the skipped evaluation.
When AI becomes a natural part of your team flow, you need to ask not just "does this tool produce correct answers?" but "what cognitive habits does this tool reinforce or suppress?"
What I'm changing
I've started building explicit friction into our AI-assisted workflows. Not to make AI harder to use—to make the human judgment step harder to skip.
In code review, we added a rule: any AI-generated review comment must be accompanied by a one-sentence explanation of the reasoning, written by the human. Not pasted from the AI. Written. It takes ten seconds, but it forces the evaluation step.
In our pair programming sessions with AI, I've started asking my team to articulate what they expect the AI to suggest before they prompt it. Write down your hypothesis. Then compare. The delta between expectation and output is where learning lives.
For architectural decisions, we use a lightweight ADR template that requires listing at least two alternatives the AI didn't propose. The act of generating alternatives forces the cognitive work that the AI would otherwise short-circuit.
These are small things. They don't solve the problem. But they create space for the "I don't know" reflex to survive.
The thing that still bothers me
None of this addresses the deeper issue.
The study measured people making decisions with AI available on demand. That's the world my team lives in now. We have AI in our IDE, in our chat, in our documentation. It's not a tool we reach for—it's ambient.
A junior engineer on my team told me last week that they'd started asking AI to review their own PRs before submitting them. Not because they distrusted their work, but because the AI was there. The friction of thinking through their own code had been replaced by the frictionless action of pasting a diff into a prompt.
I didn't tell them to stop. The AI was giving genuinely useful feedback on formatting and missed edge cases. But I noticed something: they were getting better at writing code that passed AI review, and I'm not sure they were getting better at understanding their own code.
That's the trade-off I can't optimize away with a process change. It's a question of which skills we're building and which we're letting atrophy.
The open question
I don't have a neat conclusion here. I'm more alert to the pattern now, and I've put some guardrails in place. But I suspect the real answer isn't about tools or workflows.
The researchers in this study found that monetary incentives barely changed behavior. If a cash reward can't restore the "I don't know" reflex, a code review checklist probably won't either.
What might work is something harder to institutionalize: culture. A team where saying "I don't know" is socially safe. Where the engineer who admits uncertainty about an execution path earns more respect than the one who confidently accepts an AI-generated answer. Where the evaluation step—the pause—is treated as the real work.
I'm still figuring out how to build that. But at least now I know what I'm building against.