Technical debt did not disappear with AI. It moved into maintenance.
- technical debt
- AI
- maintenance
- code quality
In 2023, code was written more slowly than it is today. That is the one thing everybody agrees on.
The rest is harder. Teams ship faster than ever, and at the same time report more incidents, more rollbacks and more hours spent repairing something that worked last week. The two do not contradict each other. Technical debt did not disappear when coding assistants arrived — it moved. Out of the build phase, where it was visible and budgeted, and into maintenance, where it is neither.
It is worth looking at the numbers before deciding whether this concerns you.
What the data shows
GitClear analysed 623 million code changes between 2023 and 2026, tracking eight quality signals. The direction is consistent and unpleasant:
| Signal | Change |
|---|---|
| Refactoring | 21% of changed lines in 2022 → 3.8% in 2026 |
| Block duplication | +81% since 2023 |
| Cross-file function calls | −35% (343 → 223 per thousand lines) |
| Error-masking constructs | +47% |
| Code rewritten within two weeks | +15% |
| Maintenance of older code | −74% |
Three of those rows tell the same story from different angles. Refactoring has nearly vanished, duplication has risen, and calls between files have thinned out. Together they describe code that stops being a network of pieces calling one another and becomes a pile of near-identical copies. Every copy works. Every copy has to be fixed separately, when the day comes.
The 2025 DORA report supplies the other half. 90% of respondents use AI at work and over 80% believe it has made them more productive. Adoption correlates clearly with faster delivery. It correlates just as clearly with lower stability: more change failures, more rework, longer cycles to resolve an incident. Three developers in ten say they have little or no trust in the code a model hands them.
The part that should worry you
The most instructive study is not about code at all — it is about perception. METR ran a randomised trial with 16 experienced developers across 246 real tasks, in repositories they had worked on for years. Each task was randomly assigned: with an AI assistant, or without.
With the assistant, they were 19% slower.
Before the trial they had estimated they would be 24% faster. Afterwards, convinced it had gone well, they estimated they had been 20% faster. The measurement said the opposite.
This is not a story about weak tools. It is a story about the feeling of progress and actual progress coming apart. And if that happens over a task lasting a few hours, which can be measured, consider how well intuition performs over a three-year horizon where nobody measures anything.
Where the cost went, precisely
Technical debt was not invented in 2023 and has not evaporated. It moved along two axes.
In time. A badly written codebase used to slow you down in the first month: hard to read, slow to review, awkward to integrate. Now it passes review — it is tidy, it is commented, it follows the conventions. The cost shows up in month eight, when somebody has to change a business rule that exists in seven slightly different places and finds only six.
In the invoice. The build phase has a budget, a deadline and somebody who signs off at the end. Maintenance has a monthly subscription nobody scrutinises. The debt moved out of the project budget and into recurring cost, where it is far harder to see and far easier to keep paying indefinitely.
The quietest row in the table is also the worst: error-masking constructs, up 47%. A try/catch that swallows the exception and carries on. A check that returns a default instead of stopping. Code that makes things look like they are working. In a demo it is invisible. In production it means you learn about the problem from a customer rather than from an alert — and you learn about it much later than you could have.
Why this matters more to us than to others
We should be direct about our own interest here, because it is the argument.
Our model is that a project starts cheap and stays in our maintenance on a monthly retainer. Which means we are the ones who pay the debt we ship. Code duplicated in seven places is not the client's problem a year from now — it is ours, every month something has to change in it. An empty catch does not ruin their weekend, it ruins ours.
A supplier paid by the hour and gone after handover has precisely the opposite incentive. We are not saying they exploit it deliberately. We are saying nobody resists an incentive pushing them one way forever.
What we actually do about it
These are not intentions. They are rules you can verify by reading the code we hand you.
One place for each thing. Configuration is read in a single file, which complains loudly at startup if something is missing rather than on the first request. SQL lives in one layer; the rest of the application does not write queries. When a rule changes, it changes in one place, and we do not have to remember how many times it was copied.
Comments explain why, not what. A comment restating the line below it is noise. One explaining why the odd approach was chosen over the obvious one is the only thing that saves you two years later, when somebody is about to "clean up" that exact oddity. Every non-obvious decision in our code has its reason written next to it.
We do not mask errors — we choose explicitly what happens on failure. There are places where a function must continue even if a dependency is down; a quote request, for instance, is saved to the database even when the email service is unreachable. The difference from an empty catch is that the choice is deliberate, it is commented, and it leaves a trace in the log. Nothing fails silently.
Refactoring is part of the work, not part of "when we have time". There is no later. Code that is not cleaned as it is written never gets cleaned, and the 3.8% figure above is the statistical demonstration of that sentence.
Every line has to be explainable by a human. We use coding assistants. It would be absurd not to. But the rule is simple and has no exceptions: if nobody on the team can explain why a piece of code looks the way it does, it does not go into the project. A model gives you an answer that compiles; it does not give you responsibility for it.
We verify in production, not in a demo. Backups are restored as a test, not merely taken. Monitoring has to tell us before it tells the client. A procedure written and never rehearsed is an assumption.
The code is yours from day one. In your repository, with a runbook. That is the best guarantee the rules above are real: anyone can check them, at any time, including another supplier you might want to move to.
What we are not claiming
That AI is the problem. The numbers do not say that. The same reports show real speed gains, and DORA is explicit: instability appears where the volume of change grows without matching control systems — automated testing, disciplined version control, fast feedback. The tools did not break anything. They exposed what was already missing.
Nor are we claiming to have our own figures proving we are better. We do not. Nobody serious does at this scale, and anyone showing you such numbers is selling you something.
What to ask anyone building software for you
Three questions, with answers that are easy to check:
- Show me a place in the code where you chose the more complicated option. Why? If there is not one, either the project is trivial or nobody thought about it.
- What happens when service X goes down? A good answer sounds like a decision. A bad one sounds like "it shouldn't go down".
- Who pays if the code is hard to change a year from now? The answer to that tells you more about the quality you will receive than any list of technologies.
Technical debt has moved into the future. The useful question is no longer what it costs to build, but who pays when the bill arrives.
Sources
The figures in this article are not ours. You can check them directly:
- GitClear — The Maintainability Gap: 2026 AI Code Quality Research — 623 million code changes, 2023-2026. Every number in the table comes from here.
- GitClear — AI Copilot Code Quality: 2025 Research — the earlier analysis, across 211 million lines, which first flagged the rise in duplication.
- METR — Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity — the randomised trial behind the 19%. Full paper: arXiv:2507.09089.
- DORA — Balancing AI tensions: moving from AI adoption to effective SDLC use — the relationship between AI adoption, delivery speed and stability.