Code turnover is the percentage of lines changed in a merged pull request (PR) that later PRs change again or delete within 90 days, and it’s Weave’s measure of rework and code stability. Weave doesn’t calculate a technical debt score, so treat code turnover as one quality signal alongside bug ratio, bugs introduced, and reverted PRs.
How it works
Code turnover quantifies the amount of code that is reworked or removed after it’s merged.
To calculate it, Weave will:
- Note all the lines changed in the PR (ignoring meaningless lines like whitespace, brackets, etc.)
- For every subsequent PR, note any cases where a line from the initial PR is changed or deleted.
- Special case: if a line is moved within the same file in a later PR, that change is ignored;
so if that line is later deleted, it will count as code turnover for the original PR. Moving a
line into a different file counts as turnover.
- Calculate the ratio of changed lines to total lines.
For example, if a PR has 100 lines changed, and 20 lines are changed or deleted in a later PR, the
code turnover is 20/100 = 20%.
We only count code turnover within 90 days of the initial PR.
Is code turnover bad?
Not necessarily! It depends on the situation.
For example, if a team is working on an experimental feature and releasing it behind a feature flag,
it is normal and even expected to significantly rework that code before shipping it to all users. In
that case, a higher code turnover is expected.
Code turnover is most interesting as a relative metric. For example, if a single team has
significantly higher turnover than other teams, that team might need to improve their code review
process or test coverage.
Common questions
Does code turnover predict technical debt?
Not on its own, and Weave doesn’t forecast technical debt. High turnover shows code that had to be reworked soon after merge, which can point to gaps in code review or test coverage, but some rework is expected on experimental work (see when turnover is expected). To hear from engineers directly, developer experience surveys include a preset question on the complexity, technical debt, and maintainability of the codebases they work in.
What other code quality metrics does Weave track?
Bug ratio is the share of code output spent on bug fixes, bugs introduced traces fixed bugs back to the commits that caused them, reverted PRs counts PRs that undo earlier changes, and review quality scores how much value each code review adds.
Can I see how much work goes to maintenance?
Yes. Weave categorizes every PR as feature, bug, or KTLO (keeping the lights on), where KTLO covers maintenance such as refactoring, performance work, and tests. See PR categorization.
Does AI-written code get reworked more?
You can check. AI code turnover weights turnover by the AI share of output and is one axis of AI skills, the Model comparison table on the AI report shows AI code turnover for each model, and code turnover is a component of the AI efficiency index.
How does our code turnover compare with other companies?
Code turnover is benchmarked against organizations of a similar size, or in your industry if an admin selects it. See benchmarks. Last modified on October 17, 2026
