Is AI making us dumber? What the studies say about developers

Learning a new skill. Anthropic researchers ran a randomized trial with 52 mostly junior developers learning Trio, a Python library none of them had used. Those with an AI assistant scored 50% on a quiz afterwards. Those who coded by hand scored 67%. The biggest gap was in debugging, and the AI group was not significantly faster (Anthropic).

How they used it mattered more than whether. Developers who handed all the code to the AI scored under 40%. Those who asked only conceptual questions and wrote the code themselves, or asked for explanations along with the code, scored 65% or more (Shen and Tamkin, 2026). The study was small and used a chat assistant, not an agent.

Speed. In METR's 2025 trial, 16 experienced open source developers worked 246 real issues in their own repositories. They expected AI to make them 24% faster, and afterwards believed it had made them 20% faster. Measured, they took 19% longer (METR).

In February 2026 METR said its follow-up data, from 57 developers, was unreliable, mostly because many developers no longer wanted to work without AI. It thinks AI speedups are likely larger now (METR update). So the 19% is out of date. The gap between how fast it felt and how fast it was is still worth knowing, though METR has not measured it again.

Thinking at work. Microsoft Research and Carnegie Mellon surveyed 319 knowledge workers about 936 real uses of AI. Higher confidence in the AI went with less critical thinking. Higher confidence in their own ability went with more. The thinking shifted toward checking, combining and looking after the AI's output (CHI 2025). This is what people reported, not a measurement.

The brain study. MIT Media Lab's "Your Brain on ChatGPT" put 54 people in three groups to write essays: with ChatGPT, with a search engine, or with nothing. EEG showed the weakest brain connectivity in the ChatGPT group, and those people struggled to quote essays they had just written (arXiv). It is an arXiv preprint with a small sample, about essays, not code, and only 18 people did the final session.

The worry is not abstract. One developer wrote that "after two years of Claude Code and Cursor I think I forgot how to write code by hand," and asked how others got their skills back (513 upvotes, r/cscareerquestions). In another thread: "I'm at staff engineer with 15+ years of coding experience and there's no way I could pass a coding interview today" (r/cscareerquestions).

For others it is about understanding, not syntax. "The reviewer opens a PR and asks 'why did you structure it this way.' The author says 'the AI suggested it.'" (504 upvotes, r/cscareerquestions). A project lead wrote: "I haven't seen the code for a few months now. When someone asks me a question i give it to an agent and copy-paste response" (r/artificial).

What people do about it varies. Some take a break: "This is the first time I've coded myself without AI in a year, and I feel both amazing and incredibly sad" (1,887 upvotes, r/gamedev). Some propose a side repo that does not allow AI-generated code (r/webdev). On the METR thread, a comment with 221 upvotes said the interesting part was never the speed, but "reduced code understanding over time" (r/ExperiencedDevs).

The studies point to habits, not to settings or to quitting AI. Each comes from the evidence above or from older work on automation.

• Ask about ideas, write the code yourself. In Anthropic's trial, the developers who asked only conceptual questions and wrote the code themselves kept their learning. The researchers wrote that "getting painfully stuck" is likely important for mastery (Anthropic).
• Ask why after the code arrives. Developers who generated code and then asked follow-up questions about it also scored high (Shen and Tamkin).
• Read before you approve. In the Microsoft survey, more trust in the tool went with less critical thinking, and the thinking that remained moved to checking the output (CHI 2025). One commenter put the hard question plainly: "how much of it are you REALLY reading as opposed to skimming?" (r/cscareerquestions).
• Take over by hand now and then. In 1983 Lisanne Bainbridge wrote that physical skills "deteriorate when they are not used", so an operator who mostly monitors may no longer be able to take over. One fix she offered: hands-on control "for a short period in each shift" (Ironies of Automation). Developers have made the same link to aviation (r/webdev).

The METR result still carries one lesson: in that study, how it felt was a poor guide to how it went. Counting what you actually did is a better one.

We made a free tool for one piece of this. Who said yes? reads the Claude Code and Codex logs on your computer and counts how many of your agent's actions you approved yourself, at the prompt. Codex logs do not record each yes, so for Codex it shows the approval rule instead. It asks you to guess first. Run npx github:skprasad-korture/who-said-yes. It has no network code and needs no account.

What it found for one of us. On 9 November 2026, SK's Claude Code logs from 8 October to 9 November held 17,558 agent actions across 100 sessions. He said yes himself 36 times, about 1 in every 488 actions. 818 of his 824 file edits ran with no prompt shown to him. SK is not a developer. He builds with agents and wanted to know who was making the calls.

A count is not a verdict. A low number can mean good rules or no reading at all. Only you know which.

How KORTURE.ai measures this: Sense reads your own chats on your computer, and shows the moments behind each reading in your own words, such as when you made the call before asking and when you let a run keep going.