An engineering lead opens the review queue on a Monday and finds two pull requests waiting. One corrects a typo in a documentation page. The other changes how a payment is calculated. Both were started by a coding agent over the weekend. Both are in the same queue, and under the team’s current rules both need exactly the same thing: one approval from whoever has time.
That’s the problem with a single standard of review. It spends the same effort on a typo as on a change that could cost real money, which means too much attention goes to the first and too little to the second. When code arrives slowly, the gap is manageable. When agents are drafting a large share of it, the gap becomes a risk.
The scale of that shift is now visible. GitHub’s 2026 Octoverse report found that more than 40% of pull requests in September started with an agent’s first draft, up from 17% in March, which we covered in our post on who reviews AI-written code. More drafts means more review, and review capacity doesn’t grow at the same pace.
One response is to hire reviewers, and for many teams that’s part of the answer. The other is to stop treating every change alike. On October 28, GitHub shipped new options that make that easier: review effort levels, AI approvals and an agent that works on pull requests until they’re ready to merge. Used carelessly, they could quietly lower your standards. Used deliberately, they let you spend scarce human attention where it matters most.
In this post we’ll look at what GitHub announced, a simple three-tier model for deciding how much review each change deserves, the guardrails that keep AI approvals safe, and a plan for putting it into practice. We’ll finish with a checklist and answers to common questions.
What GitHub Announced
On October 28, 2026, GitHub added three things to Copilot code review and its pull request tooling.
A third review effort level. Copilot code review now has Lite, Balanced and a new Max level, in public preview. GitHub says Max runs several independent review agents across models from different providers, and that because it does more work on each review, it takes longer and uses more AI credits than the other two.
Approvals, now generally available. Copilot can approve a pull request, and when approvals are turned on, that approval counts toward the repository’s required approvals. They’re off by default, and, according to GitHub’s changelog, a new commit after an approval dismisses it, so a fresh review is needed. A developer-community summary adds that administrators can choose to apply them only to listed file paths.
Agent Merge. GitHub also announced that this agent watches pull requests in the cloud and fixes the blockers you select, such as failed workflow runs and merge conflicts, so the change can meet its merge requirements. These features are available on paid Copilot plans.
The Governance Point Hidden in the Feature List
An AI approval can now count toward required approvals in the same way as a teammate’s, which turns a convenience feature into a policy decision.
GitHub says Max “runs several independent review agents across models from different providers.”
That’s a meaningful change. Until now, an automated review was advice. A reviewer, human or machine, could comment, and a person still had to approve. Once an AI approval satisfies a branch rule, the question is no longer “is the AI review useful?” but “which changes are we comfortable letting it sign off?” That question needs an answer written down before the setting is switched on, not after something slips through.
Why a Single Standard Fails
Consider what uniform review does at each end of the risk range.
At the low end, it wastes time. A change to documentation, a formatting fix or an added test carries little risk, yet it competes for the same scarce reviewer attention as everything else. The queue grows, and developers start approving quickly to clear it, which damages the habit of careful review across the board.
At the high end, it doesn’t protect enough. A change to authentication, payments or how data is accessed deserves more scrutiny than the average pull request, and a single approval under time pressure may not give it. The Octoverse data adds a reason for care: agent-started pull requests changed multiple files more often, about 87% of the time compared with 79% for those without detected agent involvement, and they merged quickly, with 90% merged within two weeks against around 86% for the rest. But the report measures merges, not correctness. It has no data on bugs, security flaws or reverts. A merge shows someone accepted a change, nothing more.
A Three-Tier Risk Model
This is our suggested way to organise review, not an industry standard, and you should adapt it to your own codebase. The idea is to decide in advance how much review each kind of change gets, instead of deciding case by case under pressure.
Tier 1: Low risk. Documentation, comments, formatting, test-only changes and small copy edits. Automated checks run as normal, an AI review at Lite or Balanced level gives a quick second look, and one human or, if your policy allows it, an AI approval is enough. The goal is speed with a safety net.
Tier 2: Standard risk. Everyday feature work and bug fixes that touch application logic but not the most sensitive areas. Automated checks plus a Balanced AI review, and at least one human approval. The human reads the change with the AI’s findings in front of them.
Tier 3: High risk. Changes to authentication and authorisation, payments, personal or sensitive data, security controls, database migrations, infrastructure and deployment configuration, and anything that changes dependencies or the build pipeline. Use the deepest AI review available, such as Max, as an additional pair of eyes, plus two human approvals, security scanning and a named owner. An AI approval should never be the only approval on a Tier 3 change.
GitHub itself suggests pairing Max with approvals on the repositories where a missed issue costs the most. Our model goes a step further by keeping a human in the loop for the changes where the cost of a miss is highest.
Five Questions to Place a Change in a Tier
When a change doesn’t obviously fit, ask:
- How much damage if it’s wrong? Think money, customer data, downtime and reputation.
- How easy is it to undo? A change that can be reverted in minutes is lower risk than a migration that can’t.
- Does it touch sensitive data or access? If so, it moves up.
- How large is it? Agent drafts often span many files, and large changes are harder to review well.
- How well is it tested? Strong, meaningful tests lower the risk. Missing or weak ones raise it.
The second half of the model is about who or what produced the change. Agent-started work isn’t automatically riskier, but you can’t assume the author checked its own work the way a person would, which is why the review needs to be real.
Guardrails for AI Approvals
If you decide to switch AI approvals on, a few rules keep them safe.
Start narrow. Because approvals are off by default, enable them first for low-risk repositories or paths, and widen only once you’ve seen how they perform.
Keep humans on Tier 3. Make a human approval mandatory for sensitive paths, using code ownership rules so it can’t be skipped.
Value independence. A review is more useful when it’s independent of the author. GitHub says Max uses multiple agents across models from different providers, which can help, but it’s still worth checking that the reviewer isn’t simply agreeing with the thing that wrote the code.
Keep the dismissal rule. An approval that disappears when new commits are pushed stops a change being altered after sign-off. Don’t work around it.
Record decisions. Log which approvals were AI and which were human, so you can audit them later.
Review the reviewer. Periodically sample changes that an AI approved and check whether anything was missed. Track defects that escaped review, as we describe in our guide to measuring ROI from AI-assisted delivery.
A Caution on Agent Merge
Agent Merge is useful, because failed workflows and merge conflicts are a common source of delay. But an agent that fixes blockers also has the power to change things your reviewers assumed were fixed. Be especially careful where a “fix” involves tests: an agent that makes a failing test pass by weakening or removing it hasn’t improved the code. Limit which blockers it can fix, require a person to review any change to tests or pipeline configuration, and keep it out of Tier 3 changes unless a human looks at what it did.
Review Capacity and Cost
Tiers also help with budgets. Max uses more AI credits and takes longer than Lite or Balanced, and GitHub now lets Enterprise customers use all Copilot features while paying for the AI credits they use. Running the deepest review on every change would be expensive and slow. Running it only on Tier 3 changes puts the spend where it matters.
Even with AI assistance, human reviewers remain the scarce resource, particularly for high-risk changes. If your team is stretched, flexible engineering capacity through Kilowott Workforce can supply experienced reviewers while you build up your own. And if you’d like help designing the tiers and the rules around them, our work through Kilowott Intelligence starts with measurement and review, not just tooling.
Putting It into Practice
Define your tiers in writing. One page, with examples of what belongs in each tier and what review each one gets.
Map them to paths. Use code ownership and path rules so the tier is applied automatically to sensitive areas, instead of relying on someone to remember.
Automate the basics. Tests, linting, secret scanning and dependency checks should run on every change, which is a natural job for automation.
Pilot before you scale. Try AI approvals on one low-risk repository for a month and compare results with your usual process.
Measure what escapes. Track review time, rework and escaped defects by tier, and adjust the tiers when the data shows a mismatch.
Revisit regularly. Tools, risks and codebases change, so review the tiers every quarter.
A Risk-Tiered Review Checklist
- Wrote down what counts as low, standard and high risk for your codebase
- Mapped sensitive paths to Tier 3 using code ownership rules
- Decided what review level each tier gets, including which changes need a human approval
- Kept AI approvals off until you’ve decided where they’re allowed
- Made human approval mandatory for high-risk changes
- Set limits on what Agent Merge may fix, and required human review of test and pipeline changes
- Logged whether each approval came from a person or an AI
- Sampled AI-approved changes to check for missed issues
- Budgeted AI review credits and reviewer time by tier
- Scheduled a quarterly review of the tiers
Frequently Asked Questions
What did GitHub announce on October 28, 2026? GitHub added a Max review effort level to Copilot code review, which joins Lite and Balanced and is in public preview. Copilot approvals became generally available, and GitHub also announced Agent Merge, which fixes selected blockers on pull requests.
Can Copilot approve pull requests? Yes, when approvals are turned on. They’re off by default, and an approval counts toward required approvals. A new commit after the approval dismisses it.
Should an AI approval ever be the only approval? For low-risk changes, your policy may allow it. For high-risk changes, such as authentication, payments or sensitive data, we recommend always requiring a human approval as well.
What is the difference between Lite, Balanced and Max? They’re review effort levels. Max is the most thorough, running several independent review agents across models from different providers, and takes longer and uses more AI credits than Lite or Balanced.
Does AI code review replace human review? No. It adds a fast, consistent first look, but people remain accountable for what ships, especially for high-risk changes.
How do I decide which changes are high risk? Ask how much damage a mistake would cause, how easily it can be undone, whether it touches sensitive data or access, how large it is and how well it’s tested.
Where to Start This Week
If you only do a few things, begin with these.
- List your riskiest areas. Name the five parts of your codebase where a mistake would hurt most.
- Draft three tiers. Write one short paragraph for each, with the review each one gets.
- Check your settings. Find out whether AI approvals are on for any repository, and who decided.
- Pick a pilot. Choose one low-risk repository to try tiered review for a month and agree how you’ll judge the result.
None of this needs a new tool or a long project. It needs your engineers to agree, in plain language, which changes deserve which kind of attention.
Match the Attention to the Risk
Agents will keep drafting more of the code, and review tools will keep getting more capable. The temptation will be to let them take over more of the sign-off because it’s fast and the queue is long. The better approach is to decide deliberately where speed is the priority and where care is, and to make that decision visible in your rules, not in each reviewer’s head.
Teams that do this get the best of both: quick turnaround on routine changes and real scrutiny on the ones that matter. And they can show, when someone asks, exactly why a given change was approved the way it was. If you’d like to talk through how this might work in your own engineering process, our case studies show how we approach this kind of work, and we’re happy to help you design tiers that fit your codebase.
