Refactoring fell from 25% to 3.8%

TL;DR. 59% of DORA respondents report AI improving code quality, and a separate analysis found more AI enablement correlating with roughly 8% higher maintainability. GitClear, analysing 211 million lines of code over five years, reports the opposite: refactoring falling from 25% of changes in 2021 to under 10% in 2024 and 3.8% in early 2026, copy-pasted code rising from 8.3% to 15.7%, two-week churn from 3.1% to 5.7% and rising, and copy-pasted code exceeding moved code for the first time in the dataset's history. Both are accurate. One asks developers how it feels and the other counts what happened to the repository. And the reconciliation is where the time went: Stack Overflow found 66% of developers lose time fixing output that is almost right, which is a cost that lands after the survey question was answered.

---

Status: established, with the two literatures separated. DORA and DX are survey instruments with stated samples. GitClear is repository telemetry across 211 million lines. Several security figures come from vendors selling code scanning and are labelled where used. The two bodies of evidence are reported separately here rather than averaged, because averaging them would produce a number describing nothing.

---

What the surveys report

Google's DORA 2025 report, with a sample of roughly 5,000, found 90% of software teams using AI at work daily.

59% of respondents see AI improving code quality.

A separate analysis found that 25% more generative AI enablement correlates with roughly 8% higher code maintainability.

Adoption figures corroborate the scale. 90% of Fortune 100 companies have deployed GitHub Copilot, per Microsoft's chief executive on a July 2025 earnings call. Google and Microsoft have disclosed 20 to 30% AI-generated code in their own codebases, with Alphabet's chief executive confirming the figure publicly on a Q1 2025 earnings call.

These are real measurements of real things. Developers were asked and they answered.

What the repository reports

GitClear analysed 211 million lines of code across five years, measuring what changed rather than what people thought.

Refactoring fell from about 25% of code changes in 2021 to under 10% in 2024, and to 3.8% by early 2026.

Copy-pasted code rose from 8.3% of changed lines in 2021 to 12.3% in 2024, and from 9.4% in 2022 to 15.7% in early 2026.

Two-week code churn, meaning code revised within a fortnight of being written, rose from 3.1% in 2020 to 5.7% in 2024, and by a further 15% since.

Duplicate code-block frequency rose roughly eightfold year on year in 2024.

And a first in the dataset's history: copy-pasted code exceeded moved code, which is the signature of code being duplicated rather than reused, and is a structural shift away from modular design.

None of these is a survey response. They are counts of what happened to files.

Why both are right

The two literatures measure different objects and the difference is not subtle.

DORA and DX measure perception and organisational outcome. They capture whether developers feel more effective, whether teams believe quality improved, and how delivery metrics moved.

GitClear measures the artefact. It counts duplication, refactoring and revision in the repository, with no opinion involved.

A developer can accurately report feeling faster and more confident while the code they produced is more duplicated and gets rewritten sooner. Those are not contradictory claims. They are claims about different things that a reader has been treating as one thing.

And this is commissioned framing in a clean instance. Survey instruments are run by parties interested in organisational capability and developer experience. Repository telemetry is run by a party interested in code quality analysis. Neither commissions the other's question, and no party funds the study that would connect a developer's reported experience to the two-week churn on their own commits.

Where the time goes

The reconciliation is not that one side is wrong. It is that the cost moved.

Stack Overflow found 66% of developers losing time fixing AI output that is almost right but not quite.

That is the mechanism. Generation is fast and the correction arrives afterwards, frequently in a different session, sometimes in a different fortnight, and always after the moment anyone measured the speed-up.

Senior engineers in 2026 report spending 20 to 35% more time on code review where junior colleagues lean heavily on assistants.

Which is cost externality in a form the corpus has now seen repeatedly. The developer generating code captures the speed. The reviewer absorbs the check, the maintainer absorbs the churn, and the person who inherits the duplicated block in eighteen months absorbs the rest.

None of those costs appears in the measurement that produced the productivity claim, because the measurement was taken at the point of generation.

What DORA itself says about the direction

Worth quoting carefully, because DORA is often cited as the positive side and its own findings are more qualified than that.

The 2024 report found that generative AI improved capabilities typically associated with better software delivery performance, while also finding declines in software stability and throughput.

The 2025 report describes AI as an amplifier, magnifying existing organisational strengths and weaknesses, and finds that while adoption improves delivery throughput and individual effectiveness, it also increases software delivery instability, indicating that underlying systems have not evolved to safely manage AI-accelerated development.

That is not a positive finding with a caveat. It is a mixed finding reported as mixed, by the instrument most often cited for the optimistic reading.

The amplifier framing is the useful part and it predicts the divergence: an organisation with strong review, testing and architectural discipline gets faster. An organisation without them gets faster at producing code that needs rewriting, and both show up as adoption success.

The security figures, and their provenance

These come from vendors selling code scanning and should be weighted accordingly.

Veracode reported 45% of AI-generated code containing a security vulnerability, across 80 coding tasks on more than 100 models.

CodeRabbit analysed 470 open-source pull requests, 320 AI-coauthored and 150 human-only, and found AI-generated code carrying 2.74 times more security vulnerabilities.

Apiiro tracked a tenfold increase in AI-assisted security findings over six months from December 2024 to June 2025, across more than 7,000 developers and 62,000 repositories.

Academic and OWASP-referenced work puts 30 to 40% of AI-generated snippets containing at least one vulnerability of a recognised class.

Every one of those parties sells detection or remediation. The direction is consistent across independent vendors and across an academic range, and the magnitudes should be read as indicative. The GitClear telemetry is the more reliable structural finding and the security numbers are the surrounding context.

What a leader should measure instead

The measurement most organisations take is the one that shows the best result, and the alternatives are known.

Seats activated and suggestions accepted show that a tool was opened. Neither connects to an outcome, and both are what vendor dashboards report by default.

Production-merged AI-authored code as a share of shipped code is the version that connects to delivery.

And the quality signals that catch the downstream cost are churn and duplication, because they surface in a fortnight rather than in eighteen months.

One framing is worth stating exactly: a leader tracking lines generated or seats activated sees a triumph, and a leader tracking cycle time and change-failure rate sees a plateau. Those are the same organisation.

The practical addition is longitudinal. Incident rates on AI-touched code at 30 days, rework rates for AI-assisted pull requests, and review burden by team. All are computable from systems already in place, and almost nobody computes them.

The two instruments, side by side

Setting them out makes the incompatibility legible, and legibility is most of the work here.

The last row explains the first five.

Neither instrument is deficient. A survey cannot count duplicate blocks and telemetry cannot ask whether a feature shipped that users wanted. They are complementary instruments that were never pointed at the same population, and the reason is that no party benefits from the combined answer.

The missing study is specific and small. Ask developers how a change felt, then track the two-week churn on that exact commit. Same people, same code, both instruments. It would settle whether the perception gap is a measurement artefact or a real divergence, and it would take one engineering organisation one quarter.

That nobody has run it is the finding underneath the finding, and it is the third time this territory has arrived at the same place: the reconciling question sits between two well-funded literatures and belongs to neither.

What the corpus already found, arriving again

This is now the third distinct subject where a self-report and a measurement of the same activity point in opposite directions.

Developer productivity: developers estimated they were 20% faster with AI assistance and were measured 19% slower on the same tasks in the same study.

Enterprise AI benefit: 97% of executives report benefiting while 29% report significant organisational return.

And code quality: 59% report improvement while refactoring falls to 3.8% and churn rises.

In all three the self-report is more favourable than the measurement, and in all three the self-report is the figure that circulates.

The mechanism is consistent and it is not dishonesty. Effort saved is felt at the moment it is saved. Cost incurred later, by someone else, or diffusely, is not felt at all, and a person asked how something went reports the part they experienced.

Which suggests a general rule this corpus can state after three instances: where a technology moves effort in time or across people, self-report will overstate benefit by roughly the amount that was moved, and the only correction is an instrument that observes the artefact rather than the operator.

The rule is falsifiable. A subject where self-report and measurement agree, on an activity where costs are deferred or displaced, would break it. None has appeared in this corpus yet, and the absence is worth watching rather than celebrating, since three instances chosen partly for being interesting is a weak sample.

Three things this establishes

Perception and telemetry are different instruments and neither substitutes for the other. 59% reporting improved quality and refactoring falling to 3.8% are both true. A reader who has seen one has half the picture, and the halves were measured by parties with no reason to run the other's study.

The productivity gain and the quality cost are separated in time, which is why one is measured and the other is not. Generation happens in a session and the correction arrives in a fortnight. A measurement taken at the point of generation is structurally incapable of seeing the second.

And the amplifier framing explains the spread better than any average. AI accelerates whatever an organisation already does. Where review and refactoring discipline exist, output improves; where they do not, the same tool produces more code that needs rewriting, and both organisations report high adoption.

What it does not establish

That AI coding assistants do not help. Adoption at 90% of teams with sustained use is not what a useless tool produces, and DORA finds real throughput gains.

That GitClear's telemetry proves causation. It correlates with AI adoption across the same period and does not isolate it from other changes in how software is written.

That the security figures are precise. They come from parties selling remediation, with a wide range across sources.

And nothing about any individual team. The amplifier finding says specifically that the outcome depends on organisational conditions this article cannot observe.

What is unresolved

Whether the churn resolves or accumulates. Two-week revision is visible now. Whether duplicated code written in 2024 becomes a maintenance problem in 2027 is not yet observable, and that is the claim the debt argument rests on.

Whether tooling closes the gap. Review automation, test generation and architectural linting are all being applied to the problem AI created, and no before-and-after measurement exists.

What the review burden actually is. The 20 to 35% figure is self-reported by senior engineers, and nobody has measured reviewer time directly.

And whether any organisation connects the two. The study that would settle this asks developers how a change felt and then tracks the two-week churn on that specific commit. It requires both instruments on the same population and nobody runs it.

What the disclosed internal figures suggest

Two numbers from companies that build both the tools and large codebases are worth separating from the vendor material, because they are disclosed against no commercial interest in particular.

Google and Microsoft have both disclosed 20 to 30% AI-generated code in their own codebases, with Alphabet's chief executive confirming the figure on a Q1 2025 earnings call.

That is a useful anchor for three reasons. It is an actual measurement rather than a survey. It comes from organisations that would look better with a higher number and did not report one. And it describes the ceiling under near-ideal conditions: unlimited tool access, strong review culture, extensive test infrastructure, and engineers who build the models.

Which reframes the adoption figures. 90% of teams using AI daily and 20 to 30% of code being AI-generated at the organisations best positioned to push that share are not in tension. Usage is near-universal and the contribution to shipped code is a minority share, even where every condition favours it.

The amplifier framing predicts exactly this. Strong organisations get real gains inside a bounded share of the work. The share is bounded by review capacity rather than by generation capacity, which is the constraint the churn and duplication figures describe from the other side.

And it suggests where the ceiling sits for everyone else. An organisation with weaker review, less test coverage and no architectural linting has less headroom, not more, because the binding constraint is the same one and its capacity is lower.

None of which is a prediction. It is an observation that the most favourable available conditions produced a minority share, disclosed by parties who could have framed it otherwise.

The counter-argument

Treating GitClear as the objective side is too generous. Copy-paste and refactoring rates are proxies for quality, not measurements of it, and duplication is sometimes correct. A codebase with less refactoring may be one where the architecture stabilised, and reading these metrics as unambiguous decline embeds an assumption about what good code looks like.

The surveys may capture something the telemetry cannot. If developers ship more features that users value, a rise in duplication is a price rather than a failure. Nothing in the repository data measures whether the software did more, and delivery throughput is the outcome an organisation is actually buying.

The timing argument cuts both ways. If the quality cost arrives in a fortnight, it is inside most measurement windows and should already be visible in change-failure rates. The eighteen-month technical debt claim is the one with no evidence, and it is doing significant work in most commentary including some of this article's framing.

And the security comparisons have a selection problem. AI-coauthored pull requests are not randomly assigned; developers reach for assistants on particular kinds of work. A 2.74 times vulnerability ratio may reflect what people use AI for rather than what AI produces, and none of the cited analyses controls for it.

The short version

Survey evidence and repository telemetry point in opposite directions and both are accurate. DORA reports 90% of teams using AI daily and 59% seeing improved code quality, with separate analysis linking more enablement to roughly 8% higher maintainability.

GitClear, across 211 million lines and five years, reports refactoring falling from 25% of changes in 2021 to under 10% in 2024 and 3.8% by early 2026, copy-pasted code rising from 8.3% to 15.7%, two-week churn from 3.1% to 5.7% and rising, and copy-pasted code exceeding moved code for the first time in the dataset's history.

The reconciliation is that they measure different objects. One asks developers how it feels; the other counts what happened to files. A developer can accurately feel faster while producing code that gets rewritten sooner.

And the cost moved rather than vanished. 66% of developers lose time fixing output that is almost right, and senior engineers report 20 to 35% more review time where juniors lean on assistants. The speed is captured at generation and the correction lands later, on someone else, after the measurement was taken.

DORA's own framing is the most useful. Its 2024 report found improved delivery capabilities alongside declines in stability and throughput, and its 2025 report describes AI as an amplifier that improves throughput while increasing delivery instability. Whatever an organisation already does, it now does faster.

Common questions

Do AI coding assistants improve code quality? The two available kinds of evidence disagree and both are accurate. DORA's 2025 report, with a sample of roughly 5,000, found 90% of teams using AI daily and 59% of respondents seeing improved code quality, and separate analysis linked greater enablement to around 8% higher maintainability. GitClear's telemetry across 211 million lines found refactoring falling from about 25% of code changes in 2021 to 3.8% by early 2026, copy-pasted code rising from 8.3% to 15.7%, and two-week churn rising from 3.1% to 5.7% and further since.

How can both be true? Because they measure different objects. Survey instruments capture perception and organisational outcome: whether developers feel more effective and whether teams believe quality improved. Repository telemetry counts duplication, refactoring and revision in the files themselves. A developer can accurately report feeling faster and more confident while the code produced is more duplicated and gets rewritten sooner. These are claims about different things that readers have been treating as one.

Where does the productivity go? Downstream, after the measurement. Stack Overflow found 66% of developers losing time fixing AI output that is almost right but not quite, and senior engineers in 2026 report spending 20 to 35% more time on code review where junior colleagues lean heavily on assistants. Generation happens in a session and the correction arrives afterwards, often in a different fortnight and always after the point at which anyone recorded a speed-up.

What does DORA actually say? More qualified things than its optimistic citations suggest. The 2024 report found generative AI improving capabilities typically associated with better delivery performance while also finding declines in software stability and throughput. The 2025 report describes AI as an amplifier magnifying existing organisational strengths and weaknesses, finding that adoption improves throughput and individual effectiveness while increasing software delivery instability, because underlying systems have not evolved to manage AI-accelerated development safely.

What about security? The figures are consistent in direction and come from interested parties. Veracode reported 45% of AI-generated code containing a security vulnerability across 80 tasks on more than 100 models. CodeRabbit analysed 470 pull requests, 320 AI-coauthored and 150 human-only, finding 2.74 times more security vulnerabilities in AI-generated code. Apiiro tracked a tenfold rise in AI-assisted security findings over six months across 7,000 developers and 62,000 repositories. Academic and OWASP-referenced work puts 30 to 40% of snippets containing a vulnerability of a recognised class. Every commercial source sells scanning or remediation.

What should an engineering leader measure? Not seats activated or suggestions accepted, which show only that a tool was opened. Production-merged AI-authored code as a share of shipped code connects to delivery. Churn and duplication surface the downstream cost within a fortnight rather than in eighteen months. Longitudinally, incident rates on AI-touched code at 30 days, rework rates for AI-assisted pull requests, and review burden by team are all computable from systems already in place and almost never computed.

Is the technical debt argument established? No, and it is the weakest part of the case. Two-week churn is measured and visible. Whether duplicated code written in 2024 becomes a maintenance crisis in 2027 has not been observed, because the period has not elapsed. That claim does substantial work in commentary on this subject, including in some framings of it here, and it currently rests on inference rather than evidence.

What is the strongest objection to reading the telemetry as decline? That copy-paste and refactoring rates are proxies for quality rather than measurements of it. Duplication is sometimes correct, and a codebase with less refactoring may be one whose architecture stabilised. There is also a selection problem in the security comparisons: AI-coauthored pull requests are not randomly assigned, developers reach for assistants on particular kinds of work, and a vulnerability ratio may reflect what people use AI for rather than what AI produces.