Cognitive Debt

Writing code and understanding code used to be a joint product. You could not get much of the first without accumulating the second, so nobody had to decide how much understanding to buy. It arrived as a by-product.

AI unbundled them. That is the whole of what changed.

Technical debt was Ward Cunningham’s term and it never meant sloppy code. It meant shipping on an incomplete understanding, deliberately, because shipping now is worth more than the interest you will pay later. That is a financing decision, not a character flaw, and the terms that matter are the rate, the maturity, and whether you can roll it over.

On those terms AI is good news. Servicing technical debt is an order of magnitude cheaper than it was: renaming across a repository, backfilling the tests I skipped, porting a script from R to Python. Work that was never worth a week is now worth an afternoon. Refactoring got cheap, so the efficient level of technical debt went up, not down.

Cognitive debt is the liability on the other side of the same transaction the understanding you did not buy because the code arrived without it. The term comes from an MIT preprint.

You pay nothing in the states where the tool works and nobody asks. You pay in full in the states where it fails, or where someone asks you to defend the thing.

In teaching — and this is where I am least sure — students can produce working code without understanding the model underneath, and the model is what the course is teaching. Prohibition is unenforceable and, given the labor market, it is bad advice.

So what I emphasize in class is the part that did not unbundle. Until the models are accurate enough that the risk is thin enough to ignore — which is not where we are — the cognitive debt stays with the human, and so does the responsibility that comes with it.

When an execution of the work doesn’t need human intervention, what leaves to human is the “intention” and “responsibility”.