AI Code Technical Debt You Can Measure: What GitClear's Data Shows

GitClear analysed 623 million code changes between 2023 and 2026 and found duplicated code blocks up 81% while refactoring moves fell 70%. That is the most detailed public dataset on AI code technical debt, and it comes from a company that sells code analytics. Both facts matter. The useful move for an engineering lead is to copy the method, not quote the headline.

The short answer. AI code technical debt is measurable through what changes in your commits rather than through opinions about AI. Track how much new code is rewritten within two weeks, how often 5-line blocks are duplicated, how much code is moved rather than copied, and whether old code still gets maintained. Those four trends are where GitClear's evidence points.

What GitClear actually measures in AI code quality

GitClear is a developer analytics vendor. Its research reports come from the same engine it sells: a parser that reads each commit and assigns every changed line an operation type. That classification is the whole method, so it is worth understanding before any headline number.

The vendor's 2025 report covered 211 million changed lines from 2020 to 2024, drawn from anonymised private repositories of its customers plus 25 of the largest open-source projects. The 2026 report widened the window to 623 million changes and was published jointly with GitKraken.

Six operations, one line at a time

Each changed line lands in one bucket. Added lines are new. Deleted lines are removed. Updated lines are edited in place. Moved lines are cut from one location and pasted into another, which GitClear treats as the footprint of refactoring. Copy/pasted lines repeat existing code. Find/replaced lines are bulk substitutions.

The logic is simple. Healthy codebases consolidate. Developers notice two functions doing the same job, merge them, and move the result somewhere shared. That activity leaves moved lines behind. A codebase that only grows leaves added and copy/pasted lines instead.

How code churn is defined

Churn is the second pillar. GitClear defines it as the percentage of lines that are reverted or updated less than two weeks after being authored. Short-lived code is a cost even when nothing breaks. Someone wrote it, someone reviewed it, and someone replaced it within a fortnight.

The definition has become a de facto standard. Academic researchers testing GitClear's claims adopted the same two-week window, which makes results comparable across studies. That is a point in GitClear's favour, and one rarely mentioned by its critics.

Code duplication from AI passed refactoring in 2024

The 2025 report produced the line most people quote. During 2024, the number of code blocks with 5 or more duplicated lines increased 8 times, according to DevClass's report on the research. Moved lines fell 39.9% in the same data.

2024 was also the first year copy/pasted lines exceeded moved lines in the dataset. New lines made up 46% of all changes that year. GitClear's explanation was mechanical: an assistant makes inserting a block as easy as pressing tab, and with limited context it is less likely to suggest reusing a function that already exists elsewhere.

Why duplication is the debt signal that matters

Duplicated code is not a style problem. When the same logic lives in four places, a bug fix applied to one leaves three still broken. Every copy becomes a future synchronisation task that nobody has scheduled.

Bill Harding, GitClear's chief executive and the report's author, put the measurement point bluntly in LeadDev's coverage. If productivity keeps being measured by commit count or lines added, he argued, maintainability decay will spread. I agree with him on this, and it is the most useful sentence in either report. Lines added is the worst metric you can put on an engineering dashboard in 2026.

The cost does not show up in the sprint that created it. That is why it accumulates. A team shipping 30% more lines looks faster on every activity chart, while its future change cost rises quietly in the background. The same dynamic is traced through review queues in the analysis of code review as the new bottleneck.

The 2026 maintainability gap: eight AI code quality signals

The 2026 report moved from line operations to a broader set of eight maintainability signals. By the time of the study, roughly a quarter of commits in the data showed AI assistance. That makes this the first dataset in which AI-touched code is a large share rather than a rounding error.

Duplicated blocks rose from 40.3 to 73.0 per million changed lines between 2023 and 2026, the 81% in the chart. Within-commit copy/paste rose 41%. Cross-file function calls, GitClear's proxy for reuse, fell 35%. Move refactors fell 70%.

Error masking is the signal to add first

The newest signal is the one I would put on a dashboard first. Error-masking constructs are catch blocks and null checks that swallow a failure instead of handling it, and they rose 47%. Assistants produce them because a suppressed exception makes generated code appear to run.

A swallowed error is worse than a crash. The crash tells you where the problem is. The silent catch moves the failure downstream to a place where it costs more to find. This connects directly to the testing gap examined in the piece on mutation scores for AI-generated tests, because a test suite that never triggers the swallowed path will never fail.

The legacy maintenance figure, down 74%, deserves equal attention. Harding framed it in coverage of the report as not tending to legacy code. Teams are building new things faster and touching old things less, which is a reasonable short-term trade and a poor long-term one.

The objections to GitClear's code quality data, and what they measured

GitClear's reports have drawn three serious counterweights. None of them directly refutes the duplication finding. Each measures something adjacent, and each deserves a fair reading.

GitHub's randomised trial found better code

GitHub ran a randomised controlled trial published in November 2024 with 202 experienced Python developers. Those with Copilot had a 53.2% greater likelihood of passing all 10 unit tests. Blind reviewers rated their code slightly more readable, reliable, maintainable and concise, with gains between 2.47% and 4.16%.

This is better experimental design than GitClear's, because it has a control group. It is also a single task, written from scratch, reviewed once. Duplication across a codebase and churn over two weeks cannot appear in a study of that shape. GitHub also defined code errors as readability problems, explicitly excluding functional errors.

DORA found faster reviews and lower stability

Google's 2024 DORA research found that a 25% rise in AI adoption was associated with an estimated 7.2% fall in delivery stability. It also estimated a 1.5% fall in throughput. The same model found a 3.4% improvement in code quality, along with faster code reviews and better documentation.

So DORA supports both camps. Developers perceive better code, and production gets less stable. That split is consistent with GitClear's picture of locally clean code that is globally harder to change.

A 151-repository study found no general rise in churn

The sharpest challenge comes from academic work. Xiao and colleagues studied open-source repositories that self-reported GenAI use and applied GitClear's own churn definition. Across 151 repositories, they found no general increase in churn after adoption, contradicting what the authors called popular narratives.

That result matters, and it has limits too. Adoption dates came from the first public mention of a tool. The study had no group of non-adopting repositories for comparison. Effects were stronger for code generation tasks, which is exactly where GitClear's concerns sit.

Where this argument is weakest

I have argued that GitClear's direction is right. Here is the case against relying on it.

The data cannot separate AI from everything else

The reports are correlational. Between 2022 and 2026 the industry also went through layoffs, hiring freezes and shifting team composition. Any of those could reduce refactoring. GitClear's own coverage concedes that some signals appear to be flattening, which is not what a simple story about assistants would predict.

The customer base also changes year to year. A dataset drawn from paying customers is not a random sample of software, and a 2026 cohort is not the same population as a 2023 one.

The vendor sells the remedy

GitClear's business is measuring the problem its reports describe. That does not make the numbers wrong. It does mean every claim here reached you from one company's pipeline, and six articles restating it are still one source. The figures in this post came through press coverage because GitClear's own pages refused automated access, which is a second reason to treat them as directional. The same caution, applied across AI developer tools generally, is the subject of the breakdown of the three scoreboards for AI coding tools.

The moved-lines metric is also narrow. A developer who rewrites a function in place to remove duplication is refactoring, and GitClear may record it as updated rather than moved. If assistants make in-place rewrites easier, the refactoring decline is partly an artefact of the definition.

A technical debt dashboard for AI code: six metrics

The right response to a contested public dataset is to measure your own. Every metric below can be computed from your git history and standard tools. None requires buying GitClear, although it would automate several of them.

The warning signs are our suggested starting points, not thresholds drawn from GitClear or any study. Set your own after 8 weeks of baseline data.

The first five are leading indicators. They move before production does. The sixth is the lagging check that tells you whether the leading ones predicted anything. If duplication climbs for a year and change failure rate stays flat, your codebase may tolerate duplication better than GitClear's average, and that is worth knowing.

Split every metric by whether a commit was AI-assisted, where you can tell. Some teams tag commits or pull requests. Others use assistant telemetry. Without that split, you are repeating GitClear's correlation problem inside your own company.

How to read code churn metrics without gaming them

Any metric attached to performance gets gamed. Churn is especially easy to game: developers can batch their edits to avoid the two-week window. Duplication counts can be gamed by tweaking whitespace below the detector's threshold.

So keep these numbers at team level, never individual level. Use them to decide where to spend refactoring time, not to rank engineers. How individual criteria should change is covered in the piece on performance review criteria for AI-assisted work.

Read trends, not levels. A duplication density of any absolute value tells you little, because languages and frameworks differ. A density that doubled in two quarters tells you a great deal. Record a baseline before you roll out a new assistant or a new agent workflow, because that baseline is the only thing that turns these numbers into evidence.

Finally, treat the dashboard as a budget, not a verdict. Debt is a legitimate financing choice when you take it on deliberately. The problem GitClear describes is debt taken on without anyone noticing, and the dashboard fixes the noticing. Where the bill eventually lands is costed in the analysis of the cleanup bill for vibe-coded software.

I would not restrict AI assistants on the strength of this evidence. I would make them pay rent: every quarter, a fixed slice of the time they save goes to consolidation work, and the move share on the dashboard shows whether it happened.

Frequently asked questions

Where to start this week

Pull 12 months of git history for your busiest repository and compute one number for each quarter: copy/pasted lines against moved lines. If the lines crossed, you have your own version of GitClear's 2024 finding, and a concrete reason to schedule consolidation work.

Then turn on one linter rule that flags empty catch blocks and run it against the main branch. The count you get today is your baseline. Write it down before anyone has a reason to make it look better.

Related reading