DEV Community

Tess Ainsley
Tess Ainsley

Posted on

Copilot's review default is 'Comment', not 'Approve'. Read the docs before you trust the merge gate.

The claims that land about any AI reviewer mostly come from vendor changelogs and self-published benchmarks. The most consequential thing you can read on a specific tool is the official documentation, because that is where the defaults live, and defaults decide whether the reviewer is actually part of your merge gate or just noise on the pull request.

Reading the primary source on GitHub Copilot code review from the official docs (checked this week) settles one question teams argue about constantly: does a Copilot review count toward required approvals?

By default, no.

The default review is a comment, not an approval

The official "Using GitHub Copilot code review" page is explicit. When Copilot reviews a pull request, it leaves a "Comment" review, not an "Approve" review or a "Request changes" review. The consequence is stated plainly: by default, Copilot's reviews do not count toward required approvals for the pull request.

That matters more than the feature list. A team that wires Copilot into a repository with required-approval rules and assumes the reviewer is helping satisfy the gate will find every merge still waiting on a human thumb even though the bot "reviewed" the change. The merge rule is not satisfied by default.

The docs describe an approval assessment that appears in every overview comment, indicating whether Copilot considers the pull request ready to approve. But again, on its own that assessment does not count toward merge requirements. The assessment is a signal to a person, not a gate the machine passes.

Approvals exist but are off by default and easy to misread

Copilot can submit an approving review that satisfies the required-approval rule the same way a teammate's approval would. That capability is real. But it is off by default and can be configured at the enterprise, organization, and repository levels. Three things a team should verify before treating it as the gate.

First, approvals are in public preview and subject to change. Preview features are not a stable thing to build a release policy around.

Second, if new commits are pushed after Copilot approves, the approval is dismissed and you must re-request a review. A bot approval does not survive a force-push update; it is tied to the state of the branch.

Third, repository administrators can use file paths to control which Copilot approvals count toward merge requirements. That is a real and useful control, but it is configuration work. Until you do it, the approval is not doing what the marketing sentence implies.

The pattern here is the same one I found reading GitHub's own guide to reviewing AI-generated code, which is a mostly-human checklist with almost every step assigned to a person. The product docs tell the same story from the other direction: the default behavior leaves the actual approval to humans.

Effort levels are the spend lever nobody quotes

The docs also document review effort levels, Lite and Balanced. Lite is a cost-efficient review giving targeted feedback on glaring issues such as bugs, security vulnerabilities, and style inconsistencies. Balanced is described as deeper analysis of complex logic, security-sensitive code, and cross-service changes, using a higher-reasoning model.

That is rigor as a cost decision, spelled out in the docs. The stricter review costs more because it uses a higher-reasoning model. If your compliance bar is "audit every security-sensitive change," the Lite default is not pointed at that bar. Set the effort level explicitly rather than assuming the default review is deep. The same logic shows up in multi-repo review, where the deciding factor is whether the tool can see cross-service context rather than raw volume.

How the reviewer actually runs and what it does not do

A few more documented behaviors matter because they shape how you operate the tool.

Copilot code review runs on a pull request you request it on, the same way you would request a human reviewer, or you can configure it to review all pull requests automatically. The typical review is described as taking less than 30 seconds.

Comments get a severity label, High, Medium, or Low, so a human reviewer can prioritize. Comments behave like human review comments, you can add reactions, resolve them, and hide them. But comments you add to a Copilot review comment are visible to humans and not to Copilot, and Copilot will not reply. You cannot have a threaded conversation with the bot; the loop you get is comment, react, resolve, one-way.

Copilot does not automatically re-review when you push changes unless you configured it to. And when it does re-review, the docs note it may repeat the same comments again even if you resolved them or downvoted them. If you are scoring the reviewer on whether it learns from dismissal, the documentation is upfront that it does not track your resolutions.

You can customize review guidance with repository and path specific instructions, using .github/copilot-instructions.md for review guidance that should apply across the codebase, and an AGENTS.md file for repository context. That is the documented hook for "does it follow our standards," and it is the part of the reviewer a team should actually test rather than trust.

The buyer takeaway

Side-by-side with other AI reviewers, the thing that distinguishes Copilot code review is what it defaults to. On a tool like this the defaults are the contract. A reviewer that is a comment stream merging nothing, one-way, and off the required-approval path is a triage assistant until you configure it into something stricter. The rigor you get, Lite versus Balanced, is a spend decision. The gate it satisfies, none by default, is a configuration decision. Neither is something a benchmark or a changelog headline will tell you; both are in the documentation.

Before you adopt any AI reviewer, find the four defaults: what review type it submits, whether that satisfies your merge rule, whether it re-reviews after pushes, and whether your standards file actually reaches it. Those four answers define the real behavior, and all four are checkable in the vendor's own docs.

Sources: GitHub Docs, "Using GitHub Copilot code review", checked against the live page this week.

Top comments (0)