You ship a feature in an afternoon. The AI did most of the work. Tests pass. PR merged. Beautiful.
Three weeks later, a bug report comes in. You open the file. You scroll. And there’s a small, panicky pause where you think: what does this actually do again?
That feeling has a name now. It’s called cognitive debt, and a growing pile of research suggests it’s quietly becoming the most important kind of debt to worry about in 2026.
What is cognitive debt, actually? #
The term was popularized by a June 2025 MIT Media Lab study led by Nataliya Kosmyna. The researchers put 54 participants through four months of essay-writing sessions, split into three groups: people using ChatGPT, people using search engines, and people writing with no tools at all. They measured brain activity with EEG along the way.
The LLM group did fine on the essays themselves. But their brains showed the weakest neural connectivity. They struggled to remember what they’d written. They felt the least ownership over their own work. The researchers coined “cognitive debt” to describe what was happening — a short-term boost in output that trades against deeper understanding, memory, and the mental scaffolding you need to think well later.
It’s a sticky term, and it’s now jumping from the lab into the software industry.
From essays to engineering teams #
In February 2026, Margaret-Anne Storey — a computer science professor at the University of Victoria and Canada Research Chair in Human and Social Aspects of Software Engineering — extended cognitive debt into how we build software with AI agents. Her framing is sharp: technical debt lives in the code, but cognitive debt lives in the heads of the developers.
She tells a story from an entrepreneurship class she taught. A student team was moving fast, shipping features, hitting milestones. By weeks seven or eight, they hit a wall. Every change broke something else. Their first instinct was to blame the code — messy architecture, hurried implementations, the usual suspects. But when Storey actually dug in with them, the real problem was different: nobody on the team could explain why certain design decisions had been made. The system had become a stranger to its own builders. As Storey puts it, “they had accumulated cognitive debt faster than technical debt, and it paralyzed them.”
If you’ve ever vibe-coded a project past a certain size, this probably sounds uncomfortably familiar. You can feel the moment your mental model of a system goes blurry. Features still get added. But the confidence to make bold changes quietly evaporates, because you’re no longer sure what you’ll break.
Why this is different from technical debt #
It’s tempting to file cognitive debt under “just another flavor of tech debt.” But Martin Fowler picked at this distinction recently, and the difference matters.
Technical debt usually refers to messy code — bad module boundaries, awkward naming, rushed implementations. The interest shows up as friction every time someone touches that part of the codebase. You can refactor your way out of it, given time and discipline.
Cognitive debt is closer to ignorance — both of the code and the domain it lives in. The fix isn’t a refactor. It’s the slower, less glamorous work of rebuilding shared understanding. Reading. Questioning. Writing things down. Pairing. Asking the dumb question in the standup until everyone actually agrees on what a piece of the system does.
Storey leans on a classic Peter Naur paper here — Programming as Theory Building, from 1985 — which argued that a program is more than its source code. It’s a theory in the minds of the people who built it. You can lose the source code and reconstruct it from the theory. Lose the theory, and the source code starts to look like ancient ruins.
That’s the version of debt worth being nervous about.
How AI quietly accelerates the slide #
Here’s the awkward part. AI coding tools are genuinely fantastic. They let one person do the work of three. They let founders ship MVPs in days instead of months. We’re not anti-AI at all — these tools are woven into how we work.
But the same tools that compress work also compress learning. When you ask an agent to “add OAuth,” you skip the entire process of figuring out how OAuth works in your stack. You skip the small architectural decisions that, on the slow path, would have lodged themselves into your head as a kind of muscle memory.
A few changes in, the codebase contains decisions you didn’t make and don’t fully understand. Multiply that across a team, and you land where Storey’s students did: a codebase nobody really owns, that nobody is confident touching.
Signs you’re racking it up #
Cognitive debt doesn’t crash your build. It shows up in softer signals:
- People hesitate before making changes, even small ones, because they’re not sure what might break.
- One or two people have become the only ones who “get” how a part of the system works.
- The team starts treating chunks of the codebase like a black box — useful, but untouchable.
- Code reviews feel rubber-stampy because nobody has the context to push back meaningfully.
- “Why did we build it this way?” gets met with shrugs.
Three or more of those feel familiar? You’ve probably been accumulating cognitive debt for a while.
Paying it down #
No silver bullet here, but a handful of habits do real work:
- One human, full understanding, per AI-generated change. Before a PR ships, at least one person on the team should be able to explain not just what the code does but why it’s written that way. If nobody can, the PR isn’t ready, no matter how green the tests are.
- Document the why, not just the what. Decision records, short design notes, even Slack threads pinned somewhere findable. The artifact matters less than the act of writing the reasoning down while it’s still fresh.
- Slow down for the hard changes. Kent Beck’s principle — make the change easy, then make the easy change — is doing more work than ever right now. Resisting the urge to one-shot a complex change is often the difference between a healthy codebase and a haunted one.
- Schedule understanding-rebuilding sessions. Walkthroughs where someone explains a part of the system out loud. Pairing sessions. Architecture retros. These look like overhead. They’re not.
- Be honest about what your agents did. If you don’t fully understand a piece of AI-generated code, that’s data. Flag it. Come back to it. Don’t pretend you wrote it.
The pattern worth noticing #
Most products being built today lean on AI tooling somewhere in the stack, and there’s no real reason to be nostalgic about pre-LLM development — those days had their own debts and they weren’t fun either. But the projects that age well, the ones still easy to evolve six and twelve months in, tend to have one thing in common. The teams behind them protect their shared understanding like it’s load-bearing. Because it is.
Cognitive debt is the kind of bill that doesn’t arrive until the system is too far along to easily fix. The good news is it’s preventable. The price is paying a little attention now — slower PRs, written-down reasoning, and the unglamorous work of making sure the theory of your system lives somewhere other than the model that wrote it.
Ship fast. Just make sure someone on the team still knows what they shipped.