PR rework rate

The PR rework rate report shows the percentage of eligible merged pull requests with a commit after a reviewer explicitly requested changes. Use it to see how often review feedback is followed by another commit and to find PRs worth investigating.

Note: A post-request commit is a signal of rework, not proof that the commit addressed the reviewer’s feedback or that the original code was low quality. Differences between groups do not establish that AI, a tool, or a workflow caused the change.

When to use PR rework rate

PR rework rate answers the question: What share of eligible merged PRs had a commit after a reviewer requested changes?

This report helps teams:

  • Compare cohorts — Check whether PRs from two comparable groups are followed by post-request commits at different rates.
  • Monitor review outcomes — Track whether this pattern increases or decreases over time.
  • Inspect individual PRs — Open the reworked PRs behind a chart point to understand what changed after the request.
  • Choose the next investigation — Look for differences by team, repository, or AI code percentage band that merit closer review.

Do not use the rate alone to judge code quality, reviewer effectiveness, or the impact of AI.

How PR rework rate is calculated

DX calculates the metric as:

Eligible merged PRs with a qualifying change request followed by a commit before merge ÷ all eligible merged PRs × 100

A PR counts once in the numerator if it has at least one qualifying change-request review and a non-deleted commit created after that review and no later than the PR’s merge time. Multiple change requests or subsequent commits on the same PR do not increase its count.

Eligible PRs without this sequence remain in the denominator. DX divides the total number of reworked PRs by the total number of eligible PRs in the selected group; it does not average individual developers’ rates.

For example, if 12 of 100 eligible merged PRs had a commit after a qualifying change request, the PR rework rate is 12%.

What is included

The denominator includes PRs that:

  • Were merged in the selected date range
  • Are not drafts, bot-authored PRs, or deleted records
  • Belong to an accessible repository and have at least one non-deleted PR commit
  • Match the selected team or group, attribute, repository, and other report filters

For a change request to qualify, its review type must be Changes requested. Bot-authored reviews, reviews without a linked DX user, and reviews by the PR author do not qualify. The subsequent commit must belong to that PR and occur before or at merge.

The report requires source-control PR, review, and commit data. When PR commit data is unavailable, the standalone report shows a connection-required message instead of a rate. The report supports date, team or group, attribute, repository, aggregation, interval, and comparison filters, including AI code percentage bands where available.

Understand 0% and missing data

A value of 0% means eligible PRs were present but none met the full change-request-then-commit condition. It does not necessarily mean no reviewers requested changes; a request without a later recorded PR commit does not count. Missing review or commit coverage can also make the rate look lower than it should.

A missing value usually means there were no eligible PRs in the selected interval or group, or the result did not meet your organization’s reporting threshold. Compare PR volume and source-control coverage before interpreting differences between small cohorts.

Use the metric in comparison reports

PR rework rate is also available in Code review overview, AI pull request overview, Cohort analysis, AI impact, Cohort lifecycle impact, and Catalog analysis. It can also be added to supported group dashboards.

Keep date range, repositories, and work type comparable when comparing groups. A higher rate can reflect PR size, complexity, review practices, or data coverage, not just a difference in the code itself.

Inspect individual pull requests

Open a chart point or breakdown row to view the Reworked PRs drilldown. It lists the repository, PR title, author, merge date, and source-control link when available. The drilldown shows PRs that met the rework condition, not every PR in the denominator.

Review the change-request feedback and subsequent commits in your source-control system to understand what happened on each PR.

Turn the signal into action

  1. Choose comparable cohorts and apply the same date and repository filters.
  2. Check the rate alongside eligible PR volume and source-control coverage.
  3. Inspect representative reworked PRs and their review history.
  4. Look for differences in PR size, work type, reviewer practices, and tests before drawing a conclusion.
  5. Try a focused change to review or PR-sizing practices, then compare the same cohorts in the next period.