There is a moment every engineering leader knows. A sprint goes unusually well. Features ship ahead of schedule. The team looks energized, velocity metrics look great, and the product demo is smooth. Then, three weeks later, someone touches that code.
I have had this happen twice in the last year — once within a project at Telus Digital and once at Sherlock Studio, where we were using AI coding tools aggressively to accelerate delivery for a client under a hard deadline. Both times, the features worked. Both times, the underlying code was a slow-motion disaster we had implicitly agreed to deal with later.
This is the shape of AI-generated technical debt. It is faster than what we have always known, quieter, and it accumulates in patterns that our existing code review practices were not designed to catch.
The numbers are already catching up to the hype
In early 2025, GitClear published a study analyzing 211 million lines of code committed between 2020 and 2024 — the most comprehensive public dataset on AI’s actual impact on codebases. The findings deserve more attention than they have received in engineering leadership circles.
In 2024, duplicated code blocks increased eightfold compared to previous years — a rate of duplication ten times higher than just two years prior. Refactoring activity, measured as the proportion of code lines associated with improving and consolidating existing work, collapsed from 25% of changed lines in 2021 to less than 10% in 2024. For the first time in GitClear’s historical dataset, copy-pasted code exceeded moved code. Developers were producing more. They were reusing, and therefore improving, far less.
Google’s 2024 DORA report, which surveyed roughly 3,000 technology professionals globally, added another layer to this picture. As AI adoption in organizations increased by 25%, delivery throughput dropped by an estimated 1.5% and delivery stability dropped by 7.2%. The report was direct about what this revealed: improving the development process does not automatically improve software delivery, at least not without the fundamentals of small batch sizes and robust testing. AI accelerated individual productivity. It did not accelerate the system.
Harness’s State of Software Delivery report, published January 2025, found that 67% of developers now spend more time debugging AI-generated code than they did before, and 68% spend more time resolving AI-related security vulnerabilities. The speed gained at the generation stage was being spent, often at a loss, in the stages that followed.
None of these numbers mean AI coding tools are a mistake. They mean we have been measuring the wrong thing. We optimized for the moment of generation and ignored the full lifecycle of what gets generated.
What I learned the expensive way
When I joined Gameskraft in 2018 and architected the Gamezy platform from scratch, AI coding assistants did not exist. What we had was the human version of the same problem: a twelve-person team, serious delivery pressure, and the constant temptation to duplicate a working pattern rather than abstract it properly.
Technical debt accumulated the old-fashioned way — through every shortcut that felt reasonable in the moment and every refactoring conversation we agreed to have later. By the time the platform was handling real scale, the cost of that debt showed up in the places it always does: the length of time it took to onboard a new engineer, the cognitive overhead of touching a service that had been extended rather than redesigned, the production incidents that cascaded through dependencies nobody fully understood.
We paid that debt back, but slowly and expensively, over months of deliberate refactoring work that had to compete with feature delivery at every planning session. The experience left me with a clear intuition about what technical debt actually is: not the presence of imperfect code, but the absence of the time you would need to fix it.
What AI coding tools do is accelerate the accumulation phase. The generation phase becomes dramatically faster. The debt phase arrives on the same schedule it always did, because debt is a property of the code itself, not of who or what wrote it.
Why this debt is different
Traditional technical debt is visible. A developer who cuts a corner knows, on some level, that they are cutting it. The shortcut is a decision. In AI-assisted development, the shortcut is not always a decision — it is an output. The AI assistant generates code that works in the context it has been given. It is optimized for local coherence, not systemic integrity.
This is the mechanism behind the GitClear numbers. AI coding assistants, by the nature of how they process context, are not reasoning about whether the pattern you are about to introduce already exists somewhere else in the codebase. They do not suggest that what you are building as a new feature might be better implemented by refactoring the service you wrote six months ago. That is not a flaw in the tool — it is the boundary of what the tool is doing. But it means that the discipline of system-level thinking has to come from the engineer, and under delivery pressure, system-level thinking is the first thing to give way.
At Zolve, where I led a twenty-person team building financial infrastructure for cross-border payments and remittances, we learned early that code in a fintech product carries a different risk profile than most other domains. A duplicated validation function in a consumer app is a maintenance annoyance. A duplicated validation function in a remittances flow, where both copies need to evolve together to stay compliant with regulatory requirements, is a compliance incident waiting to happen. The stakes made the discipline easier to hold. In lower-stakes environments, the same risks feel abstract until they materialize.
The refactoring data from GitClear is the most telling signal here. Refactoring is the mechanism through which software teams convert working code into maintainable code. It is not cosmetic. When the proportion of code activity dedicated to refactoring falls from one in four lines to fewer than one in ten, what you are measuring is not a change in output — it is a change in the quality of investment. Teams are building faster on foundations they are choosing not to strengthen.
The counterargument deserves a real answer
I want to take seriously the pushback I hear most often: AI tools are improving rapidly, and the models writing code in 2026 are meaningfully better than the ones doing it in 2023. Larger context windows allow them to reason across more of a codebase. Agentic tools can now identify redundancy across files and propose consolidations. Should we not expect the code quality problem to resolve itself as the tooling matures?
The 2025 DORA report offers a nuanced answer. Teams that invested in strong automated testing, mature version control practices, and fast feedback loops showed improved throughput with AI in 2025, where 2024 had shown a decrease. There is real evidence that organizations are learning to integrate these tools more effectively.
But the 2025 DORA report also confirmed that AI adoption continues to have a negative relationship with delivery stability, even as throughput improved. We are getting faster at creating instability. That pattern held across two consecutive years of the world’s most rigorous study of software delivery performance. Better tools without better practices is not a path out of technical debt. It is a wider, smoother lane into it.
What governance looks like in practice
I have spent considerable time over the last year thinking about what responsible AI-assisted development actually looks like, both within Sherlock Studio and in the conversations I have with engineering leaders across the organizations we work with. A few principles have held up.
AI-generated code requires architectural review, not just functional review. Most code review culture was built around two questions: does this work, and is it safe? AI coding tools have largely solved the first question at the function level. What they have not solved is whether the code belongs where it has been placed, and whether it duplicates something that already exists. Review criteria need to expand to include those structural questions explicitly, not as an afterthought.
Refactoring needs to be scheduled, not wished for. The GitClear data makes clear that the natural behavioral tendency of AI-assisted teams is to generate rather than consolidate. If refactoring is not explicitly allocated — as dedicated sprint capacity with real time attached to it — it does not happen. At Telus Digital, where I worked on systems that needed to remain maintainable across long timelines and large team rotations, the teams that protected refactoring cycles consistently maintained healthier velocity over time than those that deferred it. Not because they shipped more in any given sprint, but because their capacity to ship did not degrade.
Churn rate is worth tracking. GitClear defines churn as the proportion of new code revised within two weeks of its initial commit — a proxy for how much of what is being shipped is actually stable versus placeholder. Their data shows this rate rose from 3.1% in 2020 to 5.7% in 2024. If your team’s churn rate is climbing alongside your AI adoption rate, you have a signal worth interrogating before it becomes a problem worth managing.
The question that actually matters
The real question for any engineering leader using AI coding tools is not whether the code ships. It ships. The question is what you are building with it.
A feature that takes two days to generate and three weeks to safely modify is not a productivity win across a six-month roadmap. It is a deferred cost that your future self will pay, with compound interest, at the worst possible moment — when you are already under pressure to move fast on something else.
I made the expensive version of this mistake before AI tools existed. The corners I cut at Gameskraft, reasonable in the context of the sprint that demanded them, cost the team real time at real scale. The lesson I took from that experience was not to stop moving fast. It was to understand what I was actually buying with the speed.
AI coding tools do not change the fundamental dynamics of technical debt. They change the speed at which you can accumulate it. That is worth a great deal of respect — and a governance framework that matches the pace.
The teams that will look back on 2026 with satisfaction are not the ones that shipped the most. They are the ones that shipped thoughtfully enough to keep shipping.