The Real Cost of AI-Generated Technical Debt

Technical debt has always been a reasonable trade. You take a shortcut, you ship sooner, you pay interest later. The critical part of that arrangement is that somebody chose it — and can tell you what they chose, and why, and what it would take to undo.

AI-generated debt breaks that arrangement in a way most cost discussions miss. The problem usually isn't that the code is bad. Often it's fine. The problem is that nobody made a decision, so nobody has a mental model of the system.

That's the expensive part, and it doesn't show up in a code-quality score.

Debt with no debtor

Ask an engineer about a shortcut they took and you get an answer in ten seconds: "It only handles one currency, we knew, there's a ticket." That knowledge is what makes normal debt manageable — you can locate it, price it, and schedule it.

Now ask the same question about a generated codebase. Nobody remembers, because nobody decided. There's no ticket, no comment, no rationale. Finding out what the system assumes means reading it and inferring.

So the first real cost is archaeology: every change begins with an investigation that wouldn't have been necessary if a person had written it. On a small codebase that's an hour. On a year-old one, it's most of the estimate.

How it shows up on your invoice

Not as a line item called "debt." It arrives disguised as ordinary work getting slower:

• Estimates inflate for no visible reason. A change that sounds like two days comes back as a week, because the developer has to first establish what will break.
• Small changes cause distant failures. Duplicated logic means a fix in one place leaves the same bug alive in two others.
• Onboarding stalls. A new developer who would normally be productive in a week takes a month, because there's nobody to ask.
• Everything becomes a rewrite conversation. When nobody understands the system, "start over" starts to sound cheaper than it is.

The tell is a widening gap between how hard a feature sounds and what it costs. If that gap has grown over six months while the team stayed the same, you're paying interest.

Measuring it without a big audit

Three questions, answerable this week:

1. How long to answer "where does X happen?" Pick a core behaviour — how a refund is issued, say. If nobody can point to the code in a few minutes, the system isn't understood.
2. What share of changes cause a regression? If more than roughly one in five fixes breaks something else, the coupling is real and expensive.
3. How long until a new developer ships something meaningful? Weeks instead of days means the knowledge isn't in the codebase.

None require tooling. All three are better signals than any static-analysis number.

The interest rate varies enormously

This is where most advice goes wrong: it treats all debt as equally urgent. It isn't. Interest depends on how often you touch the code.

• Code you change weekly, with debt in it, is charging you every week.
• Code you haven't opened in eight months is charging you nothing. Leave it alone.

So the question is never "is this codebase clean?" It's which parts do we keep returning to, and what do they cost us each time? Pay down the intersection of high-traffic and high-friction. Ignore the rest, however untidy.

Two exceptions override that rule, because their cost isn't proportional to how often you touch them:

• Security defects — priced at the worst case, not the frequency. Worth a proper audit regardless.
• Data-model problems — they get more expensive every day you add rows, and unlike most debt they compound whether you touch the code or not.

When paying it down is the wrong move

Consciously carrying debt is sometimes correct:

• The product may not survive. Refactoring code for a feature that gets cut in two months is pure waste. Pre-product-market-fit, messy and learning beats clean and slow.
• The area is about to be replaced. Don't renovate a room you're demolishing.
• It genuinely isn't costing anything. Ugly code that works, that nobody touches, and that isn't a security or data problem, is not a priority. It's an aesthetic complaint.

The goal was never a beautiful codebase. It's a codebase that doesn't tax the work you're actually doing.

Rewrite or repair?

The instinct after discovering all this is to start over. That's usually the expensive mistake — a rewrite means months with no new features, and you'll reproduce bugs you'd already fixed.

Rewrite when the data model is fundamentally wrong for what the product became, or when core flows are duplicated with different logic in each copy. Otherwise repair, incrementally, starting with what you touch most. We set out that decision in full in taking an AI-built prototype to production.

The most useful question isn't "how bad is this code?" It's "what did we fail to write down?" Most AI debt is missing knowledge wearing the costume of missing quality.

The practical fix is often documentation and tests rather than rewriting: capture what the system assumes, so the next change starts from understanding instead of archaeology. That's cheaper than a refactor and fixes more of the actual problem.

If you'd like an honest read on what your codebase is costing you — and what's genuinely worth paying down — that's work we do. See how we approach AI-powered applications, or send us the repo.