The Hidden Cost of AI-Written Code

AI-written code is cheap to produce and expensive to own when nobody controls its quality. Research shows the pattern: more duplicated code, less refactoring, and less stable releases as AI use rises. The speed is real. So is the technical debt, which builds up quietly until changing anything takes longer than it used to.

At Avesta, most of our own code is written with AI. We build Avesta AgentOS this way. This article covers what the research says, where AI-generated code hides its technical debt, the metrics that reveal it early, and how we keep the speed without paying for it later.

Why is AI-written code now the norm?

Because it works, at least for speed. Google's 2025 DORA research, a survey of nearly 5,000 technology professionals, found AI adoption among software professionals had reached 90%. For the first time, it also linked AI adoption to higher software delivery throughput. Over 80% of respondents said AI made them more productive.

That isn't the problem. The problem is what speed does to everything downstream of writing code: reviewing it, testing it, understanding it, and changing it six months later.

What does the research say about AI-written code quality?

Three pieces of research point the same way.

More duplication, less refactoring. GitClear, which sells code analytics tools, analysed 211 million changed lines of code from 2020 to 2024. Lines associated with refactoring fell from about 25% of changes in 2021 to under 10% in 2024. Copy-pasted lines rose from 8.3% to 12.3% over the same period, and 2024 was the first year copy-pasted code outpaced moved, reused code. In plain terms: teams are adding more code and reorganising less of it.

Less stable delivery. Google's 2024 DORA report estimated that a 25% increase in AI adoption came with a 7.2% drop in delivery stability, even as code quality and review speed slightly improved. The 2025 report found throughput had turned positive, but said making sure software works as intended before release remains the challenge.

Feeling faster isn't the same as being faster. In a 2025 randomised trial by METR, 16 experienced developers working on their own large open-source projects took 19% longer on tasks when AI was allowed. Before starting, they expected AI to make them 24% faster. Afterwards, they still believed it had sped them up by 20%. The study is small and specific to experienced developers in mature codebases, but the gap between perception and reality is the point.

The speed of AI-written code is real. So is the technical debt.

Where does the debt hide?

1. Duplicated logic

AI tools write the code you ask for, in the place you ask for it. They're less likely to notice that the same logic already exists elsewhere and should be reused. The result is the same business rule in five places. When the rule changes, someone updates four.

2. Architecture drift

This is the one we watch most closely. Every codebase has an intended structure. Ours is layered: each layer has a clear responsibility, and layers stay loosely coupled so each can be tested on its own.

AI sees the file in front of it, not the whole system. So it will sometimes put logic in the wrong layer, or tie two parts together that should stay separate. One misplaced piece of code seems harmless. The damage comes next:

• It gets harder to test. Tightly coupled code can't be tested in isolation.
• Duplication follows. The same responsibility now lives in two layers, and both get maintained.
• AI amplifies the mistake. AI coding tools learn patterns from your existing code. Once a type of logic appears in the wrong layer, the AI treats that as where it belongs and puts more of it there.

That last point is what makes drift different from ordinary technical debt. A human who makes a design mistake makes it once. An AI that learns from a drifted codebase repeats it in every change that follows, so drift compounds instead of staying put.

A human makes a design mistake once. An AI that learns from a drifted codebase repeats it in every change.

3. Thin tests

AI is good at writing tests that pass. That isn't the same as tests that would catch a mistake. When the same model writes the code and its tests, the tests often confirm what the code does, not what it should do.

4. Code nobody understands

Code that was generated rather than written may have no author who fully understands it. It looks clean and professional, which makes the problem harder to see. The cost arrives during the first serious incident, when nobody can explain why it behaves the way it does.

5. Oversized changes

AI makes large changes cheap. Large changes are hard to review well, and reviewers under time pressure skim. Bigger, faster changes with the same review effort are a direct route to the stability drop DORA measured. We've written about why small, incremental changes matter even more with AI-generated code.

6. Unvetted dependencies

AI tools readily suggest libraries and packages. Some are outdated, unnecessary, or poorly maintained. Each one added without review is something you now own, patch and secure.

Why don't teams notice until it's expensive?

Because the usual measures reward the thing that creates the debt. Lines of code, pull requests and tickets closed all go up with AI. None of them shows whether the codebase is getting easier or harder to change.

The debt also hides behind good formatting. AI-written code reads well. Duplication and design drift don't show up in a single pull request; they show up across hundreds. And as the METR study suggests, the people doing the work may sincerely believe they're moving faster than they are.

By the time it's obvious, the symptoms look like this: estimates keep growing for simple changes, fixes in one place break another, and experienced engineers spend their time untangling rather than building.

How do you keep the speed without the debt?

You don't fix this by using less AI. You fix it by putting quality controls where AI output enters the system, and by making small, frequent changes safe. This is how we work at Avesta, using Avesta HQ, our AI-native delivery platform, and Code Clinic, which tracks code health.

• Architecture drift is measured, not hoped for. We define our architectural rules (layers, responsibilities, coupling) in Code Clinic, and it flags code that breaks them. Every team's architecture is different, so Code Clinic is configured to the rules each team actually works by, not a generic standard.
• People own the architecture. Engineers decide the structure, boundaries and conventions. AI agents work inside them, with those conventions written down as context so the agent follows them.
• Checks at every stage. Avesta HQ runs architecture checks and tests at each stage of delivery, not only at the end, so drift is caught when it's one change old, not one hundred.
• Continuous refactoring. When Code Clinic surfaces new debt or drift, we fix it as part of normal work, not in a cleanup project later. The codebase stays within the baseline limits we've set.
• Small changes, shipped daily. We integrate continuously and deploy to production every day. Unfinished features ship behind feature flags, so nothing waits in a long-lived branch growing into a risky merge.
• Tests are the safety net. Our tests cover almost all of the code, and they're written from the requirement, not from the code the AI just wrote. Because changes are small and go out daily, when something breaks we see it in the system straight away and know which change caused it.
• Stability measured alongside speed. We look at what fails and what gets reworked, not just what ships.

The same discipline is what makes fast product experiments safe to roll back, which we cover in What Is AI-Native Product Engineering?

The principle is simple: when code gets cheaper to write, checking it has to get cheaper too, or it gets skipped.

When code gets cheaper to write, checking it has to get cheaper too. Or it gets skipped.

Which metrics show AI-written code debt early?

The last one is the one executives feel. If a small change to how the product works now takes twice as long as it did last year, the debt has arrived.

Code Clinic puts these signals on one screen. The view below is an illustration with example numbers, not data from a real codebase.

What should you ask a vendor who uses AI to write your code?

Most vendors use AI now, and they should. The question is how they control it:

1. Who decides the architecture, and how is it enforced when AI writes the code?
2. What checks run before AI-written code is merged, and at which stages?
3. Who writes the tests, and are they written against the requirement or the code?
4. How do you measure code health over time? Can I see the trend for my codebase?
5. How do you keep changes small enough to review properly?
6. If your team left tomorrow, could mine understand and change this code?

Good answers are specific and come with evidence. "Our developers review everything" is not an answer when the volume of code has doubled. For the wider set of questions to ask an AI development partner, see why your outsourcing partner can't build your AI product.

Where to start

Pick one part of your product that changes often. Measure duplication, churn and how long a simple change takes there today, then again in three months. If the trend is going the wrong way, you have AI-written debt building up, whoever wrote the code.

If you'd like a second pair of eyes, Avesta's AI-native product engineering team builds with AI every day and keeps the codebase healthy with Avesta HQ and Code Clinic. Book a discovery call and we'll look at your codebase with you.

Sources

• GitClear, AI Copilot Code Quality: 2025 research, 2025 (211 million changed lines, 2020 to 2024)
• Google Cloud, Announcing the 2024 DORA report, October 22, 2024
• Google, How are developers using AI? Inside our 2025 DORA report, September 23, 2025
• METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, July 10, 2025