Tell HN: We need an accounting system for cognitive debt

mikaelaast1 pts0 comments

The term “cognitive debt” is gaining ground [1]. We can now produce code faster than we can understand it. The bottleneck is real, and so is the feeling of being choked. The situation is not new. We have always had code no one quite dares to touch. Agentic coding makes it much worse. You probably know the feeling. Everything can look fine. The code compiles. The tests are green. The pull request looks reasonable. The diff gives off a vague “probably fine” vibe. But does anyone actually understand what was added? Congratulations: you have taken on cognitive debt.Programming is about building knowledge. That used to be simpler. Until recently, the code itself was proof of understanding. That era is over. Now understanding has to be traced to something far more elusive: human mental models. Those are harder to track. I have previously described a kind of “mind palace”: an abstract model of a system where I can wander around, open and close doors, knock down a wall, add a new wing, and feel what connects to what. That mental model is what lets me change code with confidence. It is what lets me smell that something is wrong before I have proved it. When that model is missing, things grind to a halt. Trust disappears. Changes become painful. Fear of touching anything grows. You become a tourist in your own codebase.How much of your codebase is backed by human mental models? The burden of proof is on you, you trigger-happy, agent-pilled developer. I think we need an “accounting system” for cognitive debt. A system that can answer simple but uncomfortable questions: Who understands this code? At what level? Who can verify that understanding? This ledger should be reconciled continuously. Everything is cognitive debt until proven otherwise. The clock is ticking.I imagine microcertification: small certificates tied to concrete code. A file, folder, or module. The certificate says: “Mikael has demonstrated understanding of this area, at this level, verified by this authority.” It should live alongside the code.Not everyone needs the same model. That would be impossible. Different roles need different mental models. An implementer needs to demonstrate low-level understanding, while a team lead may only need a high-level model. Both models can be reconciled on their own terms. The hard part is verification. How do you create “proof of understanding”? Verification has to be AI-resistant and rooted in something we trust: a domain expert, a tech lead, a reviewer, a pair-programming session. Anchoring it in the physical world is crucial. Think of it as code review, but for your mental model.Imagine an append-only ledger that follows the codebase. It logs when code is added, changed, or removed; when understanding is certified; and when changes invalidate old understanding. History, signatures, and traceability are the key ideas, so the repo can carry its own “comprehension state” with it. An IOU. What should the debt be measured in? I’m thinking lines of code. Before anyone calls me out: yes, LOC is a bad measure of productivity. I know. But here we are measuring understanding. If an agent spits out 2000 lines of code, we have not just gained 2000 lines of functionality. We have also gained 2000 lines that someone must understand, own, debug, and maintain. The incentives balance out: more lines mean more debt, so the agent should not generate arbitrary amounts of code. But if you force it into cryptic code golf just to keep line count down, human understanding gets more expensive to build.I worry we are neglecting our mental models, then pretending everything is fine. Agentic coding creates cognitive obligations; we need new processes to meet them. Every line of code should be recorded as cognitive debt until certified as part of a living human mental model. Yes, that is radical. But then, we are living in absolutely bananas times.[1] https://margaretstorey.com/blog/2026/02/09/cognitive-debt/

code understanding debt cognitive mental model

Related Articles