Code review gains a way to gather runtime evidence
GitHub expanded Copilot code review on September 11 from an assistant that primarily reads project files into a review system that can perform more checks on the code it examines. GitHub says the service now uses the full set of shell tools exposed by the Copilot SDK behind its agent firewall. That permits the review process to run build commands, execute tests, call targeted scripts and retrieve information from tools or APIs available in its environment. The result can be more informative than judging a change only from its text.
A diff can look reasonable while failing to compile, violating a generated-code contract or breaking an existing test. Giving a reviewer controlled access to the same forms of evidence that developers use can expose that mismatch. The change does not make every test meaningful or every build complete. It improves the reviewer's ability to ask a practical question: does the proposed change behave consistently with the executable evidence this repository makes available?
This is a move toward tool-using review, not autonomous proof. A passing test suite covers only the behavior encoded in that suite, and a command can succeed without detecting a security or logic defect outside its scope. GitHub describes the tools as operating behind the Copilot agent firewall, but the announcement does not publish an independent assessment of that boundary. Repository owners still determine which runners, instructions and connected systems are available to the review process.
Lite reviews now combine several agents
The second analysis change concerns how GitHub assembles a review. The Lite effort level now uses an ensemble of agents instead of relying on one agent. Each examines the change from its own perspective, after which Copilot combines the findings into one review. Parallel perspectives can reduce dependence on a single reasoning path and may surface different categories of concern without forcing users into the more expensive Balanced effort level.
GitHub reports encouraging internal results. In its experiments, the ensemble raised the average number of addressed comments per review by 47 percent for findings classified as high severity, 31 percent for medium severity and 11 percent for low severity. GitHub also reports an approximate 8 percent reduction in review cost. These are company measurements. The announcement does not provide the number or kinds of repositories tested, a comparison interval, confidence bounds or an independent reproduction.
The metric needs careful interpretation. An addressed comment is feedback that led to a recorded response in the development workflow. It is not the same as recall, precision, false-positive rate or prevented regressions. More high-severity comments being addressed could reflect more useful detection, better prioritization or changes in how developers interact with suggestions. The result supports the claim that the revised workflow attracted more action in GitHub's experiment. It does not establish how many defects the system missed or whether every accepted suggestion was correct.
Review threads become easier to maintain
GitHub also changed what happens after a developer responds. When a later commit addresses a Copilot review comment, Copilot can resolve that comment during its rereview while leaving feedback it considers outstanding open. This can reduce a familiar source of review noise: old threads that remain visible after the relevant code has changed. The open list becomes a more useful representation of unresolved work if the classification is accurate.
The condition matters. Automatic resolution rests on Copilot's judgment that the later commit handled the original concern. It is not a branch-protection rule, a test result or a formal proof that the issue disappeared. A mistaken resolution could hide feedback from the default view even though the underlying problem remains. Teams that use the feature still need the commit history, test results and human review needed to challenge that judgment.
A smaller convenience change generates a contextual commit message when a developer applies a suggestion from a Copilot review comment. Better descriptions can make a sequence of review-driven edits easier to understand than repeated generic messages. The text remains generated metadata. Developers remain responsible for confirming that it accurately describes the change before placing it in a durable project history.
The tool path depends on runners and budgets
GitHub's product documentation places the agentic parts of code review on GitHub Actions runners. Standard GitHub-hosted runners are the default, while larger hosted or self-hosted runners can be selected. If the required Actions workflow fails, a review can still be generated, but it will lack the additional agentic capabilities. Organizations that disable GitHub-hosted runners receive a more limited review unless they provide self-hosted capacity. The new shell access therefore depends on an execution environment, not just a model response.
The workflow also has two cost components. GitHub documents AI-credit consumption for the model interaction and Actions minutes for context gathering and tool use. Its current estimates place a Lite review between $0.05 and $1 in AI credits and a Balanced review between $0.25 and $5, excluding Actions minutes. Actual use varies with pull-request size, instructions and model evolution. Budget limits can block reviews, so broader analysis does not arrive as free background computation.
Coverage has explicit boundaries. GitHub lists dependency-management files such as package.json and Gemfile.lock, log files and SVG files among the formats excluded from Copilot code review. The purpose-built service also does not offer model switching, and its models are not governed by the organization's Copilot Chat model settings. Those constraints prevent an organization from treating a successful review as evidence that every changed artifact was examined under one chosen model policy.
Useful automation still needs accountable review
The September update connects three parts of a review cycle that are often separate: inspect a change, collect executable evidence and maintain the resulting discussion as new commits arrive. The shell tools make the first stage less dependent on static reading. The agent ensemble gives Lite reviews multiple reasoning paths. Automatic thread resolution can keep the remaining work visible. Together, these changes could reduce routine friction and help human reviewers spend attention on disputed or consequential changes.
They do not turn Copilot into a correctness authority. GitHub's own documentation says the service is not guaranteed to find every problem, can make mistakes and should be supplemented with human review. That warning is especially important when a tool can execute repository-defined commands or draw on repository instructions and connected services. More context can improve relevance while also making the effective review boundary dependent on configuration.
The strongest supported conclusion is narrower than the headline percentages. GitHub has built a more capable evidence-gathering and coordination layer around AI code review, and its internal experiment found more addressed findings at lower reported cost for Lite reviews. Whether that produces fewer production defects remains unmeasured in the disclosed evidence. Teams can evaluate the advance by comparing it against their existing review outcomes, but the September 11 release itself establishes a new workflow, not independent proof of software quality.