Every application contains shortcuts. A screen copied rather than factored, a test put off until later, a rule written for the demo. Each one saves time in the moment. Technical debt is the sum of those time savings that will have to be paid back, with interest, every time you want to change the software.
Where the term comes from
Ward Cunningham, a developer and later a co-author of the Agile Manifesto, proposed the metaphor in 1992 to explain to his management why a piece of financial software needed rework. He wrote that "shipping first time code is like going into debt" and that "every minute spent on not-quite-right code counts as interest on that debt".
The metaphor stuck because it speaks to decision-makers. A debt is neither good nor bad. It finances a head start. It becomes a problem when its interest swallows the capacity to move forward.
What debt looks like in an AI-built app
Vibe coding produces debt in a particular way. Each request to the tool adds or changes code to satisfy the request of the moment, without always considering the whole. After a few hundred iterations, the same signs often appear:
- Duplicated components with small variations, which must be fixed in several places
- Business logic scattered between the interface, the database and server functions, with no single place to read a rule
- Few or no automated tests, so no warning when a change breaks something else
- Dead code: files and functions that are no longer used but that nobody dares delete
- Dependencies added then forgotten, sometimes duplicated or outdated
- No documentation of the architecture or the choices made
The most telling symptom is familiar to many founders: every new request to the AI breaks something that used to work. That is the moment when the interest on the debt outweighs the speed gain.
How to measure it
Technical debt is measured through observable signs in the repository:
- Structure: are files organised by responsibility? Does a business rule live in a single place?
- Readability: can an outside developer understand a module without a line-by-line explanation?
- Checks: are there tests, type checking, automated analysis on every change?
- Handover: does the project start on another machine with simple documentation?
- Evolution: are dependencies up to date and is the database schema versioned?
That is exactly the grid of the vibebusters Takeover Index: ten criteria scored 0, 1 or 2, grouped into five axes, for a total out of 20. Each score rests on evidence in the code, which makes it possible to track a repository over time.
A concrete example
A training platform built with Lovable has forty screens. The founder asks for an annual subscription. The tool changes the price in three places, but the invoice calculation exists in five slightly different copies. Two are missed. Customers receive a monthly invoice for an annual subscription.
The analysis shows the debt concentrated in four areas: billing, access rights, notifications and dashboards. Paying back the first two, with tests on the calculations, takes two weeks. The other two can wait. The project moves on without a rebuild.
Paying it back, and in what order
Debt is not paid back in one go. A reasonable order:
- First, anything touching security and data: access, secrets, backups
- Next, whatever slows down the product's next changes
- Then whatever costs time on every change: duplication, missing tests on critical calculations
- Finally, comfort: naming, tidying, detailed documentation
Our article on the cost of taking a prototype to production gives orders of magnitude. When the debt is too diffuse to be paid back piece by piece, a step-by-step Rebuild carries the useful features and data over to a sound foundation.
The takeaway
Technical debt is a way of financing the product. It lets you launch fast, and vibe coding makes it especially profitable at the start. It then needs to be measured and paid back by priority, before its interest blocks progress. The Scan and the Takeover Index provide that measurement, with evidence.