What technical debt is
It is the gap between what exists and what it would take to keep it maintainable. Copy and paste instead of a function, the test never written, the old version of a dependency, the name that no longer says what it does. Every shortcut is paid later, in hours of whoever comes next.
Not all debt is bad. Debt taken knowingly and written down gets repaid; debt nobody wrote down is discovered the day something breaks and nobody knows why.
Types of technical debt
The most cited classification is Martin Fowler's, which crosses two questions: was the debt taken knowingly or without noticing, and was it prudent or reckless. Deliberate and prudent debt is a shortcut written down to be repaid; inadvertent and reckless debt is what appears when nobody knew there was another way to do it.
By where it lives, it shows in the code (duplication, huge functions), in the architecture (parts that depend on each other too much), in missing tests, in old dependencies, in documentation and in infrastructure, like the server nobody knows how to rebuild.
Examples of technical debt
The same business rule copied in three places, changed in two and forgotten in the third. A library with a known vulnerability that stays unpatched because updating it breaks something. A query that runs fine with a thousand rows and takes seconds with a million. A password written in the code because it was only a test.
And the most expensive one, the one you cannot see: a process that fails without telling anyone and leaves data half written. It is reduced like any debt: measure it first, repay what carries the most interest, and stop taking new debt without writing it down.
Why it grows faster with AI
AI writes a lot of code in little time, and that code arrives without the context of why it is the way it is. What already existed gets duplicated, different patterns appear for the same thing, and dependencies nobody chose get added. In a lab, 45% of AI-generated code carried known vulnerabilities when given no security instructions.
The effect does not show in the first week: it shows when something has to change and every change touches five places.
How it is measured and where to start
It is measured with the code in front of you: duplication, dependencies that are out of date and carry known vulnerabilities, tests that do not exist, unprotected routes, queries that do not hold the real volume and places where the system fails without telling anyone. Each with its evidence, not with an opinion.
And it is ordered by what it costs if it breaks, not by what annoys the reader. We hand over that list and the order; repair is a second tier: your team applies it, or we do it if you hire us for that.