What is technical debt?

Technical debt is the metaphor coined by Ward Cunningham in 1992: every shortcut taken in the code is a loan. It lets you ship sooner today, but from tomorrow you pay interest: every change takes longer, every bug is harder to isolate, every new feature collides with yesterday's shortcuts. Like real loans, technical debt is not a mistake in itself: it is an instrument. The problem is taking it on without knowing, or never paying it back. The most useful distinction, popularized by Martin Fowler, separates debt taken on knowingly from debt accumulated through haste or inexperience: in the first case you know what still needs fixing, in the second nobody notices until the symptoms become visible, estimates that double, releases that get rarer. The phenomenon touches a large share of the Italian corporate landscape, with a significant portion of companies' application estates in need of genuine modernization.

Deliberate debt and accidental debt

The honest distinction, popularized by Martin Fowler, is between deliberate and accidental debt. The first is a conscious choice: "we ship it like this to hit the deadline, knowing what to fix later". Documented and with a repayment plan, it is a legitimate management tool. The second is the dangerous one: born of inexperience, haste or plain entropy, with nobody remembering having taken it on. It shows up on no balance sheet, but the symptoms are visible: estimates that double, releases that get rarer, the module nobody wants to touch. At the scale of a national IT estate the phenomenon is anything but theoretical: according to a Politecnico di Milano survey reported by ZeroUno, around 39% of Italian companies' application estate is in need of modernization.

AI as the new debt factory (and how you repay the principal)

Vibe coding has added a brand new channel: code generated in minutes, working in the demo but genuinely understood by nobody in the company. It is pure accidental debt, taken on at generation speed rather than human writing speed: borrowing has never been this easy. The answer is not banning AI, it is telling the two ways of paying apart. Paying interest means living with it: workarounds, patches, meetings about "why does this take three months". Repaying the principal means modernizing: rewriting the critical parts, covering them with tests, automating releases and checks, documenting what today lives in one person's head. It is exactly the kind of work described under Software Rescue: first you measure the debt, then you decide, item by item, what to pay off and what to keep servicing. The cheapest prevention is still writing down why a choice was made while you are making it, that is, keeping an architecture decision record: much of the debt comes not from shortcuts but from forgotten constraints.