Cognitive Debt Is Overtaking Technical Debt
The durable product-builder skill is no longer maximizing code output. It is managing cognitive debt: the gap between how fast a team can generate changes and how fast it can still explain, verify, and safely maintain those changes.
The strongest August 12 signal came from Digg Tech and operator chatter clustering around Florian Herrengt’s argument that AI is not mainly removing implementation work but removing the old speed limit on bad decisions. The primary essay matters because it names the failure mode product teams are starting to feel but often mislabel as ordinary technical debt: features ship, tests may pass, and yet nobody can confidently explain where a behavior comes from or why a design choice exists. Simon Willison’s amplification is useful because it distills the operational smell into one question every builder should care about: when a bug appears, can the team explain the system without asking another model to narrate it back? The useful synthesis is that the scarce resource is no longer code production. It is retained system understanding.
Many teams are still measuring AI leverage with PR count, tickets closed, or lines changed. Those metrics can rise while actual throughput falls, because review, debugging, migration, and incident response do not scale with generation speed. Builders who protect comprehension will keep the compounding upside of AI. Builders who optimize for generated output alone will convert speed into operational drag and eventually into slower shipping.
Add a comprehension budget to one AI-heavy development workflow. Trigger: contributors regularly submit large agent-generated diffs, rely on chat transcripts as design history, or struggle to explain recent changes during incidents. Context: identify which parts of the system must remain locally understandable by the owning team and where generated complexity is already outpacing review capacity. Tools: cap diff size, require a short human-authored design note for architectural changes, force large agent runs to stop at reviewable checkpoints, and reject changes when the owner cannot explain data flow, failure modes, and rollback shape in plain language. Verifier: use code review plus one understanding check, such as a walkthrough, ownership handoff, or architecture quiz for the subsystem owner. Budget: set maximum lines changed, files touched, and unexplained abstractions per PR or agent run. Artifacts: preserve design notes, subsystem maps, rollback plans, and the final human explanation separate from the raw chat transcript. Stop condition: halt a run or reject a PR when the owner cannot explain the change, the rollback is unclear, or the diff exceeds the team’s review budget.
Pick the last big AI-generated change your team shipped and ask its owner to explain the full data path and rollback plan from memory. If that explanation is weak, the debt is cognitive before it is technical.
For disposable prototypes, isolated internal tools, or tightly scoped migrations with strong rollback, heavy comprehension gates may slow work more than they help.
Florian Herrengt’s August 11 essay provides a precise failure model grounded in day-to-day engineering work, and Simon Willison’s August 12 commentary reinforces that this is becoming a recognizable operator pattern rather than an isolated complaint.
Did adding comprehension budgets lower review overload and make post-merge incidents easier to explain and fix?
Watch: average diff size · review turnaround time · incident time-to-understand · PRs rejected for explanation gapsApply it now
Knowledge only counts when it changes the build.
Pick the last big AI-generated change your team shipped and ask its owner to explain the full data path and rollback plan from memory. If that explanation is weak, the debt is cognitive before it is technical.
- Stage
- build
- Produce
- Comprehension budget policy for one engineering workflow
Full context at Florian Herrengt. Bring back one decision, test, or workflow change.
Read the original ↗Keep Going