Cognitive Debt - When Velocity Exceeds Comprehension
Summary
Cognitive debt is the gap between how fast AI lets you produce code and how fast a human can actually understand it. Writing and absorbing used to be the same act. You typed it, so you thought about it. AI splits them apart. Now the code ships, the tests pass, the dashboards are green, and nobody in the room genuinely understands what’s running in production. The bill doesn’t arrive today. It arrives later, as slower recovery times, architecture that turns brittle when you touch it, and tacit knowledge that never got built in the first place.
Key Concepts
- Comprehension lag: The delay between code existing and you actually understanding it. Typing it out forced engagement whether you liked it or not. Remove that friction and understanding becomes the bottleneck, capped at human speed.
- Production decoupled from absorption: Characters landing in a file no longer means a mental model is forming. Those used to be the same event.
- The reviewer’s dilemma: A junior generates code faster than a senior can properly read it. So the reviewer picks: be the bottleneck, or approve code they don’t fully follow. Most quietly pick the second.
- Cognitive disconnection: Burnout with a specific shape: high output, low confidence. You’re a stranger to your own work.
- Tacit vs. explicit knowledge: The intuition and judgment that used to accumulate while you implemented something isn’t accumulating anymore. All that’s left is documentation, and docs never capture the nuance.
- The measurement problem: Orgs optimise what they can see: velocity, story points, commits. There’s no metric for “do you actually understand this?”, so the incentive quietly rewards accumulating debt.
Main Takeaways
- Code is now cheap to produce and still expensive to understand. AI made the writing nearly free. The understanding is still a fixed human cost, and nothing has driven that cost down.
- The debt is invisible and it compounds. Unlike technical debt it doesn’t break anything today. It’s a lagging indicator. It surfaces months later, mid-migration or at 3am during an incident.
- Black box debugging a black box. On-call ends up doing forensics on a simple fix because nobody understands the logic underneath. That’s the future being built by default.
- Seniors don’t grow from nothing. The friction of doing it by hand is exactly where the scar tissue and intuition come from. Skip it and you get fast developers who never turn into architects.
- Old code stops being trustworthy. Normally you trust old code because it survived production. Flip it: AI-era old code is more dangerous, because the humans who watched it get generated have long since paged that context out of their heads.
- The incentives point the wrong way. Systems reward throughput. The engineer who stops to genuinely understand their work looks slower than the one who just ships, even when the fast one is the one quietly loading the org with risk.
Personal Reflections & Questions
Worth thinking about
- I’ve felt this. Code works, tests green, and I couldn’t confidently explain half of it. So where’s my line for “understood enough to move on”, and is that line honest, or just convenient?
- If the friction is where intuition gets built, and AI removes the friction, how does the next generation ever become senior? Or do we just… stop producing architects?
- Orgs measure PRs and story points because those are easy to count. What would a “comprehension depth” metric even look like, and could you game it the moment it existed?
- Willison’s agentic patterns lean hard into AI doing the implementation. Do things like linear walkthroughs and red/green TDD actually pay this debt down, or are they just a nicer way to keep borrowing? Maybe the debt is simply the price of the speed and we pay it either way.
📇 Additional Metadata
- 🗂 Type:: note
- 🏷️ Tags:: software-engineering ai
- 📡 Status:: #status/🌱