On September 1, GitHub introduced Copilot approvals in public preview. They are off by default; when enabled, they count toward required approvals, with file-path controls available at repository level. An approval assessment in a review comment alone does not count.
What does the second review add?
Keeping a human approval requirement is easy to defend until you ask what the human actually does. If someone glances at green checks and clicks Approve, keeping their name on the pull request achieves little. A team can take responsibility for an automated merge policy just as it can for an individual merge.
Consider a hypothetical API cleanup that removes a response field. The author updates the tests, the suite passes, and an AI reviewer finds the implementation consistent. But a customer still uses that field. Unless the review checks compatibility with that customer's integration, agreement tells us little about whether the change should ship.
A teammate who knows the customer could catch this. So could an automated check built from the customer's contract. Either introduces evidence the author missed. That is the standard I would apply to reviewing AI-generated code: a second pass should challenge the first pass's assumptions. A different reviewer, human or AI, may still share them.
Make the case for automatic merging
"Dependency bumps" and "generated code" are too broad to serve as safety policies. A generated client can faithfully reproduce a breaking API change. Calling the output generated says how it was produced, without establishing whether it is acceptable.
A stronger case would be regenerating a client from an already reviewed schema, using a pinned generator, with checks that verify reproducibility and compatibility. The human decision happened at the schema change. Requiring someone to reread every generated line may add little. An AI review could provide another check, but the justification for merging already rests on specific evidence.
Where that evidence is incomplete, spell out what you expect the model to resolve. Before relying on its approval, try it on past changes whose problems your team understands. Examine the misses, particularly cases where the tests passed too. Those are the cases your proposed policy would have allowed through.
Account for what the team stops learning
Review can also leave a second person able to maintain the code. If only the author understands a new subsystem, skipping review gives up an opportunity to change that. A clean diff and a correct implementation do not settle whether the team can afford that concentration of knowledge.
I would enable AI approvals only for a narrow class of changes I could explain to a teammate: why the checks are sufficient, which failures remain possible, and who will maintain the result. Keep human review where that explanation depends on judgment nobody has exercised yet. If the pressure to automate comes from a growing review queue, start by making that queue manageable enough for people to do useful reviews.