Rework Rate: The Productivity Metric That Doesn't Lie

TL;DR: Most productivity metrics can be gamed by shipping more. Rework rate is the one that catches it: the share of freshly written code that gets rewritten within weeks of merging - work you paid for twice. It comes straight from git history, it needs nobody's self-assessment, and it is quietly rising across the industry as AI assistants raise output volume. Measure it with a fixed definition, trend it against your own baseline, and treat a climb as an early invoice for technical debt.

What is rework rate?

Rework rate is the percentage of recently authored code that gets modified or deleted within a short window (commonly two to four weeks) of landing. The intuition is simple: code that ships and survives was probably right; code that ships and gets rewritten fourteen days later was a draft you paid production prices for.

That is what earns it a place in the engineering economics toolkit rather than the vanity-dashboard drawer. Every reworked line is an engineer-hour spent twice, at fully loaded cost both times. Unlike survey-based waste estimates, this one is computed from what the repository actually recorded. Delivery volume can be inflated by splitting PRs and gold-plating tickets; the fact that last sprint's code needed redoing this sprint cannot.

Churn vs rework vs refactoring: definitions matter

Three things look identical in a diff and mean opposite things. Getting them straight is most of the job:

• Churn is the umbrella measurement: any code changed shortly after being written.
• Rework is the bad slice: recent code being redone because it wasn't right. Wrong behavior, wrong shape, immediately regretted.
• Refactoring is the good slice: existing code being moved and consolidated to improve structure without changing behavior.

A team doing heavy healthy refactoring and a team drowning in fix-forward rework can post the same raw churn number. This is exactly where the industry data gets alarming: GitClear's analysis of 623 million code changes found moved-code operations - the signature of refactoring - collapsing from 21% to 3.8% of changes, while code-block duplication rose 81% and two-week churn rose 15% in the AI-assistant era (GitClear, 2026).

Churn up while refactoring is down means the churn is not cleanup. It's rework. Faros AI's 2026 AI Engineering Report adds the confirming symptom: bugs per developer up 54% at high AI adoption (Faros AI). More on that mechanism in AI code churn.

How to measure rework rate

The metric is only as trustworthy as its definition is fixed. Four rules:

1. Pick a window and freeze it. Two, three, or four weeks are all defensible; changing the window changes the number, so choose once and write it down. Determinism is the point: the same history must always produce the same rate.
2. Exclude the noise. Generated files, lockfiles, vendored code, and formatting-only sweeps will otherwise dominate the signal. Publish the exclusion list alongside the number.
3. Separate moves from rewrites where your tooling allows. Code relocated intact is refactoring; code deleted and replaced is the expensive kind. If you can't separate them, at least annotate known refactoring pushes so they don't read as regressions.
4. Slice by codebase area, not by person. The question rework answers is where does work not stick: which module, which kind of change, which intake path. That's a systems question, and per-area slicing is where the fixes are findable.

A healthy rework rate, honestly

Here is the honest answer most vendor content dances around: there is no universal healthy band, because the number is a function of the window and exclusions you chose. A "12%" under one definition and a "25%" under another can describe the same team. Any benchmark quoted without its measurement definition attached is decoration.

What is honest and useful:

• Your own trend under a frozen definition. Six months of your own history gives you a baseline; the signal is the direction and the outliers, not the absolute level.
• Known causes of a climb. Rushed scoping, vague requirements, review theater, a volatile hotspot module. And, per the data above, high-volume AI-assisted output merged faster than it's understood.
• The debt connection. A rising rework rate is technical debt being created and serviced in the same month, the leading indicator for everything in The Real Cost of Technical Debt, and one of the delivery signals worth watching continuously alongside the core delivery metrics.

Caveats: when rework is fine, and when the metric turns toxic

Two honest limits. First, some rework is healthy. Prototypes, spikes, genuine iteration on a hard design: redoing that code is the process working. A team with near-zero rework may just be a team that never attempts anything uncertain. Judge the rate against the kind of work, not against zero.

Second, rework rate is a systems instrument, not a personnel one. High rework in someone's area usually indicts the inputs they were given - requirements, review, the state of the module - and using it as an individual score both misreads the signal and teaches people to stop touching risky code, which is how debt compounds in silence. Keep it at team and codebase level, where it stays unfakeable and fixable.

The door

Compute one number this week: the share of code from the last quarter that was rewritten within a month of merging, under a definition you write down. Then look at where it concentrates. One team, one module, or one kind of ticket will jump out - it almost always does - and that's not a verdict, it's a map. Fix the intake, the review, or the module, re-measure next quarter, and you'll have the rare productivity story that comes with before-and-after receipts.