Monday morning, a developer opens a pull request on a repo whose branch protection requires one approval. The Copilot review posts its overview comment, the approval assessment says the change looks ready, and with the new setting enabled that assessment is a formal approval that satisfies the rule [1][5]. The merge button goes green with nobody having read the diff.
Subtract Copilot's approval from your required-approvals number and you get the real change: a repo set to two now needs one human, and a repo set to one needs none [13]. That setting, not Copilot's hit rate on bugs, is what decides how large a change this is for a given repo.
Teams may tell themselves Copilot is just another reviewer, that engineers will still read the assessment and apply judgment, but the settings screen does something more specific: it converts a comment into a token that opens a gate. The evidence available today is all configuration, not outcome. We know approvals are off until an admin opts in, that enterprise, org and repo levels can each enable, restrict, or hand the decision down, that repo admins can restrict approvals by file path, and that a new commit dismisses the approval automatically [2][3][4][6]. GitHub has not published a false-approval rate for these approvals. devops.com's own guidance is to begin with low-risk code and measure outcomes before extending approval authority to critical repos [12], which is the advice you give when the outcome data does not exist yet.
Mitch Ashley of The Futurum Group put the line clearly, saying approval is where code review stops being advice and becomes authority, and that leaders should turn it on and instrument it to measure effectiveness [9][10]. The instrumentation is the part GitHub does not hand you, per devops.com [11]. That count - pull requests Copilot approved that a human later reverted - doesn't exist as a dashboard anywhere, and the person who most needs it is whoever gets asked about Friday's incident.
Sorting the repos comes down to how many approvals branch protection requires and how cheaply a bad merge on these paths can be undone before a customer notices.
Where two approvals are required and the path is easy to revert, turn it on and let Copilot absorb the second seat; you keep a human in the loop and buy back review time. Where two are required but the blast radius is real, use the path restriction so Copilot can approve docs and test fixtures while authentication and payment code stays human [4]. Where one approval is required and the path is cheap to revert, enabling this means accepting merges with no human approver, which is a defensible choice only if you write it down as one. Where one approval is required and the path is expensive to get wrong, the fix is raising the count to two before enabling anything.
Default-off is a policy [2]. It's a policy that lasts only until someone with admin rights gets curious. Completing the sentence "Copilot may approve these paths and may not approve those" for each repo is the work that needs doing. Skipping it just reveals that a repo's required-approvals settings were never a considered decision in the first place.
