Cognitive debt: when your team no longer understands its AI-written code

Picture this: on a Friday afternoon a payment integration fails. The logs point to a module that an AI assistant wrote most of three months ago. The code is clean, the tests were green, the review was approved. But nobody on the team can explain why the retry logic is built the way it is. What should have been an hour's fix turns into an afternoon of reverse-engineering your own system.

Since early 2026 that gap has had a name: cognitive debt.

What is cognitive debt?

Cognitive debt is the growing gap between how a system is built and how well the team understands how and why it works that way. The software runs, but nobody can confidently explain why, or predict what a change will do.

The term in this sense comes from Margaret-Anne Storey, a computer science professor at the University of Victoria who studies how developers understand complex systems. In February 2026 she described student teams in an entrepreneurship course that shipped features quickly with AI. Around week seven or eight, one team hit a wall: small changes broke something unexpected elsewhere. The cause was not messy code, she wrote, but that nobody could explain why certain design decisions had been made or how the parts were supposed to work together.

The phrase had turned up before, in a June 2025 MIT Media Lab study titled Your Brain on ChatGPT. That study was about writing essays, not code. Participants who used ChatGPT showed the weakest brain connectivity in EEG measurements, felt the least ownership of their essays and struggled to quote from them. The mechanism is the same: outsourcing the work saves effort now, and the bill arrives later.

Why technical debt is the wrong comparison

Technical debt lives in the code: duplication, a temporary hack, an abstraction that no longer fits. You can see it. Linters, reviews and static analysis point it out. Storey sums up the difference like this: technical debt lives in the code, cognitive debt lives in people.

That is why code with a lot of cognitive debt can look perfect. AI often produces clean, consistent code. No tool raises an alarm, because technically nothing is wrong. The problem is that nobody owns the design anymore.

The productivity illusion

Developing with AI feels fast. Pull requests keep coming, the sprint numbers look good. But feeling and measurement demonstrably diverge here. In a randomised study by the research organisation METR (early 2025), experienced open-source developers estimated afterwards that AI had made them 20% faster. Measured, they were 19% slower.

That does not prove AI slows you down. In February 2026 METR itself wrote that a follow-up measurement is hard to interpret, because many developers no longer wanted to work without AI. What the study does show is that your own sense of speed is a poor yardstick. Cognitive debt makes that more dangerous: you see the speed immediately, and the cost only at the first serious incident.

How do you notice your team building up cognitive debt?

There is no meter for it. There are signals that follow logically from the definition:

• Incidents take longer. Not because the bug is harder, but because someone first has to work out what the code actually does. Your mean time to recovery (MTTR) goes up while code quality on paper stays the same.
• The paste-and-hope loop. The code fails, the error goes into the AI, the suggested fix goes in, a new error appears. That is not the AI's fault; it is a lack of context to judge whether a fix addresses the cause or only the symptom.
• Small changes, big side effects. Exactly what Storey's team ran into around week seven. At some point a rewrite feels like the only way out.
• "Just ask the AI" as the default answer to questions about your own system.

Why juniors are most at risk

You learn programming by struggling: reading a stack trace, following an execution path, finding the bug yourself. When AI takes over those steps, you learn less than you think.

There is research on this now. In January 2026 Anthropic ran a randomised study in which 52 mostly junior developers learned a Python library that was new to them (Trio), with and without AI help. Right afterwards, the AI group averaged 50% on a comprehension quiz, the group without AI 67%. The AI group finished about two minutes faster, a difference that was not statistically significant. The biggest gap was on the debugging questions: exactly the skill you need when something breaks.

The most interesting part is in the details. Those who let AI do everything scored lowest. Those who mainly asked AI conceptual questions, or had it generate code and then asked for explanations, scored well. Same tool; how it was used decided whether anything stuck.

You notice the difference the moment there is no assistant beside you, for example in a technical job interview where you have to explain a trade-off or defend an architectural choice.

How do you prevent cognitive debt?

Dropping AI is not a serious option. The question is how you use it. Storey suggests, among other things, that at least one team member fully understands every AI-generated change before it ships, that you record why something changed and not just what, and that you make deliberate time in reviews and retrospectives to keep shared understanding up to date. On top of that, three concrete habits.

Review like a junior

In a normal review you ask: does it work, and does it meet our standards? With AI-written code, one question is added: do I understand it? Three checks before you accept anything:

1. Can I explain this code to a colleague?
2. Do I understand why this design was chosen, and not another?
3. Could I debug this at 3 a.m. without AI?

One "no" means: not done yet.

Take fifteen minutes

If a piece of generated code is not immediately clear, deliberately take fifteen minutes to understand it. That is a rule of thumb, not a measured optimum. But fifteen minutes now is cheaper than an afternoon during an incident. The rule underneath: if you can't explain it, you don't own it.

Let AI explain, not just build

Ask why a pattern was chosen, which edge cases exist, what it costs in performance and which alternatives there were. That is the kind of use that produced the highest scores in Anthropic's study.

Speed without understanding is borrowed time. The teams in good shape a few years from now will not be the ones generating the most code. They will be the ones that still understand their system better than the model that helped write it.

Sources

• Margaret-Anne Storey: Cognitive Debt (9 February 2026)
• Margaret-Anne Storey: What I'm Hearing About Cognitive Debt (So Far) (18 February 2026)
• MIT Media Lab: Your Brain on ChatGPT (June 2025)
• Anthropic: How AI assistance impacts the formation of coding skills (January 2026)
• METR: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity
• METR: We are Changing our Developer Productivity Experiment Design (February 2026)