Pascal once apologised for a long letter - he hadn’t the time, he said, to write a shorter one. Hemingway’s iceberg was seven-eighths submerged; the art was what he omitted. An LLM does neither. It never revises - it generates once, at the customer’s expense, and moves on.
Now apply that to code.
Editing a line of code is the expensive kind of thought. To tighten a condition, or ‘thread a parameter’ through three call sites, you have to hold the old code in your head, understand why it is the way it is, and change it without breaking anything else. Generating a fresh block costs a model nothing at all. So when an AI assistant meets code it doesn’t like, it does not do the expensive thing. It deletes the block and writes a new one. Observe an LLM coder (Claude Code or OpenAI Codex) for an afternoon and you can’t miss it: the AI never edits a line in place. Regeneration is its only move. Cut, and paste.
I measure this for a living, so I measured it.
Take two snapshots of a repository and classify every changed statement: added, deleted, or edited in place. The share edited in place is the rework rate* - the repair (editing/changing existing code via inline edits) signature indicative of human maintenance. Across 136 of the largest public codebases and 393 million churned statements, mature human-maintained projects - curl, PostgreSQL, Express - ‘rework’ was measured at around one statement in six. An intensively agent-built codebase I measured reworked one in five hundred logical statements (CHG_LLOC).
Not a modest shift. A ninety-fold collapse by the LLM to make inline edits.
* REWORK, defined: between two snapshots of a repository, every changed logical statement is classified added (ADD), deleted (DEL) or changed in place (CHG). REWORK = CHG ÷ (ADD + DEL + CHG) — the edited share of total churn, reported as a percentage. The term and method are CodeDelta’s, specified fully in the REP_CHURN paper.
I am not the only instrument pointing this way. GitClear ran hundreds of millions of changed lines through their own analysis and watched refactored§ lines fall from 24.1% to 9.5% between 2020 and 2024 - the first year in their data that copy-pasted code overtook refactored code. Veracode pushed the output of more than a hundred code models through security analysis and 45% of it failed. Fast, fluent, plausible - and nobody paid for the cutting.
§ Refactored is GitClear’s term and category, not mine: in their method a line counts as refactored when existing code is moved or restructured rather than newly written. Their definition, method and data are in the study referenced below.
Here is what it looks like up close. A pull request lands: four hundred new lines, tests green, description immaculate. Nothing was edited - the old function is simply gone, a new one in its place. Six months later a bug surfaces in that code. Does anyone edit it? No - nobody understands it well enough to edit it, including the tool that wrote it. It gets regenerated again. The codebase grows a layer of code that has never been repaired by anyone, human or machine, and each regeneration resets the clock on understanding it. That is what cut-and-paste garbage means. Not that the code doesn’t run. That nobody has ever had to understand it enough to change it - and at one edit per five hundred statements, nobody is starting now.†
† None of this says don’t use AI coding. It can be fast and, on a good day, awesome. It says the output needs what every fast production line has needed since production lines existed: supervision, measurement and quality control.
There is a strong objection and it deserves a straight answer: maybe repair is obsolete. If regeneration is free, why maintain code at all - throw it away and generate again, the way we stopped darning socks. Perhaps. But every codebase that pays your salary is maintained, not regenerated: the decade of Kubernetes shows rework climbing year on year as the project matures, from 0.5% in its growth spurt to an all-time high of 11.6% this year. Maturity IS repair. A codebase at 0.19% is not mature software built fast. It is a first draft nobody paid to shorten, shipped.
You do not have to take my word for any of this, and that is the point. The rework rate is a diff and a division, computed from two commit hashes on your own repository. Run it on the code your AI tools wrote last quarter. If the number comes back healthy‡, you have evidence your process makes the expensive choice when it matters. If it comes back at half a percent, you have a pile of pasted garbage with green tests, and now you know.
‡ Healthy: within the measured bands for maintained software — mid-size mature projects rework about one changed statement in six; the largest codebases one in ten to one in twenty. Bands and method: the REP_CHURN paper and the REWORK baselines paper.
Concision is expensive. Complexity a choice.
The rework measurement in this piece is CodeDelta’s REWORK/REP_CHURN metric — statement-level churn from two snapshots of your own repository, on macOS, Linux and Windows, free to try. Download CodeDelta → or add it to every pull request.