Technical Debt vs Cognitive Debt

We spent 20 years building tools to detect technical debt. Linters. Static analysis. SonarQube. Complexity metrics.

But AI coding created a new kind of debt these tools weren't designed to catch.

Margaret-Anne Storey formalized the concept of Cognitive Debt in the context of AI-assisted engineering and the distinction matters:

→ Technical debt: you KNOW the code is bad. You chose to ship anyway. It's a conscious tradeoff.

→ Cognitive debt: the code is fine. Tests pass. Builds are green. SonarQube says complexity is low. But nobody on the team actually understands why it works.

We have tools that measure code quality. We have nothing that measures whether your team understands the code they shipped.

Technical debt announces itself : failing tests, slow builds, bugs. You can measure it, you can prioritize it, you can pay it down.

Cognitive debt stays silent until you need to change, or extend a module. Then you discover nobody has the mental model anymore.

Quick audit for your next retro, just 5 questions:

1. Can anyone explain how this module works without re-reading it? 2. Could you debug this at 2am without asking an AI? 3. Do you understand WHY this implementation was chosen over alternatives? 4. Could a new hire onboard from this codebase alone? 5. If your AI tool disappeared tomorrow, could you maintain this?

If you answered "no" to more than 3, you have cognitive debt.

The faster AI makes you ship, the faster cognitive debt compounds. And unlike technical debt, there's no linter that catches "the team doesn't understand their own system."

Peter Naur wrote decades ago that a program is a theory living in developers' minds. AI is producing code without transferring the theory.