Review Depth Is Now an Organization Setting: What to Measure Before You Pick a Default

On 7 August 2026, GitHub made Copilot code review effort levels generally available. Two levels, Lite and Balanced, control how much analysis Copilot performs on a pull request. Organization administrators can set a default effort level for automatic reviews, which repositories inherit unless they configure their own.

That turns review depth into an organization-level policy value. You can leave GitHub's Lite default in place or deliberately choose Balanced — and that choice can propagate across repositories you may rarely inspect.

The information needed to make that choice well is not on the settings page. It is in your pull request data.

What GitHub shipped

The two levels replace the Low and Medium options from the public preview. Existing configuration carries forward under the new names.

• Lite is the lighter option, intended for routine changes such as documentation updates and small fixes.
• Balanced routes the review to a higher-reasoning model, intended for complex logic, security-sensitive code, and changes that cross services.

Lite applies when no effort level has been configured. Both levels are available on Copilot Pro, Pro+, Max, Business, and Enterprise plans.

Three details matter for anyone responsible for review policy:

1. The organization default is inherited for automatic reviews. Repositories that have not configured their own level use the organization setting.
2. A per-review override is available. Choosing a level when manually requesting a review affects that review only and does not change the repository or organization default.
3. The level that ran is visible. GitHub labels the effort level in pull request timeline events and in the Copilot overview comment.

Effort level is separate from whether Copilot reviews at all. Per GitHub's documentation, Copilot reviews a pull request when it is assigned to it, while users, repository owners, and organization owners can additionally configure automatic reviews.

Effort level decides the depth of the reviews that happen.

Picking a default is a resource decision

The two levels are a trade-off, not a quality dial you turn to maximum.

Balanced routes to a higher-reasoning model, which GitHub positions for complex or sensitive changes. Using it indiscriminately also means spending more AI credits on routine work. Lite provides a faster, more targeted pass, but using it everywhere means the changes that would benefit from deeper reasoning receive the lighter treatment too.

The spend is documented. GitHub states that Balanced reviews consume more AI credits than Lite reviews and may use marginally more GitHub Actions minutes. It estimates a Lite review at roughly $0.05 to $1 of AI credits and Balanced at $0.25 to $5.

An inherited default can apply whichever choice you make to every repository that has not configured its own.

The problem is that repositories are not homogeneous.

Some primarily produce documentation updates, dependency bumps, and small fixes. Others regularly produce cross-service changes, security-sensitive logic, or large changes with significant review surface.

A single default is therefore only the starting point. The real question is:

Which repositories have evidence that they deserve an override?

That is where pull request data becomes useful.

Start with the share of review that is already automated

Before choosing how much machine review to add, find out how much review is already automated.

GitQuick classifies every review by the reviewer's login into three categories: human, AI review service, and other automation.

AI review services are a subset of automation and include logins such as copilot-pull-request-reviewer, gemini-code-assist, coderabbit, and cursor[bot].

Other automation covers accounts such as Dependabot, Renovate, and GitHub Actions, which can generate activity in the review record without performing the kind of AI review this decision is about.

It is important to know the difference between the two numbers because they are not interchangeable.

The figures below come from public organizations in the GitQuick showcase, using one-month windows ending between 13 and 19 August 2026. The table includes every showcase organization with at least 1,000 reviews in its window — ten of the sixteen currently published — sorted by AI review share.

The range is wide, and the middle is empty.

AI review share runs from 0% at Apple to 46.9% at OpenAI. Seven of the ten organizations sit below 4%, while the other three sit above 22%.

In this sample, there is no cluster around a single middle range that gives you an obvious benchmark to copy.

More importantly, none of these numbers tells you what your organization should do.

That is the argument for measuring your own.

What the new label does and does not give you

The effort-level label is a real improvement.

It makes the depth of an individual Copilot review auditable instead of assumed. You can see that a particular pull request received a Balanced review rather than a Lite one.

But that is still a per-review observation.

It does not tell you:

• what share of changes in your highest-risk repository received only Lite reviews,
• whether the repositories using Balanced are actually the ones producing complex changes,
• how much of your total review activity is already automated,
• or whether human review coverage changed after you altered the policy.

Review depth and review coverage are different measurements.

A pull request can receive a deep automated review and still merge without a human review.

That distinction becomes especially important once automated review is common enough to influence the metrics teams already watch.

Before you set the default

Three checks are useful before choosing an organization-wide policy.

1. Look at PR size per repository — median and P90

The median describes the typical change. P90 exposes the large tail.

A large PR is not automatically a complex PR. Generated files, mechanical refactors, and dependency changes can all produce large diffs without requiring deeper reasoning.

But a repository with a heavy large-PR tail is worth investigating.

Are those large changes also the cross-service, security-sensitive, or complex changes for which GitHub recommends Balanced?

The PR size distribution across public organizations shows how far median and P90 can sit apart.

2. Check human review coverage in the same repositories

Automated review depth does not answer whether a person reviewed the change.

A repository that already relies heavily on automated review has a different risk profile from one where nearly every pull request receives human review.

Increasing the depth of Copilot's review changes what the automated reviewer may catch. It does not establish human accountability for the change.

3. Confirm where the default would actually land

An organization default matters most in repositories that have not set their own policy.

Those may not be the repositories you look at every day.

Before changing the default, identify the repositories that will inherit it and examine what kind of pull requests they actually produce.

Changing review policy can change your metrics before it changes your process

This is where the effect becomes easy to miss.

Automated reviews are recorded as reviews.

GitQuick derives time to first review from the earliest review on a pull request, whichever account submitted it. A policy that causes Copilot to review more pull requests can therefore improve time-to-first-review without any person responding sooner.

The number changed.

The human review process may not have.

That is why the first-review stage has to be read next to automated review share. The post on reading the PR pipeline by stage covers that distinction in more detail.

There is a second effect too.

A Copilot review means the pull request no longer counts as having zero recorded reviews, even if no human ever reviews it.

So as automated review adoption increases, a conventional zero-review metric can improve while human review coverage stays flat — or even declines.

Those are different signals and should be measured separately.

After changing review policy, watch the human side independently:

• human review share,
• merges without human review,
• time to human approval,
• and automated review share.

Otherwise, you risk concluding that the review process improved when what actually changed was who produced the first review event.

One limitation is worth stating plainly: GitQuick classifies reviewers by login, so it can identify that a review came from an AI review service. It does not currently read which Copilot effort level GitHub ran.

Takeaway

Explicit review depth is better than implicit review depth.

But once review depth becomes an inherited organization policy, the default deserves more thought than simply choosing Lite or Balanced globally.

Start by understanding how much of your review activity is already automated. Separate AI review services from ordinary bots. Look at which repositories produce the large and potentially complex changes. Then check whether those repositories still receive meaningful human review.

GitHub gives you the control.

Your pull request data tells you where that control is worth using.

The dashboards below are public and require no GitHub installation:

• Microsoft
• AWS
• All showcases

See your AI, bot, and human review split →

Disclaimer: This analysis uses public GitHub metadata and GitHub's own changelog and documentation. Reviewer classification is based on account login heuristics and can misclassify accounts that do not follow common naming patterns. Review counts measure review activity, not review quality. GitQuick is not affiliated with or endorsed by GitHub or any organization mentioned.