Intent Debt

When someone develops a program, there is an intent at the start. Someone wants to solve a problem, such as automatically sending out invoices. From this intent, decisions arise, and from these decisions, finished program code emerges. Intent Debt is the part of this intent that gets lost along the way. The program then still runs, but nobody can say anymore why it was built exactly this way. The word Debt means exactly that: as with a loan, you pay for it later, and you pay in time and frustration.

When nobody knows anymore why the code looks the way it does

Software is rarely written once and then never touched again. It gets changed, extended, and repaired for years. In the process, the same question keeps coming up: Am I allowed to change this, or did someone have a specific reason for doing it this way? Without a recorded intent, this question cannot be answered. So developers prefer to leave everything as it is, including superfluous parts.

This costs real money. Teams work more slowly because they have to feel their way through code that nobody understands anymore. A well-known pattern: a function seems pointless, gets removed, and three weeks later another part of the system fails. It did have a purpose after all, only nobody remembered it anymore.

A related, older term is technical debt. That refers to sloppily built code that later needs to be cleaned up. Intent Debt is something different: the code can be clean, it’s just the knowledge of its why that’s missing. You can’t see the debt just by looking at the program, and that is exactly what makes it dangerous.

How the gap between intent and code arises

Intent gets lost in small steps. A requirement is mentioned verbally in a meeting and never written down. A compromise is negotiated in a chat that gets deleted a year later. A special rule is built in because a single customer needed it, but the reason ends up nowhere. In the end, only the result remains, not the reasoning behind it.

AI assistants that write code accelerate this loss. You describe what you want in a single sentence and receive a hundred lines of finished code in return. The sentence then disappears into the chat history. The code remains and gets published. The ratio flips: in the past, a human read every line, today they often only check whether it runs.

There are countermeasures. Teams write short notes on important decisions, often called Architecture Decision Records. These state what was decided, what alternatives existed, and why they were discarded. Tests help too: a good test describes, in the form of an example, what behavior is intended. That is intent in a form the computer itself can verify.

Where the term is currently showing up

Intent Debt is mainly read about in debates on AI-assisted programming. When companies report that a growing share of their code comes from machines, the counter-question about maintainability almost always follows. The term also comes up regularly around so-called vibe coding, the loose practice of building software solely by giving instructions to an AI.

For investors, this is not a marginal topic. At many companies, software is the largest asset, and poorly understood software becomes more expensive over time rather than cheaper. Anyone who wants to judge whether AI tools genuinely benefit a company must weigh the writing time saved against the repair time that will be due later.

On a small scale, you encounter this principle outside computer science too. Think of a formula sheet you copied for an exam without understanding the derivation. In the short term, that works. As soon as a question is phrased slightly differently, you’re missing exactly the knowledge you skipped. Intent Debt is the same calculation, just spread over years and with a price tag attached.