Thorough Review, Direct Approval: Copilot Code Review Max and Approvals Arrive

On October 28, GitHub announced two changes to Copilot code review in its official changelog: a new Max review effort level entered public preview, and Copilot approvals became generally available. Together they mean something direct: Copilot is no longer just "looking over your code for problems". When conditions are met, it can now approve a pull request for merging. The step is small, but its nature changed: review moved from "giving suggestions" to "taking part in the decision". For teams merging many pull requests a day, this article explains what actually changed, and which rules to set before handing approval power to an AI.

Start with the facts. Copilot code review previously had two effort levels, Lite and Balanced. Max is a third level, positioned as the most thorough. Its method is not one model trying harder, but several independent review agents running at once, each powered by models from different providers, each reviewing from its own perspective, with an aggregation agent combining the results: reconciling disagreements, double-checking accuracy, and producing a single unified review. GitHub describes it as Copilot's broadest coverage, especially on critical issues, while keeping noise low. The cost is stated just as plainly: Max does more work per review, so it takes longer and uses more AI credits than Lite or Balanced.

Approvals are a separate feature. Every Copilot review already includes an approval assessment in the pull request overview comment, stating whether Copilot considers the pull request ready to merge. Now that assessment can become a real approval: when approvals are turned on, Copilot's approval counts toward the repository's required approvals. Mechanically it behaves like a human reviewer's approval: if new commits are pushed after Copilot approves, the approval is dismissed, and a new review must be requested for a fresh approval. Two defaults matter: approvals are off by default and must be turned on by admins at the enterprise, organization, or repository level; and repository admins can choose which file paths Copilot is allowed to approve. Approval power is not all-or-nothing; it can be tightened by path.

What Max is for, and what it is not for

GitHub positions Max precisely: for changes where a missed issue costs the most, such as authentication logic or a shared library several services depend on. The reverse also holds: everyday small changes, documentation edits, pure style tweaks do not deserve Max. They would be slower and more expensive for no meaningful gain. Effort levels can be set at three layers: for a single pull request from the Reviewers bar, or as the default for a repository, organization, or enterprise, with each layer overriding the one above. Admins can also set a maximum review effort level, above which levels are unavailable within that scope. The practical meaning of that layering: a team can lock Max to genuinely high-risk repositories and paths, instead of letting everyone run the most expensive level by default on every pull request.

The multi-agent approach itself deserves a closer look. Different models have different strengths and blind spots, so several models reviewing independently can indeed catch issues one model would miss. But how the aggregation agent reconciles disagreement sets the floor for the final review's quality. If aggregation is effectively majority vote, a critical issue found by one model can be outvoted by two models that missed it. If aggregation is "better safe than sorry", noise comes back. GitHub says the aggregation double-checks accuracy, but does not detail the standard or process. For now that must be heard as a vendor claim: after adopting Max, teams should sample two weeks of its reviews and count how many reported issues are real problems versus noise before deciding whether it is worth the price.

One more boundary is easy to miss: Max's "most thorough" has limits. It reviews the changes in the pull request, not the whole system. Cross-service knock-on effects, behavior after a staged rollout, whether the business logic is right: none of these are inside one code review's view. Treating Max as "the strictest gate" is right; treating it as "merging is now safe" is wrong. No review level, however high, replaces tests, staged rollouts, rollback plans, and on-call.

Four rules before handing approval power to an AI

First, set approval power by path. Repository admins can choose which file paths Copilot may approve, and that control should actually be used. A sensible starting point: open approvals only for low-risk paths such as documentation, tests, and pure front-end presentation; keep authentication, payments, permissions, data migrations, and shared libraries out at first, or pair them with "review plus human re-check". Write the path list into the repository's review policy, not just the admin settings page, or nobody will know why it was set that way when someone new takes over.

Second, approval counts must not rest on AI alone. Copilot's approval can count toward required approvals, but that does not mean "one AI approval is enough". Keep a hard requirement for a human approval: pull requests on critical paths need one human approval, with AI approval as extra credit, never a substitute. Otherwise teams gradually develop the habit of "the AI said it can merge", and human review skill quietly decays. Review is not only about catching bugs; it is how team members understand what the code is becoming, and AI cannot replace that part.

Third, use the new-commit dismissal mechanism properly, and do not work around it. GitHub's rule is that pushing new commits after approval dismisses the approval, requiring a fresh review. That mechanism is protection, not friction. Team policy should state it plainly: do not hoard several changes into one pull request just to "preserve the approval", and do not force-push small fixes after approval. Every new commit deserves a fresh review, even a one-line change, especially a one-line change, because one line is exactly where a "quick logic tweak" hides.

Fourth, review the approvals after enabling them. For the first month after turning approvals on, sample the AI-approved pull requests weekly: did any of them cause production problems later? For pull requests the AI did not approve, how did humans ultimately judge them? One month of those two data sets lets a team judge whether the approval threshold is too loose or too strict. An approval grant with no review afterward is handing over merge power and then never looking again, and that is the most dangerous way to use it.

The cost ledger: Max is not free "extra care"

Max's cost comes in two ledgers. The first is AI credits: multiple agents, multiple models, plus one aggregation agent, so one review costs several times a Lite or Balanced review. If a team sets Max as the default for every repository, the month-end bill will be the first to report that decision. The second is time: Max is slower, so pull requests wait longer. For high-risk changes, waiting a few more minutes for a stricter review is a good trade. For a team merging many pull requests a day, Max everywhere stretches the merge queue, which pushes people to bypass review, batch up big pull requests, and push everything at once, behaviors that damage code quality more than skipping one review round.

So the right use of Max is targeted, not universal. A workable setup: keep Balanced as the default, and use Max only for two kinds of pull requests, those touching high-risk paths such as authentication, payments, permissions, or shared libraries, and the last big release pull request before a release. How do you tell whether a pull request is high-risk? The cheapest way is automatic path matching: if the pull request contains files on high-risk paths, Max is suggested automatically; otherwise Balanced stays the default. Write the rule into repository configuration, not into each person's judgment.

There is also a hidden cost: the cost of review noise. GitHub says Max expands coverage while keeping noise low, but "low" is relative, not zero. The cost of noise is not reading a few extra comments; it is the erosion of trust in review. When false positives pile up, developers start bulk-dismissing review comments, and real issues hiding among the false positives get dismissed too. After enabling Max, watch one metric: the acceptance rate of review comments. If Max's acceptance rate is clearly below Balanced's, its "more thorough" is turning into "more talkative", and the right response is to narrow its scope, not to add more of it.

How to handle review comments: triage beats blanket acceptance

Once Max and approvals are live, teams face a daily question: what do you do with review comments? The laziest options, accept everything or ignore everything, are both wrong. Triage comments into three streams. The first is auto-fix: formatting, naming, obvious null pointers, unused variables. These are factually clear and safe to change, and can be fixed by Copilot or the developer on the spot without discussion. The second is human re-check: comments touching business logic, edge cases, concurrency, and performance must be read by someone who knows that code before deciding, because an AI reviewer reads code text, not business context, and a "problem" outside the context may be a false positive or a real problem that machines cannot tell apart. The third is explicit deferral: style preferences, refactoring suggestions, and comments beyond the pull request's scope go on record for a later task, not into an endlessly expanding pull request.

Triage criteria belong in the team's review policy, not improvised each time. More importantly, triage outcomes should feed back into level selection. If one class of comments lands in "explicit deferral" month after month, that level is too chatty for that repository and should be stepped down. If one class lands in "human re-check and genuinely a problem" month after month, that level is earning its keep and should stay or expand. Levels are not set once; they should follow acceptance-rate data. Many teams do the enablement step for a new tool and skip the tuning step, and the tool quietly stops fitting until it is quietly abandoned.

Approval records and audit: AI-approved pull requests must stay traceable

Once approvals can come from an AI, audit questions follow: three months later someone asks "who approved this pull request", and the answer cannot be "Copilot". GitHub's mechanism keeps Copilot's approval in the pull request record like a human's, which is good, but team policy should add two rules. First, merge records must make it visible at a glance whether an approval came from AI or a human; do not mix them in statistics, or a review will be unable to tell whether "human review quality declined" or "the AI approval share rose". Second, even for AI-approved pull requests on critical paths, keep a human re-check record, not necessarily a formal approval, even a "reviewed" comment. The record's value is not in the moment but afterward: when something breaks, you can trace who looked, and how far they looked, instead of facing a blank that only a machine approved.

Audit data also answers a practical question: how much time did AI review actually save? The saving cannot be counted as "fewer hours waiting for review" alone; it must subtract "time spent reworking AI-approved pull requests later". Net benefit is the difference. Add two columns to the review table: rework rate for AI-approved pull requests and rework rate for human-approved pull requests, and compare after a quarter. If AI-approved rework runs persistently higher, approvals were opened too wide and paths should tighten. If the two are similar or AI is lower, the mechanism genuinely saves time, and expansion has evidence behind it. Numbers beat feelings, especially for a decision about expanding AI authority.

A five-step rollout checklist for small teams

Finally, a checklist a team can follow directly. Step one: start with one pilot repository, not everything. Pick a moderately active repository with a middling pull request volume, and turn on Max and approvals there first. Step two: set path rules. Write down which paths AI may approve and which require human approval, and keep the settings page and the written policy aligned. Step three: set the default level. Default Balanced, Max suggested automatically on high-risk paths, Max chosen manually for the last big release pull request. Step four: run it for a month, watching three metrics: review comment acceptance rate, production incidents from AI-approved pull requests, and average time from pull request submission to merge. Step five: review at month's end, adjust levels and path rules from those three metrics, and only then decide whether to roll out to the next repository. After those five steps, a team has its own answer to "what is AI review worth", not the vendor's answer.

Read together with this round's Microsoft Copilot harness article, a line appears: on October 28, Microsoft and GitHub described different layers of the same thing. The harness article is about the foundation: models can change, the machinery that runs models is now open. This article is about one concrete stage on that foundation: in code review, how multiple models divide the work, and how a review result becomes a merge decision. Max's "several independent review agents plus one aggregation agent" is the harness idea in review form: not one model doing everything, but several models each doing their part, with an orchestration layer synthesizing one decision.

For small teams, that line has a practical meaning: review is the cheapest place to test multi-model collaboration. One review's cost is visible, its results can be sampled, and the blast radius of a mistake is bounded, at worst one extra human re-check. If you are considering handing more stages to multi-agent collaboration, start with review: turn on Max, turn on approvals, run a month, watch acceptance rates and production incidents. That month's data tells you more about what multi-model collaboration is worth in your team than any vendor blog post.

And to draw the boundary with existing Copilot articles on this site: the October 19 article on six retired models and model policy was about model supply and admin policy; the October 28 Copilot Fusion general availability article was about handing model selection to the system while writing code; the October 28 Copilot Projects public preview article was about coordinating multiple agents across repositories for one whole job. This article is not about writing code, choosing models, or cross-repository tasks, but about the gate after code is written and before it merges: how review is done, and how approval is granted. Same day, same product family, different stage. Read along the line "write code, review, merge", and October 28 assembles the complete picture.

In one sentence: Max makes review more thorough, and approvals let a review result directly release a merge, but approval power is not finished once it is switched on. Set power by path, keep a human approval, use the new-commit dismissal mechanism properly, and review once a month. With those four rules in place, AI review is a tool that saves teams time. Without them, it is a shortcut that saves teams thinking, and the price of skipped thinking always comes due in production eventually.