// answer

GitHub Copilot Code Review: Verdict or Effort Level?

Short answer

GitHub Copilot code review now shows an approval assessment and the effort level used. The verdict can approve pull requests in public preview, while effort level tells you how deep the review ran.

Other people are working this out at the same time: See what people are building

GitHub Copilot code review now gives an approval verdict or effort level

GitHub Copilot code review now gives both, not one or the other: an approval assessment and the effort level used for that review run. The approval assessment says whether Copilot thinks the pull request is ready to approve, while the effort level shows how deep the review ran. GitHub documents both behaviors in its Copilot code review docs and changelog.

The part people get wrong is treating the effort level like a verdict. It is not a yes or no answer. Lite and Balanced are review depths, with Lite aimed at routine changes and Balanced aimed at more complex or security-sensitive pull requests. The approval assessment is the separate signal that says whether Copilot considers the pull request ready to approve.

GitHub says every Copilot code review includes the approval assessment in the pull request overview comment. That assessment does not count toward merge requirements on its own. When approvals are enabled, Copilot can submit an approving review that satisfies a repository's required-approval rule, and a later push dismisses that approval just like a teammate's approval would be dismissed.

The effort level now shows up in the pull request overview comment and in timeline events. GitHub says that helps you see whether a review ran at Lite or Balanced. This is useful when teams want to compare review depth across repositories or confirm that a sensitive change got the deeper review path.

The inconvenient part is that the two signals answer different questions. Approval verdict asks, can this be approved. Effort level asks, how hard did Copilot look. A Balanced review can still decide a pull request is not ready, and a Lite review can still surface issues. Reading only the effort level tells you nothing about the outcome.

If you request a review manually, you choose the effort level in the pull request under the Reviewers section where Copilot appears. If your organization or repository has a default, automatic reviews inherit that setting unless a repo-level configuration overrides the organization default. GitHub also says existing configurations moved from the old Low and Medium names to Lite and Balanced.

The other thing people miss is that approval is still in public preview. GitHub says the approval feature is off by default and configurable at the enterprise, organization, and repository levels. That matters because a team can have Copilot code review enabled without having Copilot approvals enabled. In that setup, you still get the approval assessment, but not an actual approving review that counts toward merge rules.

For a practical read, use the effort level as context and the approval assessment as the decision signal. If the review says Balanced and still refuses approval, the change likely needed deeper scrutiny and did not clear it. If the review says Lite and approves, that is still an approval path, but it came from the lighter review configuration, not from a deeper analysis.

Here is the step that actually helps on a real team: open the pull request, look at the Copilot overview comment, then check whether you are seeing Lite, Balanced, or an approval assessment. If you need a stronger review for a sensitive change, request Balanced before asking Copilot again. If the repository default is not what you want, change the default at the repository or organization level.

If you want a place to coordinate human reviewers alongside Copilot, DevConnect keeps that work simple and free, and it stays focused on real testing exchange rather than paid shortcuts: https://devconnectplatform.com. For Copilot review itself, though, the useful takeaway is narrower, GitHub now surfaces both review depth and approval outcome, and they are not the same signal.

FAQ

Does effort level mean approval No. Effort level only tells you whether Copilot used Lite or Balanced for that review. Approval is a separate assessment and, when enabled, a separate approving review action.

Can Copilot's approval satisfy branch protection Yes, when approvals are enabled. GitHub says Copilot can submit an approving review that satisfies required-approval rules the same way a teammate's approval would. That feature is in public preview and off by default.

Where do I see which effort level was used GitHub says the pull request overview comment and timeline events show the effort level used for each review run. The docs also say you can choose the level in the pull request under the Reviewers section.

What changed from the old settings GitHub renamed the preview labels Low and Medium to Lite and Balanced. Existing configurations carry forward under the new names. GitHub also says the default review effort for some existing and new setups is changing from Lite to Balanced on September 28, 2026.

Should I use Lite or Balanced GitHub's docs map Lite to routine changes and Balanced to larger, more complex, or security-sensitive pull requests. Use the deeper setting when the code change has more risk or spans more services.

Sources - GitHub Blog, Copilot code review effort levels are generally available: https://github.blog/changelog/2026-08-07-copilot-code-review-effort-levels-are-generally-available/ - GitHub Docs, About GitHub Copilot code review: https://docs.github.com/en/copilot/concepts/agents/code-review - GitHub Docs, Using GitHub Copilot code review: https://docs.github.com/en/copilot/how-tos/use-copilot-agents/request-a-code-review/use-code-review - GitHub Blog, Copilot code review can now approve pull requests: https://github.blog/changelog/2026-09-01-copilot-code-review-can-now-approve-pull-requests/ - GitHub Blog, Upcoming changes to GitHub Copilot policies and billing: https://github.blog/changelog/2026-08-28-upcoming-changes-to-github-copilot-policies-and-billing/ - GitHub Blog, Auto-resolution and analysis updates in Copilot code review: https://github.blog/changelog/2026-09-11-auto-resolution-and-analysis-updates-in-copilot-code-review/

Frequently asked questions

Does effort level mean approval

No. Effort level only tells you whether Copilot used Lite or Balanced for that review. Approval is a separate assessment and, when enabled, a separate approving review action.

Can Copilot's approval satisfy branch protection

Yes, when approvals are enabled. GitHub says Copilot can submit an approving review that satisfies required-approval rules the same way a teammate's approval would. That feature is in public preview and off by default.

Where do I see which effort level was used

GitHub says the pull request overview comment and timeline events show the effort level used for each review run. The docs also say you can choose the level in the pull request under the Reviewers section.

What changed from the old settings

GitHub renamed the preview labels Low and Medium to Lite and Balanced. Existing configurations carry forward under the new names. GitHub also says the default review effort for some existing and new setups is changing from Lite to Balanced on September 28, 2026.

Should I use Lite or Balanced

GitHub's docs map Lite to routine changes and Balanced to larger, more complex, or security-sensitive pull requests. Use the deeper setting when the code change has more risk or spans more services.

Know someone stuck on this? Send them the answer.

Sources

Every link here was fetched and confirmed to resolve before this page went live.

More on this topic: Building with AI

Related questions

Not the question you had?

Ask it. Every source gets fetched and checked before anything goes up, so it takes a day or two, and questions that cannot be answered honestly do not get a page at all.

No account, no email address needed.

Everyone here builds with AI, and says so

DevConnect is for developers who use AI and are honest about it. The interesting part is not that the code was generated, it is what you did with it afterwards.