Quick Answer: AI technical debt is the backlog of old, poorly documented, or insecure code that AI tools now make cheaper to fix. Coding assistants can read unfamiliar systems, translate them into modern languages, and generate tests far faster than teams could before. That turns decades-old shortcuts from a permanent background cost into a project you can actually schedule. The payoff only works when humans supply specifications, tests, and careful review.
Ward Cunningham coined the term technical debt in 1992 to describe the cost of shipping imperfect code now and fixing it later. For most of the decades since, the debt just piled up. Teams knew the COBOL batch job was fragile and the old PHP form handler was overdue for patching, so they worked around it. Rewriting was expensive and risky, so living with the mess seemed cheaper. That math is changing, and AI technical debt is the part moving fastest. Here's what shifts, what doesn't, and where teams are getting burned.
Why Old Debt Stopped Being Cheap to Carry
Debt has interest, and the interest on legacy code compounds in two ways. The first is knowledge loss. When the engineer who understood a billing module retires, the code keeps running, but nobody can predict what breaks when it changes. Every edit gets slower and more nervous. The second is security exposure. A single old dependency can turn into an enterprise-wide emergency. Log4Shell (CVE-2021-44228), disclosed in late 2021, showed how a logging library buried deep in thousands of systems could force organizations to hunt for vulnerable components they didn't know they had.
So the real cost of debt isn't the ugly code. It's the unknown surface area around it. Start there, because you can't pay down what you can't see.
What AI Actually Changes (and What It Doesn't)
AI changes the cost of comprehension and translation more than anything else. Tasks that used to take a senior engineer weeks of archaeology can now be started in an afternoon. In practice, AI helps most with three things:
- Explaining undocumented functions and tracing call paths through unfamiliar files.
- Drafting translations from one language or framework to another, in small slices.
- Generating first-pass unit tests for functions that have none.
What AI doesn't change is the decision about what the system is supposed to do. A model can translate a COBOL paragraph into Java. It can't tell you whether the business rule in that paragraph is still correct, or whether a regulator still expects it. That judgment stays with people who know the domain. Here's the trap: the tool's output looks finished, so reviewers relax exactly when they should be most skeptical.
The Counter-Intuitive Part: Tests Matter More, Not Less
The popular advice goes like this: AI writes the code, so you can skip the slow, boring test-writing phase. This is the most expensive mistake in the space.
Without tests, you have no way to verify that a translation preserved behavior. The fix is what Michael Feathers called characterization tests in Working Effectively with Legacy Code (2004). These tests don't assert what the code should do. They capture what it currently does, including its bugs and oddities, so any change in behavior shows up immediately. That's a deliberate choice. A bug you preserve on purpose is a decision. A bug you accidentally change during migration is an incident.
The sequence matters. Write characterization tests against the legacy system first, then let AI produce the new version, then run the same tests against the output. If the tests pass, you have evidence. If they don't, you have a precise list of behavioral differences to review. Skip the first step and you're trusting a model's confidence instead of your own verification.
Where Teams Get Burned
Most failures I've seen in this kind of work follow predictable patterns, and they're rarely dramatic. They show up weeks later as a number that's slightly off.
Consider a hypothetical payroll module. The original system used fixed-point decimal arithmetic for currency, which is standard in COBOL-based financial code. The AI-generated replacement uses floating-point numbers in a modern language. Each individual calculation looks correct. Over thousands of records, rounding differences accumulate, and the totals drift by amounts too small to notice in a single paycheck but large enough to fail a reconciliation. The tests that would have caught this were never written, because the team assumed the translation was equivalent.
Other common failure modes include:
- Edge-case drift in date handling, time zones, encoding, and null behavior.
- Oversized diffs that reviewers approve by skimming, because nobody can read 4,000 changed lines carefully.
- Plausible insecure code, such as generated input handling that skips validation the original code performed.
Here's where it gets interesting: the bigger the AI-generated change, the less reliable the review. Keep changes small enough that a human can hold the whole diff in their head.
Choosing an Approach: Rewrite, Refactor, or AI-Assisted Migration
There's no single correct method. The right choice depends on how much the system changes, how risky it is to run, and how much behavior your business depends on. The table below compares the main options.
| Approach | Best for | Main risk | Effort profile |
|---|---|---|---|
| Full rewrite | Systems with a clear, documented spec and a tolerable outage window | Rebuilding years of hidden business rules from scratch | Highest upfront, cleanest end state |
| Strangler fig pattern (incremental replacement) | Large, critical systems that must stay live | Running two systems in parallel longer than planned | Spread over many releases, lower per-release risk |
| AI-assisted line-by-line translation | Well-tested modules with stable behavior | Subtle semantic drift that passes superficial review | Fast per module, depends heavily on test coverage |
| Targeted dependency and security patching | Known vulnerable components with a clear fix | Breaking changes in upstream APIs | Low effort, high urgency |
The strangler fig pattern, described by Martin Fowler, is often the safest default for systems people actually depend on. You route new functionality or one capability at a time to the replacement and retire the old code gradually. AI helps most inside that structure, because each slice is small enough to test and review properly. Full rewrites still make sense for small, well-specified systems. For everything in between, be skeptical of anyone promising a single-weekend migration.
A Practical Sequence for Paying Down Debt This Quarter
If you're staring at a large legacy estate and don't know where to start, work through this sequence. Each step gives you information the next step needs.
- Rank your debt by risk and churn. Code that changes often and breaks often matters most. Adam Tornhill's hotspot analysis, which tools like CodeScene automate, combines version-control history with complexity metrics to find those files.
- Inventory your dependencies. Generate a software bill of materials using a standard format such as CycloneDX or SPDX. You can't patch what you haven't listed.
- Write characterization tests for the top hotspots. Capture current behavior before anyone touches the code.
- Use AI for explanation first, translation second. Ask it to summarize a module and list its side effects. Then compare its summary against what the tests show.
- Keep every change small. Set a diff-size limit your reviewers can actually handle, and reject anything larger.
- Measure the result. Track defect rates, rollback counts, and reconciliation failures in the affected modules, not just lines migrated.
That last step is the one most teams skip. Migrated lines are a vanity metric. Fewer incidents in the code you touched is the metric that tells you the debt is really shrinking.
Frequently Asked Questions
What is AI technical debt?
AI technical debt refers to the accumulated cost of legacy code, outdated dependencies, and undocumented behavior that AI tools now make cheaper to understand and repair. The debt itself isn't new. What's new is that AI can reduce the effort of paying it down, though it still requires human specifications, tests, and review to do so safely.
How do you pay off technical debt with AI?
Start by ranking debt by risk and change frequency, then write characterization tests for the highest-risk code. Use AI to explain modules and draft translations in small slices, and run the original tests against each output. Keep every change small enough to review carefully. Skipping the tests is the most common reason these projects fail.
Why does legacy code become a security risk?
Legacy code often depends on old libraries that stop receiving security patches. When a critical vulnerability appears, like Log4Shell in 2021, organizations must find every instance, which is hard if nobody maintains an inventory. Unvalidated inputs and outdated authentication patterns in older code add further exposure that's easy to miss.
When should you rewrite instead of refactor?
Rewrite when the system is small, well-specified, and can tolerate a cutover window. Refactor or migrate incrementally, such as with the strangler fig pattern, when the system is large, business-critical, or full of undocumented rules. A full rewrite of a complex system often takes longer and loses more hidden behavior than teams expect.
Your most useful next step is small and concrete. Pick the single most-changed module in your codebase, write characterization tests for it this week, and note how many behaviors surprised you. Those surprises are your real debt inventory, and they'll tell you more than any AI-generated summary will. Share this with someone who's wrestling with a legacy system they're afraid to touch, because that's the person who needs the sequence most.