AI technical debt: what AI coding tools leave behind, and how to pay it down

Last updated: 8 July 2026

AI technical debt is the maintenance burden that builds up when code is generated faster than it can be reviewed, understood and refactored. AI coding tools do not invent technical debt. They accelerate it, producing a large volume of plausible code and almost none of the discipline that keeps a codebase healthy. The 2025 DORA report is blunt about the effect: AI adoption now shows a positive relationship with delivery throughput, but it continues to show a negative relationship with delivery stability [1]. Teams ship more and break more, and the gap between those two outcomes is how much debt was already in the code and the process. This guide is for founders and engineering leaders who are shipping AI-assisted software and want to know what it is quietly costing them, and how to pay it back before the interest compounds.

What technical debt actually is

Technical debt is a borrowing metaphor, and it is worth returning to the original because AI has made it newly relevant. Ward Cunningham coined it in a 1992 experience report, describing the trade-off precisely:

"Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt." [2]

The key word is interest. Debt itself is not the problem. Unpaid debt is. Martin Fowler put the same idea in concrete engineering terms: if a clean design would let you add a feature in four days, and the accumulated cruft makes it take six, the two-day difference is the interest you pay on every future change [3].

Fowler also drew the distinction that matters most for AI-built software. The useful question is not whether debt exists, but whether it is prudent or reckless, and whether it was taken on deliberately or inadvertently [4]. Debt a senior engineer takes on knowingly, to hit a date, with a plan to repay it, is a sound decision. Debt that accumulates silently because nobody understood the code well enough to know it was there is the dangerous kind. AI-generated code, shipped unreviewed, is squarely in that second category: inadvertent debt at best, and reckless debt when it goes to production under deadline pressure with nobody having read it.

What is different when AI writes the code

AI does not change the nature of technical debt. It changes the volume and the speed at which it arrives. A coding assistant can produce in an afternoon what used to take a week, and if the reviewing, testing and refactoring do not scale at the same rate, the debt accrues faster than any team has had to manage before.

The scale of adoption is why this matters now. The 2025 DORA report, based on almost 5,000 technology professionals, found that 90% of respondents use AI at work and more than 80% believe it has increased their productivity, yet 30% report little or no trust in the code it produces [1]. Stack Overflow's 2025 developer survey tells the same story from a different sample: AI-tool adoption rose to 84%, while distrust of the accuracy of AI output (45.7%) now runs well ahead of trust in it (32.7%) [5]. Developers are using these tools more and believing them less, which is a rational response to shipping code they have not fully verified.

DORA's own conclusion is the most useful frame we have found for this problem:

"AI doesn't fix a team; it amplifies what's already there. Strong teams use AI to become even better and more efficient. Struggling teams will find that AI only highlights and intensifies their existing problems." [1]

A codebase with strong tests, mature version control and a real review gate absorbs AI-generated code and gets faster. A codebase without those things absorbs the same code and accumulates debt at a rate proportional to how much it ships. The tool is an amplifier, not a cause.

The debt is visible in the code

The shift is measurable, not anecdotal. GitClear analysed 211 million changed lines of code from 2020 to 2024 and found the fingerprints of AI assistance in the structure of the code itself. Lines classified as copy-pasted rose from 8.3% in 2021 to 12.3% in 2024, while lines associated with refactoring fell from 25% to under 10% over the same period [6]. 2024 was the first year GitClear ever measured in which copy-pasted lines outnumbered lines that were moved, which is to say reused [6].

That single reversal is a debt signal in its own right. Moving code is how a codebase stays maintainable: one function, called from many places, fixed in one place. Copying code is how debt spreads: the same logic duplicated across a codebase, so a single bug must be found and fixed in every copy. GitClear is a vendor that sells code-quality tooling, so it has an incentive to find quality problems, and its headline duplication multipliers vary across its own materials. The two percentage-point figures above are the stable, internally consistent numbers, and they point one way: AI-assisted codebases duplicate more and consolidate less.

What we find when we audit AI-built software

When we run a Vibe Code Audit over software built with a coding assistant, the debt clusters into a handful of recurring categories. None of them is exotic, which is exactly why a structured review surfaces them quickly.

Duplicated logic and architectural drift. Each AI session solves its task in isolation, with no memory of how the rest of the codebase already does the same thing. The result is three implementations of one idea and no single place to change it. This is the duplication the GitClear data measures, and it is the debt that makes every later change slower [6].

Tests that prove the code ran, not that it is correct. AI-written test suites tend to assert the happy path: the function was called, it returned something, the app started. They rarely exercise an unauthorised request, a malformed input, or a failure path. A green suite that asserts almost nothing is worse than no suite, because it reads as reassurance while providing none.

Security debt. Veracode's 2025 benchmark tested over 100 models across 80 coding tasks and found that AI-generated code introduced an exploitable security flaw in 45% of cases, a rate that did not improve as models got larger [7]. Insecure-by-default code is debt with a deadline: it sits quietly until someone finds it, and increasingly that someone is automated.

Supply-chain debt. Coding assistants routinely recommend packages that do not exist. A peer-reviewed study presented at USENIX Security 2025 found that 19.7% of packages suggested by code-generating models were hallucinated, and 43% of those fictional names recurred across repeated prompts [8]. Persistent, predictable, non-existent dependency names are an open invitation to attackers, who register the fictional package and wait, a technique now called slopsquatting.

Secrets in the source. Credentials hard-coded into the codebase are a classic finding that AI has made more common. GitGuardian recorded 28.65 million new hardcoded secrets pushed to public GitHub in 2025, a 34% year-on-year rise, and reported that commits co-authored by AI assistants leak secrets at roughly twice the baseline rate [9]. GitGuardian sells secrets detection, so treat the figure as vendor research, but the pattern matches what we find.

Why AI-built code accrues debt by default

The reasons are structural, which is why the numbers do not improve on their own. A model optimises for code that plausibly satisfies the prompt, not for code that fits cleanly into the system around it or holds up under conditions nobody asked about. It has no view of your architecture, so it cannot reuse what it cannot see. It learned from public code full of shortcuts, so it reproduces those shortcuts confidently. And it works one session at a time, so it optimises locally and leaves the global consistency, the thing that keeps maintenance costs down, to whoever reviews it. When nobody does, the debt is the difference between the code you got and the code a senior engineer would have written.

What it costs to leave it

Unpaid technical debt is not an abstraction; it is engineering time you no longer get to spend on the product. Even before today's AI tools existed, the cost was large. Stripe's 2018 Developer Coefficient survey, conducted before GitHub Copilot and the current generation of assistants, found developers spending around 13.5 hours of a 41.1-hour week dealing with technical debt [10]. That is roughly a third of the working week lost to maintenance, as a baseline, before any AI tool was accelerating the rate of accumulation.

At national scale the numbers are stark. The Consortium for Information and Software Quality put the cost of poor software quality in the United States at $2.41 trillion in 2022, of which accumulated technical debt accounted for an estimated $1.52 trillion [11]. That is a United States figure with no direct UK equivalent, so read it as an order of magnitude rather than a local invoice, but the direction is clear: debt that is never serviced becomes the largest line item in software.

The newest cost is the one that should concern a UK engineering leader most, because it turns latent debt into active risk. The National Cyber Security Centre warned in May 2026 that organisations should prepare for a surge of vulnerability disclosures, and its Chief Technology Officer, Ollie Whitehouse, was explicit about the mechanism:

"Artificial Intelligence, when used by sufficiently-skilled and knowledgeable individuals, is showing the ability to exploit this technical debt at scale and at pace." [12]

The debt that used to sit harmlessly in a neglected corner of a codebase is now something an attacker can find and exploit faster than before. Servicing it has moved from good housekeeping to a security control.

How to pay AI technical debt down

The remedy is not to stop using AI. These tools genuinely accelerate delivery, and that is worth keeping. The remedy is to put back the discipline the speed removed, so the throughput does not turn into instability. In practice that means four things.

Put a senior review gate between generation and production. The single highest-value control is a named senior engineer reading AI-generated code against recognised standards before it ships, and deciding what is safe now, what must be fixed first, and what should be rebuilt rather than patched. This is the discipline DORA found separates teams that get faster with AI from teams that just get less stable [1]. We describe how we run that review in what a vibe code audit actually finds, and the checklist a team can apply itself in how to review AI-generated code.

Measure the debt so you can prioritise it. You cannot pay down what you cannot see. Track duplication, test coverage that exercises failure paths rather than start-up, dependency freshness, and the presence of secrets in the source. These are the categories that reliably accumulate in AI-built code, and measuring them turns a vague worry into a ranked list of work.

Separate prudent debt from reckless debt, and repay the reckless first. Fowler's distinction is the triage tool [4]. Debt you took on deliberately, understand, and have a plan for can wait. Debt that is reckless or inadvertent, an unreviewed authorisation path, a hallucinated dependency, a hard-coded key, is the interest-bearing kind and comes first. The goal is not zero debt; it is no reckless debt in the surfaces that matter.

Restore the controls AI removed. DORA is clear that AI increases change volume, and that without strong automated testing, mature version control and fast feedback, more change means more instability [1]. Real tests on the risky paths, disciplined version control, and a review gate are what let a team keep the speed without inheriting the debt.

For a funded founder, this is also due-diligence protection: a codebase full of duplicated logic, shallow tests and committed secrets is exactly what a technical reviewer finds in an afternoon, as we cover in pre-acquisition code due diligence for AI-built products. We recently ran this same review over one of our own neglected internal tools and retired it rather than repair it; the account is in we audited one of our own internal tools.

Frequently asked questions

What is AI technical debt?

AI technical debt is the maintenance burden that accumulates when AI coding tools generate code faster than a team can review, understand and refactor it. It appears as duplicated logic, shallow tests, insecure patterns and hallucinated dependencies. The tools do not create debt from nothing; they accelerate how quickly it builds up in a codebase.

Does AI-generated code really create more technical debt?

The evidence points that way. GitClear found copy-pasted code rose from 8.3% to 12.3% of changed lines between 2021 and 2024, while refactoring fell from 25% to under 10% [6]. DORA's 2025 report links AI adoption to lower delivery stability where testing and review discipline are weak [1]. More code, less consolidation, means more debt.

How do you measure AI technical debt?

Measure the categories that reliably accumulate in AI-built code: code duplication, test coverage that exercises failure paths rather than just start-up, dependency freshness and hallucinated packages, and secrets committed to the source. Tracking these turns a general worry into a ranked list, so you can repay the reckless, interest-bearing debt before the debt you took on deliberately.

Should we stop using AI coding tools to avoid the debt?

No. AI coding tools genuinely accelerate delivery, and that is worth keeping. DORA found the difference between teams that improve with AI and teams that destabilise is not whether they use it, but whether they have strong testing, version control and a review gate [1]. Keep the speed; restore the discipline that stops it becoming debt.

Is AI technical debt a security risk?

Increasingly, yes. Veracode found AI-generated code introduced an exploitable flaw in 45% of tests [7], and the NCSC has warned that AI is now able to exploit long-neglected technical debt at scale and pace [12]. Unserviced debt that once sat harmlessly is now something attackers can find and use faster, so paying it down is a security control.

The honest answer

AI lets a small team build something real in a fraction of the time it used to take, and that is a genuine advance. What it does not do is review, test or consolidate its own output, and that unpaid work is the debt. Left alone, it compounds, in slower changes, higher risk, and a codebase nobody fully understands.

If you have built something with AI and want a senior engineer to tell you honestly how much debt is in it, and what to repay first, book a Vibe Code Audit. We will tell you what we find, rank it by what it is costing you, and put our name to the verdict. For the broader question of readiness, read whether AI-generated code is safe to ship.

Sources

1. DORA / Google Cloud, "Announcing the 2025 DORA report" (State of AI-assisted Software Development), 23 September 2025. https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report
2. Ward Cunningham, "The WyCash Portfolio Management System", experience report, OOPSLA 1992. https://c2.com/doc/oopsla92.html
3. Martin Fowler, "Technical Debt" (bliki), revised 21 May 2019. https://martinfowler.com/bliki/TechnicalDebt.html
4. Martin Fowler, "Technical Debt Quadrant" (bliki), 14 October 2009. https://martinfowler.com/bliki/TechnicalDebtQuadrant.html
5. Stack Overflow, 2025 Developer Survey, AI section, December 2025. https://survey.stackoverflow.co/2025/ai
6. GitClear, "AI Copilot Code Quality: Evaluating 2024's Increased Defect Rate", February 2025. https://www.gitclear.com/ai_assistant_code_quality_2025_research
7. Veracode, 2025 GenAI Code Security Report, October 2025. https://www.veracode.com/resources/analyst-reports/2025-genai-code-security-report/
8. Joseph Spracklen et al., "We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs", USENIX Security 2025, arXiv:2406.10279. https://arxiv.org/abs/2406.10279
9. GitGuardian, The State of Secrets Sprawl 2026. https://www.gitguardian.com/state-of-secrets-sprawl-report-2026
10. Stripe, "The Developer Coefficient", September 2018. https://stripe.com/files/reports/the-developer-coefficient.pdf
11. Consortium for Information and Software Quality (CISQ), "The Cost of Poor Software Quality in the US: A 2022 Report", Herb Krasner, 2022. https://www.it-cisq.org/the-cost-of-poor-quality-software-in-the-us-a-2022-report/
12. National Cyber Security Centre, "Preparing for a 'vulnerability patch wave'", Ollie Whitehouse (CTO), 1 May 2026. https://www.ncsc.gov.uk/blogs/prepare-for-vulnerability-patch-wave