Technical debt is the future cost baked into short-term choices in software development. Like a financial debt, a shortcut in the code speeds up delivery today but charges "interest" later in the form of bugs, rework and slowness to change the system. The term was coined by Ward Cunningham, one of the authors of the Agile Manifesto.
Not all debt is bad
Taking on technical debt consciously can be strategic: shipping fast to validate a hypothesis and refactoring later is a legitimate trade-off. The problem is invisible, accumulated debt, the kind no one recorded, which turns every new feature into a minefield.
How to control it
The first step is to measure: test coverage, complexity, duplication and the areas of code where bugs cluster. With that, you decide what to refactor, what to rewrite and what to just monitor. A technical diagnosis turns debt from a diffuse fear into a plan with priority and cost.