GitHub Copilot gets granular settings for automated code review

O GitHub anunciou em 23 de setembro de 2026, via changelog oficial, um conjunto de ajustes na configuração do Copilot code review que muda a forma como equipes decidem quando e como a IA entra na revisão de pull requests. A mudança não é sobre qualidade da revisão em si, mas sobre quem controla o gatilho e o nível de esforço da IA, algo que até agora era limitado a poucos planos e pouco granular.

What existed before

Before this announcement, personal Copilot code review settings were only available to those with Copilot Pro, Pro+, or Max, inside the generic "Copilot features" page. There was a single automatic review switch, with no distinction between a draft pull request, a new push, or co-authorship. In other words: either the AI reviewed everything automatically, or nothing at all.

This binary model created real friction in large teams: those working with draft PRs for days (common in trunk-based development flows with feature flags) received review comments before the code was even ready for human eyes, generating noise that developers learned to ignore, which is the worst possible scenario for a code quality tool.

What changes: personal configuration by trigger

Now, under Profile → Copilot settings, there's a dedicated "code review" page available on all plans, including Copilot Business and Copilot Enterprise, which were previously left out. From there, the developer separately controls:

• Automatic review when creating a PR, co-authoring a PR, or taking a PR out of draft state;
• Automatic review on new pushes;
• Automatic review specifically for draft PRs you created or co-authored;
• The default review effort, currently with two options: Lite or Balanced.

In practice, this enables a flow like: automation turned on only for PRs coming out of draft (a signal of "ready for review"), with subsequent pushes not triggering a new automatic round, preventing every git push --force after a rebase from firing off a new batch of comments. Those who prefer to keep manual control can still request a review via the PR's "Reviewers" tab and choose the effort there, even if the personal default is set to something else.

Lite vs. Balanced: what changes in effort

The changelog doesn't detail the internal criteria for each level, but the distinction named as review effort indicates that Copilot adjusts the depth of analysis (likely the number of files considered in context, or the level of detail in comments) according to the chosen mode. This is relevant for those working with large PRs: a lighter effort tends to produce fewer comments and a faster response, useful for routine reviews or hotfixes; a balanced effort is more suitable for structural changes, where the extra analysis time is worth it.

The practical point is that this default effort applies both to manual reviews and to configured automatic ones, and it can be overridden PR by PR when requesting a manual review. In other words, you can keep Lite as your everyday default and bump up to Balanced only when the PR warrants it.

Enterprise-level governance

The second change is for those who administer entire organizations: authorized enterprise administrators can now set a single default effort (Lite, Balanced, or GitHub's default) that applies, by inheritance, to all repositories belonging to that enterprise's organizations. Individual organizations and repositories can still override this default.

This detail matters more than it seems for platform and DevEx teams: until now, standardizing Copilot code review behavior across dozens of repositories required configuring each one manually or trusting that each developer would adjust their own account. With the enterprise default, it's possible to establish a central policy (for example, Balanced as a minimum floor in production repositories) without depending on individual discipline, while still keeping override flexibility where it makes sense.

When it's worth turning automation on, and when it isn't

Copilot's automatic review pays off in teams with a high volume of small, recurring PRs, where having a first AI filter before a human speeds up the cycle. It tends to get in the way in two scenarios:

• Teams that already use aggressive lint/SAST tools in CI: duplicate automatic review generates noise without adding new signal, and the developer ends up muting both.
• Flows with long-running draft PRs used as work checkpoints (not as "almost ready"): enabling automatic review for drafts in this case is the opposite of what the feature solves, because the comment arrives too early to be useful.

The new granularity solves exactly this second case, since it's now possible to specifically turn off automation for drafts without giving it up for ready PRs.

What remains open

GitHub did not publish, alongside this announcement, adoption data or accuracy metrics comparing Lite and Balanced, so any decision about which one to use as a team default still depends on direct observation over a few weeks. It's also worth noting that this announcement follows another one, from September 18, 2026, about an "improved review experience" in Copilot code review, which suggests GitHub is iterating quickly on this front, and teams that adopt the configuration now should review their chosen defaults in a few months, when the tool will likely have changed again.