Copy-paste velocity

A thought experiment. You run a delivery company. One day, your drivers discover they can hit their package-per-hour targets much faster with a simple trick: whenever a route is confusing, they just… drive the package back to the warehouse and re-enter it as a new delivery. Packages scanned per hour: way up. Vans in motion: constantly. The dashboard is a wall of green.

Packages actually arriving at houses: mysteriously flat.

If your engineering metrics are lines shipped, PRs merged, or story points burned, I have some difficult news about your vans.

Velocity is a direction word and we use it as a speed word

Physics pedantry, but it's load-bearing: speed is how fast you're moving; velocity is how fast you're moving toward somewhere. Engineering borrowed the word velocity and then quietly measured speed. Lines, commits, merges — all of it counts motion. None of it counts direction.

This was always a bit broken, but it used to be broken safely, because motion was expensive. When every line cost a human minutes of typing and thinking, nobody produced much motion that wasn't at least aimed somewhere. Code volume was a rough proxy for progress the same way calorie expenditure is a rough proxy for exercise — imperfect, but hard to game by accident.

Then the cost of motion went to approximately zero, and the proxy snapped.

The people who actually counted

The most honest large-scale numbers on this come from GitClear, who analyze hundreds of millions of changed lines across real repositories, year over year, specifically to see what AI assistance is doing to the composition of code changes. Their AI code quality research found a pattern that should be read aloud at every sprint review:

• Churn is rising. A growing share of lines get shipped and then modified or reverted within weeks — GitClear projected churn roughly doubling in the assistant era versus the pre-AI baseline. Code that needs immediate rework isn't progress; it's motion that came back to the warehouse.
• Copy-paste is beating reuse. In their data, duplicated blocks and copy-pasted lines have been climbing while moved lines — the signature of refactoring, of code being consolidated into shared abstractions — decline. In 2024 they measured, for the first time in their dataset's history, more copy-pasted lines than moved lines. The autocomplete makes it easier to accept a fresh duplicate than to go find the function that already exists.

Sit with that second one, because it's the quiet catastrophe. Refactoring — the activity that turns motion into direction, that compresses ten similar things into one good thing — is declining as a share of all code activity, at exactly the moment total code activity is exploding. The industry is producing more code and less structure. More miles, fewer deliveries.

And the system-level echo showed up right on schedule: the 2024 DORA report found teams with higher AI adoption reporting reduced delivery throughput and stability — individual developers feel faster, the organization measures slower. That's not a paradox. That's what it looks like when speed goes up and velocity doesn't.

Where the miles actually go

So if teams are shipping 5x the code and not arriving 5x anywhere, where does the difference go? It goes into the codebase, as mass. Every duplicated helper, every regenerated-instead-of-refactored module, every plausible-but-redundant utility is a line that must now be maintained, secured, understood (ha), migrated, and paid for, forever.

Ward Cunningham's original 1992 debt metaphor was precise in a way its casual users forget: the danger was never the borrowing — it was the interest, the ongoing tax on every future change that touches the not-quite-right code. Copy-paste velocity is a machine for writing loans. Each duplicate is a tiny bond issue: near-zero cost today, a coupon payment every time either copy changes and someone has to know the other copy exists. (Nobody knows the other copy exists. That's what made it a duplicate.)

The cruelty of the mechanism is that the interest is invisible in the metrics that created it. The sprint that shipped the duplicate looked great. The sprint eight months later that mysteriously took three weeks to change a price calculation — because the calculation existed in four places, two generated, one subtly different — just looks like your team getting slower. Nobody connects the two sprints. The dashboard has no line for "we are now driving through our own traffic."

(And notice who gets blamed when that second sprint drags: the engineers working it, who are — this is the darkly funny part — the only people in the building actually paying down the loan. The person who shipped the duplicate got a great quarter out of it. The person consolidating four price calculators into one gets a burndown chart that looks like failure. Your incentive system is now structurally rewarding the borrowers and punishing the repayers, and it will keep doing that for exactly as long as motion is the thing you measure.)

The gut-check questions your dashboard can't answer

Try these on your last quarter:

1. Of the code shipped, how much was still in production, unmodified, ninety days later? (Churn check.)
2. How many of your functions do substantially the same thing as another function nobody looked for? (Duplication check.)
3. Is the time-to-change for a typical small feature going down — the thing all this velocity was supposed to buy — or quietly up? (Interest check.)
4. If your team shipped 5x the lines this year, is your product 5x anything? Revenue? Capability? Anything at all?

Question four is the one that ends meetings. Because everyone can feel the honest answer: the lines went up 5x and the product got — some better. The delta between those two numbers is pure warehouse-driving, and it's compounding.

Here's the detail that makes this era genuinely different from ordinary bloat, though: the dead weight doesn't just cost storage. In METR's 2025 randomized study, experienced developers using AI assistance on codebases they knew intimately came out measurably slower — while believing the opposite. One reading among several: the assistants' output imposes a comprehension tax on people who already held the map, and the map itself is being redrawn faster than anyone can read it. Volume isn't just failing to help. Past some point, it's the thing in the way.

Measuring arrival instead of motion

None of this argues for shipping less, exactly. It argues for metrics that can tell the difference. Motion metrics — lines, merges, points — are now strictly gameable by a machine that games them by default. What's left that can't be faked? Behaviour. A function that runs in production, gets called, succeeds, and carries real traffic is a delivered package regardless of who wrote it or how fast. A function that shipped and is never called is a warehouse loop with a commit hash. (In CodeNSM's own fleet telemetry, that distinction is stark and routine: sizable shares of shipped functions turn out to be dormant — payroll with no output — and the number is a far better honesty test than any velocity chart, because production doesn't care how productive your quarter felt.)

The teams that navigate this era won't be the ones that ship the most code. They'll be the ones that can look at their codebase and answer, function by function, the delivery company's only real question:

Did the package arrive?

Everything else is engine noise.