Every time I write a grocery list I am off mental effort. So is anyone who uses a calculator, a calendar, or Google Maps. Psychologists have a tidy name for this: cognitive off, which Risko and Gilbert defined back in 2016 as using physical action to reduce the mental demands of a task. It is one of the oldest tricks of our species. Writing itself is cognitive off. Nobody thinks the invention of the notebook made humanity dumber.
So when people fret about AI making us stupid, my first instinct is to roll my eyes. My second instinct, after a year of managing engineering teams that use Claude Code and Codex all day, is to stop rolling my eyes and actually look at the research. It turns out the researchers have been busy, and the picture is more specific and more uncomfortable than the usual “kids these days” complaint.
The key distinction, which I had not appreciated until recently, is between off a task and off the learning that the task would have produced. A grocery list offloads the task of remembering milk. It does not prevent you from knowing what milk is. But when you hand an LLM a problem you have never solved yourself, you offload the task and the learning at the same time, and you may not notice, because the task still gets done. The University of Technology Sydney put out a report this spring drawing exactly this line: off is fine until the thing you offload is the work that would have built or maintained a skill. At that point it stops being off and becomes atrophy.
The evidence for this in software is now direct rather than anecdotal. Anthropic ran a randomized trial in which professional developers learned an unfamiliar Python library, half with an AI assistant and half without. The AI group finished faster, as you would expect. Then everyone took a quiz on what they had just built. The AI group scored about 17 percent lower, and the people who had delegated the most to the model did the worst, averaging under 40 percent. The paper’s authors call this a tradeoff between productivity and skill formation, which is polite. What they observed was working code produced by people who could not explain it, which is a sentence I have now written in three different places because it keeps being the whole problem.
That study was done on experienced engineers. A follow-up line of work looking at persistence found that AI assistance also makes people give up sooner when the assistant is taken away, and the literature on novices is worse still, because a beginner has no prior expertise to compare the model’s output against. They cannot tell a good answer from a fluent one. Microsoft and Carnegie Mellon surveyed a few hundred knowledge workers last year and found that the more confidence someone had in the AI, the less critical thinking they reported doing. Nobody in that survey was being lazy. They were being reasonable. If the tool is usually right, checking it feels like a waste of time. That is precisely the trap Lisanne Bainbridge described in “Ironies of Automation” in 1983: the skills that decay while the machine runs smoothly are the ones you need the moment it fails.
Addy Osmani gave the engineering version of this its name last year: comprehension debt. Technical debt is code you understand but wish you had written better. Comprehension debt is code that works and that nobody on the team can explain. It accrues silently, it compounds, and it comes due at the worst possible moment, which is 2 a.m. during an incident when the person who “wrote” the module is staring at it like a stranger. It isn’t just potential outages that should worry us either. Code no human understands entering people’s phones, their cars, their hospital beds is a moral hazard. Legal briefs, investment plans, contractor estimates, or work reports generated by AI but not understood by the human sender create all manner of chaos and liability. In education alone the academic integrity issue has ballooned into a full blown crisis. The MIT Media Lab preprint that measured reduced brain engagement in students writing essays with ChatGPT called the broader phenomenon cognitive debt. It is a debt we are passing down to our children via technology arguably more dangerous than any private or government debt.
I want to be careful here, because it would be easy to slide into the printing-press lament I made fun of in a previous post. The tools are not the problem. I am more productive than I have ever been and I have no intention of giving that up. The problem is that we adopted the tools and kept the old workflow, and the old workflow assumed that whoever produced the work had understood it along the way. Code review, standups, “LGTM,” the whole apparatus of software accountability was built on that assumption. It no longer holds, and nothing has replaced it.
Here is what I think replaces it, and it is smaller than you might expect. The learning-science literature has been clear for decades that explanation is the thing. Reading an explanation feels like understanding; producing one is understanding, or at least the closest observable proxy we have. This is the illusion of explanatory depth: people rate their grasp of a mechanism highly right up until they are asked to walk through it, at which point the rating collapses. Self-explanation is also one of the best-attested ways to actually consolidate what you have just learned. So the intervention is not “use AI less.” It is “before this work moves forward, explain it in your own words, and keep the record.”
That is what I built Ninchi to do, and it is deliberately boring. A developer opens a pull request. Ninchi reads the diff, asks a question about it, and the developer answers in plain prose. The answer is scored against a rubric and stored. If the team wants, a failing answer blocks the merge. That’s it. The whole intervention takes a couple of minutes per PR, which is far less time than the AI saved you.
What I did not fully anticipate when I built it is that this turns the off problem inside out. The same act that verifies understanding is the act that creates it. A developer who delegates a feature to Claude and then has to explain the retry logic and the failure mode has just done the exact cognitive work the Anthropic study found missing. They keep the speed. They keep the learning. And the organization gets something it has never had before: a record of who understood what, when, instead of a green checkmark and a hope.
I’ve started thinking of this as learning velocity rather than governance, because governance sounds like paperwork and this is the opposite of paperwork. Kahneman’s fast, intuitive System 1 is what an LLM is very good at replacing. Slow, effortful System 2 is what it quietly lets you skip. The goal is not to slow down. It is to make sure the fast tool keeps feeding the slow mind, so that the human at the keyboard is getting stronger with every merge rather than weaker. Iron Man’s suit is the right picture, and I keep coming back to it. The suit is not the problem. The problem is a pilot who has stopped understanding how it flies.
I don’t know yet whether a couple of questions per pull request is enough to bend the curve. The early numbers from developers using Ninchi are encouraging, and I’ll write about them properly when there are enough of them to mean something. For now I will settle for this: the bill for cognitive off is real, it is measurable, and it is coming due faster than anyone expected. We should probably start paying it in small installments now.