GitHub splits Copilot code review's automatic triggers into draft and new-push switches

Most teams will leave the default alone. According to GitHub's documentation, as cited in a dev.to walkthrough of the update, Copilot does not review a pull request again after a push if it has already reviewed it, unless new-push review is configured ^[7]. With draft review switched on, that single pass can land on the earliest version of a branch ^[5].

The walkthrough's example is a small appointment-request app. A later commit adds sign-in so owners see only their own appointments, and the review of the first draft is now stale ^[11]. Switching on every trigger fixes the staleness by reviewing everything. The post's author wrote that "A review after every tiny push can become noise." ^[12] The author argued that teams should "choose review checkpoints by the decision you need to make, not by the number of times AI generated code." ^[10]

Separate switches fit that argument, and I think GitHub got this part right. The author proposes three checkpoints: an early design check, a change check after risky edits, and a release check against the user's actual task ^[17]. Draft review covers the first. A new-push review or a manually requested re-review covers the second, because it looks at the code after a consequential change ^[18]. The third is a person trying the task as a visitor and as an owner, including an invalid submission and a status change ^[19].

Who owns each control depends on where it lives. As the post describes the update, the draft and new-push switches sit on a personal settings page and cover pull requests the user creates or coauthors ^[5]. Effort is the setting with a central default. An enterprise sets it, and organizations and repositories can override it ^[3]. A manual request can still ask for a different level ^[6]. If the personal page is the whole trigger surface, a team's trigger policy is a convention each author applies to their own account ^[5].

Effort is where the spend goes. GitHub describes Lite as targeted feedback and Balanced as deeper analysis that uses more credits ^[9]. The post does not quantify the credit gap, so the cost of a Balanced default with new-push review on cannot be worked out from it. The author would request a deep review when a change crosses identity, payments, data ownership, deployment, or a shared component used across important flows, and would not request one to rename a label ^[13]. "That is my risk rule, not a GitHub default," the author wrote ^[14]. On a team where most pull requests are interface and copy changes, I'd set Lite as the enterprise default and have authors request Balanced by hand on boundary-crossing work ^{[3] [6]}. A repository holding identity or payments code is the obvious candidate for a Balanced override ^{[3] [13]}.

No trigger changes what Copilot produces. Its default response is a comment review, and an approval assessment alone does not satisfy merge requirements ^[8]. A human approver still has to clear any branch rule that demands one ^[8]. For the sign-in change, the author's check is to use two separate ordinary test accounts, attempt the forbidden read and edit, then inspect the server-side permission rule ^[15]. The author wrote that a re-review does not replace that test, because a reviewer can miss behavior that only appears with real roles and data ^[16].