Cognitive debt is not a new form of technical debt. It's a distinct category.
Technical debt is code that works but is hard to maintain. You can measure it. You can schedule the refactor. It's a resourcing problem.
Cognitive debt is code that works — and that your team no longer fully understands. You can't schedule that refactor because you don't know what you'd be fixing. It's a knowledge problem.
Thoughtworks defined it precisely: developers shipping code they didn't write, can't explain, and can't safely extend. Their recommendation in Vol 34 is a return to engineering fundamentals — not as nostalgia, but as risk mitigation.
The risk escalates significantly in regulated environments.
MIT Tech Review and Veracode found 45-48% of AI-generated code contains OWASP Top 10 vulnerabilities. Under the EU AI Act Phase 2 and GDPR — the operating environment for most DACH enterprises — systems built on AI-generated code that developers can't fully audit are not just technically risky. They are governance failures.
A DPIA conducted on a system whose developers can't explain its logic is not a valid DPIA.
Sonar framed the dynamic sharply: "AI externalizes cognitive load but internalizes debt." You feel lighter. The system gets heavier.
The naming matters. "Cognitive debt" gives your team a term for a risk that previously had no shared language. Named risks are manageable. Unnamed risks accumulate silently.
I read Vol 34 the week it dropped. The cognitive-debt entry is the cleanest articulation I've seen of something most teams have been feeling for a year without the language for it. The previous three posts in this series traced the same shape from productivity, code quality, and economics. Thoughtworks just gave it the institutional label.
Is "cognitive debt" already part of your team's vocabulary? If not — what term are you using for code your team ships but can't fully audit?