GitHub reports 47% more high-severity fixes and 8% lower cost from its new ensemble reviewer, its own numbers, not an independent audit.
GitHub says its Copilot code review ensemble catches more real bugs at lower cost. On September 11, 2026, Copilot code review's fastest, cheapest setting, Lite, switched from a single model to an ensemble of agents that also runs a project's own build, test, and script commands during review, and GitHub reported a 47 percent increase in high-severity findings developers actually addressed, a 31 percent increase for medium-severity, 11 percent for low-severity, and roughly 8 percent lower review cost. A week later, on September 18, the redesigned review experience behind those numbers reached general availability for everyone using Copilot code review.
Sources: GitHub Changelog: Auto-resolution and analysis updates in Copilot code review
Treating these as two separate claims helps, because they answer different questions. The September 11 update is about review quality: what the reviewer actually does to a pull request before it leaves a comment. The September 18 update is about review usability: how those comments get organized, resolved, and explained once a person reads them. Only the quality change comes with a number attached to it, and that number deserves more scrutiny than a changelog headline usually gets.
What did GitHub change about Copilot code review on September 11?
Before this release, Lite ran a single model over a diff and returned its findings. GitHub's changelog describes the new version as using multiple agents, each contributing its own perspective on the same change, with the results combined into one review. GitHub's own description of the outcome is direct: the ensemble approach made Lite reviews 'more thorough and accurate for the same or often lower cost.' That is a claim about combining independent judgments rather than trusting a single pass, the same logic behind running more than one reviewer against a diff instead of one, applied here inside a single product's fastest, cheapest tier.
Sources: GitHub Changelog: Auto-resolution and analysis updates in Copilot code review
The second change in the same release may matter more than the ensemble itself. Copilot code review can now reach the complete SDK shell tool set, running, in GitHub's words, 'behind the Copilot agent firewall.' In practice that means the reviewer can run build commands, run tests, execute targeted scripts, and pull information from other available tools and APIs, instead of only reading the diff as text and reasoning about what the code probably does when it runs. A reviewer that can execute a project's own verification catches a different class of problem than one that can only read a patch and guess at the outcome.
Sources: GitHub Changelog: Auto-resolution and analysis updates in Copilot code review
A concrete version of that difference: a pull request renames a function and updates every call site by hand except one, buried in a rarely touched integration test. A reviewer reading only the diff sees a plausible rename and forty consistent edits, with no strong reason to flag the one it missed unless it happens to read that exact file closely. A reviewer that runs the test suite gets a failing test back directly, regardless of how carefully it read any single file. That is the kind of miss tool execution catches by running a project's own checks instead of simulating them by reading code.
Running tools during review is not a free capability either. Executing build commands and scripts means the reviewer needs guardrails of its own, which is why GitHub specifies this running 'behind the Copilot agent firewall' rather than with unrestricted shell access. A reviewer that can execute code needs the same kind of containment an agent that writes code needs, for the same reason: the tool doing the checking is still a tool capable of running something it should not.
Sources: GitHub Changelog: Auto-resolution and analysis updates in Copilot code review
What improvements does GitHub report from the ensemble change?
GitHub attributes four concrete improvements to the ensemble and tool-execution changes together, broken out by severity tier below. Alongside the numbers, GitHub also reports a qualitative shift: developers left more positive feedback on Copilot's comments, and the system surfaced more high-severity findings while producing fewer nits.
Sources: GitHub Changelog: Auto-resolution and analysis updates in Copilot code review
| Severity tier | Change GitHub reports | Why it matters |
|---|---|---|
| High-severity findings addressed | +47% per review | The tier where a miss tends to become an incident, not a nitpick |
| Medium-severity findings addressed | +31% per review | A real jump, though GitHub does not define the medium versus high boundary |
| Low-severity findings addressed | +11% per review | Smallest gain of the three, which fits: low-severity issues were already easier for static analysis to catch |
| Review cost | about -8% | GitHub does not say whether this is compute, latency, or dollar cost, or measured per what unit |
These are self-reported numbers, published in the same changelog that announced the feature, measured against a baseline GitHub itself chose. No outside party has audited the sample size, the definition of an 'addressed' comment, or what counts as review cost. That does not make the numbers false. It means they deserve the same scrutiny any vendor's benchmark deserves before a team changes its process because of them, not the trust a specific percentage tends to buy on its own.
What the changelog does not say
The changelog does not disclose how many pull requests or repositories the comparison covers, whether the baseline is Lite before this exact change or a different effort level entirely, or how GitHub defines an addressed comment versus one a developer dismissed without acting on it. It also does not compare the ensemble's output against a competing reviewer working the same diffs, so there is no way from the changelog alone to know whether a 47 percent jump in high-severity fixes reflects a genuinely stronger reviewer or a previously weak baseline getting less weak. Both explanations are consistent with the same headline number.
- What is the sample: how many reviews, over what time window, across which repositories?
- What does "addressed" mean: a fix a human applied, a suggestion accepted with one click, or a comment simply closed?
- What is the baseline: the previous version of the same tool, or a claim relative to no automated review at all?
- Is the cost figure compute, latency, or a dollar number, and is it per review or per organization?
September 18: the review experience reaches general availability
A week after the quality change, GitHub rolled the redesigned review experience out to everyone using Copilot code review. The overview comment on a pull request now sorts every finding into one of three buckets: Open, for issues not yet addressed; Resolved since last review, where the changelog states Copilot 'has validated that you've fixed those issues it found earlier'; and Previously missed, for issues that were not introduced by a new commit but that a later pass caught on the existing changes. Ordering findings this way turns a flat comment list into a timeline of what changed between review passes.
Sources: GitHub Changelog: Copilot code review, an improved review experience
That third bucket deserves attention beyond the interface polish it looks like at first glance. Previously missed is Copilot's reviewer flagging, in the same overview comment a developer already reads, that an earlier pass on the same pull request did not catch something a later pass did. Most review tools do not surface their own past misses this directly. Whether that transparency changes how much a team trusts the tool, or simply makes visible a gap that was always there, is a question the changelog does not answer, but the bucket existing at all is a small, honest design choice.
Auto-resolution also got more specific. When Copilot decides a comment no longer applies, it now attaches a resolution reason, either Won't Fix or Incorrect, based on the commits that followed the original comment, instead of closing it with no explanation. And if a developer replies to a comment to say the issue should stay open, the changelog states plainly that Copilot 'honors that reply,' overriding what would otherwise be automatic resolution. That is a small feature with an outsized trust implication: a reviewer that can auto-close its own findings needs a way for a human to overrule it, and now it has one.
Sources: GitHub Changelog: Copilot code review, an improved review experience
The same release adds one convenience feature with no quality claim attached to it: when a developer accepts a batch of Copilot's suggested changes at once, GitHub now generates a commit title and an optional description based on what was actually selected, instead of leaving the developer to write one by hand for a set of edits they did not author line by line.
Sources: GitHub Changelog: Copilot code review, an improved review experience
Why this is not the same story as the PR size limit or org-wide agents
GitHub has shipped Copilot code review changes at a fast clip this year, and it is worth being specific about how this one differs from two recent ones. Removing the reviewer's file and line-count ceiling in late August changed what size of pull request the tool could process at all. Publishing custom agents organization-wide in late August changed where an agent definition lives and how far it can spread with no per-repo setup. This pair of releases changes neither size nor distribution. It changes how good a single review is on an ordinary, already-in-range pull request, and how clearly that review's findings get presented once a person opens the comment thread, which matters more the faster a team's agents produce diffs for a human to look at, the exact pressure behind keeping code review from collapsing as AI writes faster than people can read.
Do not switch a whole team to Lite-effort Copilot review purely because of the September 11 numbers. Run it on a sample of real pull requests from your own repositories first, count how many of its high-severity findings your team would have caught anyway, and compare that against whatever reviewer or process it would replace. GitHub's percentage describes GitHub's own before-and-after. It does not describe your codebase.
The self-reported-metric problem is not specific to GitHub. Every vendor building an AI code reviewer, including us, has an incentive to publish the number that makes the tool look good and skip the one that would not. The honest response is not to distrust every figure a vendor publishes. It is to ask what evidence would let someone else check the claim, and to notice, plainly, when a changelog stops short of providing it.
TLM Forge sidesteps the self-reported-percentage problem by not relying on one: a ship or no-ship decision comes from a gate that counts unresolved critical findings rather than a felt sense that review quality improved, and it stays at zero, not a number GitHub or anyone else gets to round up.
GitHub's two September releases are a real improvement to a widely used tool. An ensemble of agents that can run a project's own build and tests instead of only reading its diff is a genuine step past static analysis, and that mechanism is the actual news here. The specific percentages are still a vendor's own claim about its own product, unaudited, and worth treating as exactly that until someone outside GitHub checks them.
Frequently asked questions
01What did GitHub change about Copilot code review on September 11, 2026?
Copilot code review's Lite effort level moved from a single model to an ensemble of agents that combine separate findings into one review, and gained access to the full SDK shell tool set so it can run builds, tests, and scripts during review instead of only reading the diff.
02What improvements does GitHub report from the ensemble change?
GitHub reports a 47% increase in high-severity findings addressed per review, 31% for medium-severity, and 11% for low-severity, plus about an 8% drop in review cost and more positive developer feedback on Copilot's comments.
03Are GitHub's reported Copilot code review numbers independently verified?
No. They are GitHub's own figures from GitHub's own changelog, measured against GitHub's own baseline. GitHub has not published the sample size, the definition of an addressed comment, or any outside audit of these percentages.
04What changed in Copilot code review's UX on September 18, 2026?
The overview comment now sorts findings into Open, Resolved since last review, and Previously missed buckets. Auto-resolution attaches a reason, either Won't Fix or Incorrect, and the redesigned experience reached general availability that day.
05Can a developer stop Copilot from auto-resolving a code review comment?
Yes. GitHub's changelog states that when a developer replies to a comment to say the issue should remain open, Copilot honors that reply instead of auto-resolving it, overriding what would otherwise be automatic closure.