Technical debt
Why it matters
Debt that is taken on knowingly can be planned for. Debt that builds up unnoticed cannot. Each leftover shortcut makes the next change harder to predict, and a product can go from quick to fragile without anyone deciding it should.
Building with an AI coding agent raises the stakes. A model will produce a working feature in minutes, and just as quickly leave near-duplicate versions of the same logic side by side, or old code that nothing uses any more. The speed is real, and so is the clutter it can leave behind.
How to apply it
- Say out loud when debt is being taken on, and write down what paying it back will look like.
- Finish migrations. A database with old and new columns both live is debt that grows every day, because every query has to know which one to trust.
- Ask the agent to extend an existing pattern rather than create a second one next to it.
- Keep a visible list of known shortcuts, and review it on a fixed rhythm instead of only after something breaks.
- Pay debt down in small, regular pieces through refactoring, not in one rewrite that stalls everything else.
What it is
The phrase borrows from finance. Taking a shortcut is like borrowing money: the feature ships sooner, but interest is charged afterwards, paid in extra time on every later change. Software developer Ward Cunningham came up with the comparison in the early 1990s. Debt is not always a mistake. Borrowing on purpose to hit a launch date, and then repaying, is a normal trade.
A small example from running a business: a quote tool is built in a day by copying the invoice tool and changing a few lines. It works. Six months later a tax rate changes, and the same fix has to be made in two places. Someone forgets one, and the quotes are wrong.
Common mistakes
- Treating all debt as bad. A throwaway prototype does not need to be tidy.
- Never paying it back. A shortcut with no repayment plan is not a loan, it is a leak.