GitHub Copilot PR approvals: what still needs human review

GitHub Copilot code review gained pull request approvals in public preview on September 1, 2026. Approvals are off by default. Administrators can enable them, and an approval can count toward the repository’s required approvals. A recommendation in the review comment, by itself, does not. That distinction matters when you configure the merge rules. GitHub’s release announcement explains the change.

I would use that extra assessment. I would still want a person who understands the workflow to approve changes involving customer access, money, or records the business depends on. The useful question is what evidence that person should examine.

What the approval setting actually changes

GitHub’s configuration separates permission to submit an approving review from permission for that review to satisfy merge requirements. Repository administrators can also restrict which file paths qualify. Every changed file must match an allowed pattern for those approvals to count. The configuration guide documents those controls.

For a small team, I would start with a narrow scope and inspect actual review quality before expanding it. A documentation correction and a change to invoice creation should not inherit the same review policy just because they live in the same repository.

Give the reviewer a business rule to check

Consider a hypothetical change that creates a draft invoice when an agreement is signed. The provider sends a webhook, which is an HTTP notification that the event happened. The application receives it and creates the invoice.

That description leaves too much open. My acceptance rule would be more precise: a valid signed-agreement event creates one draft invoice for the correct account. Receiving the event again returns the existing result. Nothing sends the invoice to the customer until someone reviews and approves it.

That gives both the AI reviewer and the human something concrete to challenge. It also exposes a missing decision: what should happen if the agreement changes after a draft already exists? I would settle that before judging whether the implementation is correct.

Repeat the event and interrupt the work

A successful first request is only the beginning of the test. Send the same event twice. Then send two copies at nearly the same time. Check the stored records afterward. Both cases should leave one invoice linked to the agreement.

Next, interrupt the operation between its steps. If the invoice is saved but the event is not marked complete, can a retry create another invoice? The developer should show how the system prevents that and provide a test that would fail if the protection were removed.

Check what happens when the accounting connection is unavailable. The original event needs a visible state that someone can resolve. A test that only confirms a green success message says very little about that recovery.

Check who can act on which records

The human review should connect permissions to actual people. Can someone from another customer account retrieve this invoice by changing an identifier? Can a staff member who may edit a draft also send it? Should they be able to?

The webhook handler needs to verify the provider’s notification before trusting it. A record identifier in a request is not evidence that the sender may change that record. Test invalid notifications and requests against another account, then confirm that neither changes data.

There is another practical limit to check: GitHub lists dependency-management files, logs, and SVGs among the files excluded from Copilot code review. An approval should not be read as proof that every changed file received the same examination. GitHub’s review documentation lists the exclusions.

Leave a usable failure report and a way back

If this automation stops, somebody needs enough information to act. I would look for the affected agreement, the failed step, the time, and whether retrying is appropriate. Keep credentials and unnecessary customer information out of the report.

Then ask the developer to explain the rollback. Turning off the new code may stop more drafts from being created, but it does not remove drafts already created or recall an invoice already sent. The release needs a way to identify affected records and a named person to decide what happens to them.

Record what the human approved

The review record can be short: the commit reviewed, the business rule checked, the relevant test results, any remaining limitation, and the person approving the change. Keep it with the pull request so the decision survives the chat that led to it.

A new commit can change that decision. GitHub says Copilot’s approval is dismissed when new commits arrive, after which a fresh review can be requested. That behavior is part of the preview. The human should also examine what changed before relying on an earlier sign-off.

The wider ownership questions are covered in Can ChatGPT build your business software? If you already have a working tool, a software audit can focus on the specific behavior people are about to depend on.

If nobody can agree on that behavior yet, start by mapping the process. A review cannot settle an approval rule the business has never defined.