AI code review stopped being a mere convenience feature this week. On October 28, GitHub announced that Copilot may now approve pull requests, and that this approval counts toward required approvals just like a human one. Technically, that is a toggle in the settings. For a team, it is a fundamental question: who is actually accountable for what lands on the main branch?
This topic keeps me busy because I know both sides. As a developer, I welcome every hint that saves me from a bug. As a team lead, I also see what a review does besides finding bugs: spreading knowledge, sharing responsibility, keeping standards together. So you won't get a feature overview here. Instead, you get a guide that helps your team set rules for AI in reviews, with a traffic-light model, example files and seven steps for the first team session.
In short
Copilot can now wave pull requests through with an approval that counts, but this is switched off by default. A traffic-light model makes sense: the AI may approve low-risk paths on its own, while everywhere else it pre-reviews and a human decides. The biggest pitfall is not the technology but a team that accepts AI comments without thinking.
What you will learn in this article
Copilot code review has been around for a while. Until now, the agent commented, suggested changes and, at the end, assessed in an overview whether it considered the pull request ready. That was not an approval in terms of branch rules. If your repository required two approvals, you still needed two humans.
The changelog from October 28, 2026 changes two things. First, according to GitHub, Copilot approvals are now generally available: when the feature is enabled, Copilot may approve a pull request, and that approval counts toward required approvals. If someone pushes new commits afterwards, the approval is dismissed and a new review is needed. Second, next to “Lite” and “Balanced” there is a third effort level called “Max” (a public preview according to the changelog). It runs several independent review agents on models from different providers, and an aggregating agent reconciles their findings. That takes longer and costs more AI credits.
Important for your team rules: approvals are off by default. At the enterprise level, “Disabled everywhere” is the default, and below that organizations and repositories can decide. A repository has two separate toggles. One allows Copilot to submit approving reviews at all. Another decides whether those approvals count toward merge requirements.
In addition, you can optionally define up to 15 file patterns (globs). A Copilot approval then only counts if every changed file in the pull request matches one of those patterns. If you leave the field empty, the approval counts for all files. This field is the most important tool for a team that wants to use AI in measured doses. One note for context: when I researched this, the configuration page of the docs still listed approvals as a preview and “Max” as “Coming soon”. The changelog is newer. So take a quick look at what your own organization actually offers.
You could argue: the AI finds bugs, so let it approve, and everybody saves time. That falls short, because a review serves several purposes at once. Finding bugs is only one of them.
Whoever reviews a pull request gets to know the code. If its author is on vacation, someone else can still understand the incident at night. For example, a colleague then also knows why the payment logic now makes a second attempt. In addition, a team constantly negotiates its standards in reviews: how do we name things, how much abstraction is enough, what do we test? Google describes the bar in its Engineering Practices roughly like this: a change gets approved when it improves the overall health of the code, even if it isn't perfect. That is a judgment call that needs context. Which feature do we want at all? Does it fit the direction of the product?
GitHub itself is clear in its documentation on responsible use. Copilot can miss problems, especially in large changes. It can report problems that don't exist. And suggested code can look valid and still be wrong or insecure. The explicit recommendation is to supplement human reviews, not to replace them.
On top of that, there is a psychological effect called “automation bias”: people rely on an automated assessment more than they should, especially when it is usually right. If the top of the pull request says “Copilot considers this ready”, the second pair of eyes skims faster. If the AI approval also counts toward the mandatory approvals, the one person who knows the context may be missing. That is why the decision about where the AI may approve belongs to the team, not to a single admin flipping a switch.
I wouldn't answer the question with yes or no but grade it by risk. A simple traffic-light model is enough for that. It also fits nicely with the glob field GitHub offers.
The traffic-light model: the higher the risk of a path, the more human review.
| Zone | Typical paths | Role of the AI | Role of the humans |
|---|---|---|---|
| Green | Docs, README, translation files, typos in comments | Reviews and may approve on its own | Spot checks, e.g. once a week |
| Yellow | Regular application code, tests, internal tools | Pre-reviews, approval does not count | At least one human approval |
| Red | Authentication, payments, IAM and infrastructure, database migrations, CI workflows | Reviews in depth (e.g. “Max” level), approval does not count | Two humans, at least one of them a code owner |
In AI code review, the green zone is deliberately small. It only covers changes where a missed bug is cheap and quickly noticed. The yellow zone is everyday work: here the AI saves people time, because obvious bugs are fixed before the human review. The red zone is where the most thorough AI review pays off most, yet the approval stays with the team.
By the way, GitHub's changelog recommends using “Max” together with approvals where overlooking a problem would hurt the most. This is where I disagree: where a bug is most expensive, I want the most thorough review and a human who signs off. More compute doesn't replace context.
This is how I would set up an agreement for AI code review. Plan a team session of about 60 minutes and a short follow-up after four weeks. You need a Copilot plan that includes code review (Pro, Pro+, Max, Business or Enterprise) and admin rights on the repository for the settings.
Look at the last 20 to 30 pull requests together. Which paths were changed? Where were there real discussions, where only a quick “LGTM”? That almost automatically gives you a first split into green, yellow and red. Also check which settings are already active. Often someone switched on automatic review long ago without it ever being discussed.
For the green zone you need a list of file patterns, one per line, 15 at most. Here is an example for a fictional bike rental project:
docs/**
**/*.md
locales/**/*.json
.vscode/extensions.json
The docs give no examples and no exact syntax for this field. So test the patterns with a small pull request that only changes a README, and a second one that also touches a TypeScript file. In the second case, the Copilot approval must not count toward the merge rule.
For the red zone, a CODEOWNERS file helps together with the branch rule “Require review from Code Owners”. Then someone from the named group must always approve these paths, no matter what the AI thinks. The group names here are just examples, of course:
/src/auth/ @bike-rental/security
/src/payment/ @bike-rental/security
/infra/ @bike-rental/platform
/migrations/ @bike-rental/platform
/.github/ @bike-rental/platform
/AGENTS.md @bike-rental/platform
Only now do you go into the settings. In the repository's Copilot code review settings you will find the auto-approval section. Enable “Allow Copilot to approve pull requests” if you want approvals at all. Only turn on “Allow Copilot approvals to count toward merge requirements” together with the glob list from step 2. For automatic review itself, a branch ruleset with the rule “Automatically request Copilot code review” is the clean way, because it applies to everyone and doesn't depend on personal settings.
Keep the cost in mind. According to the docs, a review on the “Lite” level costs roughly 0.05 to 1 US dollar in AI credits, and 0.25 to 5 US dollars on “Balanced”, excluding Actions minutes. “Max” costs more. For the red zone that can be worth it, for every typo fix probably not.
For the review, Copilot reads instruction files from the repository, namely from the pull request's head branch. The central file is .github/copilot-instructions.md, plus path-specific files under .github/instructions/ and an AGENTS.md in the root directory for rules that apply to all AI agents. Write down what matters to you in reviews and what the AI should ignore. How to build the path-specific files with applyTo and excludeAgent is shown in Path-specific Copilot custom instructions: a guide. An example:
## Review focus
- Check that inputs on all public endpoints are validated.
- Point out missing tests when business logic changes.
- Watch for secrets in code and overly broad IAM permissions.
## Please do not comment on
- Formatting (Prettier handles that in the pipeline).
- Pure matters of taste in variable names.
## Tone
- Write comments in English, short and with a reason.
- Mark optional hints with "Optional:".
Because the file is read from the head branch, a pull request can change the rules for its own review. So add .github/ and AGENTS.md to the red zone. Otherwise someone might end up tailoring the review rules to their own change.
When the AI handles the rough stuff, the focus of human reviewers shifts. Write down what you will look at from now on: domain correctness, architecture and interfaces, readability for the next person, operations and failure cases. That doesn't make the review shorter, but it makes it more valuable. How to phrase comments that land well is covered in Code Review Feedback: Comments That Land.
Schedule a retrospective. Three questions are enough: which AI hints actually prevented something? Which were noise? Did anything slip through in the green zone? Then adjust globs and instructions. If you want to approach this more systematically, Evaluating AI agents: small evals in TypeScript has ideas for small, repeatable tests.
The trickiest part of AI code review is dealing with the hints themselves. I often see two extremes in discussions: either every suggestion gets accepted with two clicks, or all comments are marked “resolved” unread. Both are bad. In the first case, code nobody understood lands in the project. In the second case, you pay for hints nobody reads.
A simple rule helps: every AI comment gets one of three reactions. Either accept it, but understood and tested. Or reject it with half a sentence of reasoning, such as “false alarm, validation happens in the schema”. Or ask when it's unclear whether the hint is right; then the author brings in a human. The reasons for rejections are pure gold, because in step 7 you use them to improve your instruction file.
Also pay attention to a small detail with a big effect: in its overview, Copilot assesses whether the pull request is ready. Ask human reviewers to look at that assessment only after their own reading. That keeps their judgment unbiased and gives automation bias less room.
Letting approvals count without globs. An empty path field means the AI approval counts for all files. Combined with only one required approval, code can then reach the main branch without a single human look.
Leaving the instruction file unprotected. As described above, Copilot reads the rules from the pull request's branch. Without code owners for .github/, a safeguard is missing here.
Not asking the team. When a manager or an admin switches on approvals alone, it quickly feels like distrust of the team's own reviews, or like a cost-cutting program. A traffic-light model agreed on together, on the other hand, gets supported and maintained.
Taking reviews away from juniors. Reviews are one of the best learning sources for new team members. If the AI approves everything simple, only the hard cases are left for them. Deliberately let them keep reviewing in the yellow zone, ideally in pairs.
Granting the agent overly generous permissions. Copilot can hand suggestions over to the cloud agent, which then opens a pull request with fixes itself. How to limit such permissions properly is covered in Copilot Assisted Permissions: a safe setup.
I consider AI code review a real gain, especially in the yellow zone. When obvious bugs are gone before a human looks, the human review gets better: less nitpicking, more conversation about what really matters. That is an argument for more AI in reviews, not for fewer people.
With approvals that count, I'm more cautious. They make sense for a narrow, clearly described area. Beyond that, they shift responsibility to a system that cannot be responsible itself. When something breaks at night, the on-call engineer doesn't call an agent. So my advice: start with a tiny green zone, measure, talk about it and only expand it if the team wants to. “People first” means something very concrete here: humans make the rules and the AI follows them.
Yes, if admins enable the feature. According to the GitHub changelog from October 28, 2026, a Copilot approval then counts toward required approvals. It is off by default, and new commits dismiss it.
No. GitHub also recommends using Copilot as a supplement. The AI can miss bugs and report false problems. Besides, a human review serves purposes like knowledge sharing and shared standards that an AI doesn't take over.
The docs give rough ranges in AI credits: about 0.05 to 1 US dollar for “Lite” and 0.25 to 5 US dollars for “Balanced”, each excluding Actions minutes. “Max” is more expensive. Exact numbers depend on the size and complexity of the change.
In .github/copilot-instructions.md for the whole repository, in files under .github/instructions/ for specific paths, and in an AGENTS.md for rules that concern all AI agents.
To get started with AI code review, check which Copilot settings are currently active in your most important repository, and bring the traffic-light model to your next retro. Half an hour is enough for a first green zone. And now I'm curious: would you let an AI approve pull requests in your team, and if so, for which files? Let me know in the comments.
This post was created with AI assistance.
👉 Next step: More for team leads: my cheat sheets put the essentials on one printable page.
Originally published on sascha-ms.de. More articles on serverless, AI in everyday development and leading tech teams: sascha-ms.de/en