GitHub Adds an Addressed Rate for Copilot Reviews. What It Measures

GitHub’s latest Copilot reporting adds a number many engineering leaders have wanted: how often people act on code-review feedback from the assistant. The new copilot_code_review object in repository-level daily reports includes evaluated comments, comments developers addressed, and a breakdown by severity, review tier, comment type, and customization. It also counts reviewed pull requests merged without a later human change request.

The useful caveat is in the definition. A comment is “addressed” if a developer applied the suggestion, made the fix manually, asked Copilot to make it, or replied that the fix will arrive in a later pull request. The count is evaluated when a pull request merges, so it appears on the merge day rather than the day the comment was posted. A reply promising future work can therefore count as addressed even though the code change is not in that pull request.

A response metric, not a quality score

Dividing addressed comments by evaluated comments gives a response rate. It does not tell a team whether the assistant was right, whether the developer’s change was necessary, or whether an unaddressed comment was wrong. It also does not measure whether the final change introduced a different defect.

That distinction matches a broader research finding. A July 2026 study of agent-generated review comments across open GitHub repositories found that developers sometimes left comments unresolved because suggestions were incorrect or conflicted with intentional design choices. The authors also found that concise, actionable suggestions were more likely to be resolved. The study covers a sampled set of Python repositories and several agents; it is not a benchmark of this new GitHub metric, but it illustrates why “acted on” and “useful” are different concepts.

GitHub’s total_merged_no_human_change_request_after_review is another signal, not an approval stamp. It counts reviewed pull requests merged without a later human request for changes after the first Copilot review. Some may be straightforward changes; others could have been reviewed elsewhere or merged under a team’s chosen process. GitHub notes that bot pull requests are generally not evaluated for comments, while this merged-pull-request count still includes them.

How teams can use the report

Use the fields to spot questions worth investigating, not to rank developers or set a target that rewards quick agreement. Break results down by repository, severity, review tier, comment type, and custom instructions. Then sample the underlying discussions: Were high-severity findings fixed? Did developers explain why they disagreed? Did a suggested patch pass the project’s normal checks?

A team can compare trends before and after changing review instructions, but the report alone cannot establish that the instructions caused a change. Repository mix, pull-request size, review tier, and the kinds of code being reviewed also affect the data. Keep a human reviewer accountable for final decisions and measure downstream outcomes separately, such as escaped defects or reverted fixes.

Access is also scoped. GitHub says the fields are in enterprise and organization repos-1-day reports; the Copilot usage metrics policy must be enabled, and the user needs the relevant metrics permission. The Copilot metrics API docs describe report access, while our coverage of Copilot’s Xcode integration follows another recent change to the developer workflow.

The new addressed rate makes feedback activity more visible. Its best use is to identify where to ask better questions—not to turn a developer’s agreement into a proxy for code quality.