When generating new code is nearly free, refactoring starts to feel optional. GitClear's 2026 data shows the share of changed lines that consolidate existing code falling while copy/paste climbs, and I read that pattern as technical debt in AI-generated code piling up where nobody books it. This guide covers what those measures count, why cheap generation tilts the mix, and how to put refactoring on the plan as a line instead of a virtue. It closes with the Refactoring Ledger, a free worksheet you run on last sprint using only your pull requests and your backlog.
What moved code, copy/paste and churn count
GitClear's report The Maintainability Gap (June 2026) classifies 623 million code changes from 2023 to 2026, drawn from GitClear's own customers and corporate open-source repositories. It is a vendor's data about its own customers, not a sample of the industry. GitClear and GitKraken sponsored it, and both offer in its recommendations to help teams track the signals it measures.
Moved code is GitClear's name for changed lines that relocate or consolidate existing functionality, the closest thing in its data to a refactoring signal. That share fell from 12.7% of changed lines in 2023 to 3.8% in 2026, year-to-date, which means the first five months of the year. What fell 70% is the moved share of changed lines, not the amount of refactoring. The sample grew a lot over those years, so read it as the mix of work shifting, not as teams refactoring less.
Copy/paste, in this report, means a line repeated three or more times inside a single commit. That share rose from 11.1% of changed lines in 2023 to 15.7% in 2026, year-to-date, up 41%. Block duplication, the rate of changed lines sitting in duplicated blocks of five or more consecutive lines, rose 81% over the same window, the highest level GitClear has recorded.
Churn is the measure to read carefully. In this report, two-week churn is the share of changes revised or reverted within two weeks of being written, computed for GitClear's customer repos only, and it rose from 16.1% in 2023 to 18.6% in 2026, year-to-date, a relative rise of about 15%. Almost all of that rise came in one step, from 2024 to 2025.
I don't treat churn as a score. Some quick rework is just a team getting a change right. GitClear's figures show the mix of work moving; they don't show why it moved.
Why cheap generation tilts the mix toward copying
GitClear's own explanation is that adding code to a new file takes almost no architectural understanding of the repo, while refactoring takes enough understanding to consolidate safely, and that AI assistants don't stop to consolidate patterns the way human developers do. That is GitClear's reading of its data, not a measured cause. Over the same years the sample grew and the mix of teams in it changed, and the data can't separate those changes from anything else.
I find the reading persuasive for a plain reason. Generating a new function can take seconds. Finding the one that already exists, understanding it and folding your need into it takes a conversation, and when one of those is nearly free, the other starts to feel optional.
Big Agile wrote about the diagnosis in April, in the vibe coding hangover that follows peak AI velocity, and about its cousin in August, in why review becomes the constraint once generation gets cheap. This guide adds two things those didn't: a price on the code an agent has to read, and a way to book the payments.
That price comes from one experiment. Giles Edwards-Alexander, CTO for Europe, Middle East and India at Thoughtworks, refactored one large file in a greenfield Rust app of about 150,000 lines, built and maintained by a single developer, over fifteen steps, and had a fresh agent make the same representative change at each step. In The Economic Benefit of Refactoring, published on martinfowler.com and his work rather than Fowler's, he reports that the change went from an estimated 159,564 input tokens to 27,360, 83% fewer.
He attributes the saving to the agent reading less code, not to there being less code. The largest file shrank from 17,155 lines to 3,695, while the data access layer as a whole went from 17,155 lines to 16,608; at the start the layer was a single file, which is why both begin at 17,155.
Read it narrowly. It is one change on one refactored file in one app, the tokens are estimated rather than metered, and the refactoring's own cost was not measured: he puts an upper bound of five million tokens on his total consumption, a figure that also covers creating the plan twice and designing the experiment, against a saving of 39.7 cents per change at his assumed $3 per million input tokens. It does not show that refactoring pays for itself. It does show that the code an agent has to read is part of what every future change costs.
One more finding from the same experiment matters for anyone hoping the tools will tidy up after themselves. The agent did not refactor on its own initiative: the harness's explicit refactoring step did not prompt it to improve the file, and Edwards-Alexander then had Claude build a refactoring plan against Martin Fowler's book Refactoring and follow it. His conclusion is that a human needs to actively guide it.
Book refactoring as a line, not a virtue
I rarely see a team write its shortcuts down. A velocity chart books every feature as an asset and has no column for the liabilities that shipped with it: the copied function, the helper nobody consolidated, the module that got a little harder to change for the next person.
This framing extends Ward Cunningham's 1992 technical debt metaphor, from his OOPSLA experience report on the WyCash portfolio system: shipping first-time code is like going into debt, and time spent on not-quite-right code is interest on it. His debt gets repaid; he wrote that a little debt speeds development as long as it is paid back promptly with a rewrite. The debt that worries me is the kind nobody writes down, so nobody pays it back on purpose. A loan you didn't book still charges interest.
Refactoring sounds like rework to a lot of the stakeholders I work with: we already paid for that code, so why pay for it again? The feature still does exactly what it did. What the team is paying down is the cost of having built it fast, which is why I describe refactoring as debt service rather than cleanup.
To get it funded, I teach every team I work with in coaching engagements to plan its capacity in four lines: Roadmap, Minor Enhancements, Defects, and Engineering and Maintenance, where redesign, refactoring and upgrades live. I don't attach a magic percentage to the last one; the point is that nobody plans all of a team's capacity on new features, so the maintenance line is visible and funded on purpose instead of quietly squeezed. It is the same instinct as pairing every volume metric with a counterbalanced signal, which is how last week's guide treated AI ROI slides.
Not every refactor needs a line item. The everyday kind happens inside new work, in tens of minutes: you touch the code, you leave it a little better than you found it, and nobody needs to approve it. Ron Jeffries argues for this in his case for keeping refactoring off the backlog: refactoring belongs inside the work on each feature, improving the code where the team is already working. Refactor Mercilessly, the Extreme Programming practice, names the same discipline, and its wiki page opens with text Jeffries signed.
Larger redesigns are where I part company with Jeffries, who argues against putting refactoring on the backlog at all. When you open a module and find it needs rebuilding rather than tidying, that goes on the backlog as its own redesign item and gets ordered like everything else. GitClear's own first recommendation in its report is to budget for refactoring and legacy maintenance as first-class work, so booking it is not a Big Agile discovery; the four lines are how I put that budget on the plan.
Try this next week: run the Refactoring Ledger on last sprint
Run it with the team on one finished sprint, using only what you can see in its pull requests and its backlog. You don't need any code-analytics product. The ledger estimates the debt the sprint may have added, the duplication that came in and the refactoring that got skipped, so the team can see it and decide what to book next.
THE REFACTORING LEDGER
Run it on one finished sprint, with the team.
Use only what you can see in the sprint's pull
requests and backlog. No analytics product needed.
SPRINT: _____________________________________
1. COPIES ADDED
Pull requests that wrote logic that already
existed somewhere else, instead of reusing it.
Name each one and where the original lives.
Entries: ____________________________________
2. REFACTORS SKIPPED
Places someone said "we'll clean that up
later," in a review comment, a ticket, or out
loud in the room.
Entries: ____________________________________
3. FRICTION FELT
Changes that took longer than they should
have because of code nobody wanted to touch.
Name the file or the module.
Entries: ____________________________________
4. BOOK EACH ENTRY ONE WAY
Inside new work: the next story that touches
it folds it in, in minutes, not days.
Redesign item: too big for that. It goes on
the backlog as its own item and is ordered
like everything else.
Working agreement: the same kind keeps coming
back, so the team agrees to refactor
mercilessly wherever it works.
Let it ride: a deliberate loan. Write down
why, and the sprint you will look again.
Booking for each entry: _____________________
5. NAME THE CAPACITY LINE THAT PAYS FOR IT
Roadmap, Minor Enhancements, Defects, or
Engineering and Maintenance.
Line for each entry: ________________________
DONE WHEN: every entry has a booking and a line,
and no entry is booked as "later."ILLUSTRATIVE EXAMPLE. FICTIONAL.
COPIES An address-validation function copied
ADDED into the signup flow; the original
lives in checkout.
REFACTORS "Clean up the retry logic later," in a
SKIPPED review comment on a payments change.
FRICTION The pricing module. Stories ran long
FELT because nobody wanted to touch it.
BOOKING Address check: inside new work, the
next signup story folds it into one
shared home. Retry logic: working
agreement. Pricing: redesign item.
LINE Pricing: Engineering and Maintenance.
Address check and retry logic: the
Roadmap stories that touch them.Don't skip the friction section. It is the part a stakeholder can feel, because it shows up as changes taking longer, and it is the closest the ledger gets to showing interest as a line item.
When the same kind of entry keeps coming back, stop booking it one at a time and write the working agreement instead. When an entry goes to Let it ride, write down why; a deliberate loan is fine, and an unrecorded one is the problem. Speed that you don't refactor is not throughput. It's a loan with a hidden rate.