The first time I turned on Copilot code review, I watched it comment on a pull request within ninety seconds, felt genuinely impressed, and then spent ten minutes working out why the merge button was still greyed out.
That gap between what it does and what it changes is the whole story. Copilot reviews. It does not approve, it does not gate, and it does not look for the class of problem that actually ends up in an incident report.
None of that makes it a bad tool. It makes it a tool with a shape, and knowing the shape before you build a workflow around it saves the conversation I had with my own team three weeks later.
Here is the setup, and then the honest part.
Getting It Running
You need a paid Copilot plan, and GitHub CLI v2.88.0 or later if you want to do this from a terminal.
Requesting a review is the same gesture as asking a colleague. Open the pull request, find Reviewers in the sidebar, pick Copilot. Or from the command line:
gh pr create --fill --reviewer @copilot
The @ matters. Older CLI versions will not accept it at all.
One thing nobody tells you: the review runs as a GitHub Actions workflow. When a review does not appear, the Actions tab has a run called Copilot code review with real logs, and that is where the answer usually is. I spent an embarrassing amount of time looking everywhere else first.
The Part That Actually Saves Time
Copilot's comments often come with a suggestion block you can commit straight from the pull request. Useful, and applying them one at a time produces a commit per fix, which turns a tidy branch into fourteen commits called "Potential fix for pull request finding".
Use the Files changed tab and Add suggestion to batch instead. Queue everything, then commit once.
If several comments have no ready-made suggestion, or a fix spans files, there is a third option on the summary comment: Fix batch with Copilot. The coding agent works server-side and pushes to your branch a few minutes later. That handles what suggestion blocks cannot, because it writes changes rather than committing pre-written ones.
You can also argue with it. Reply mentioning @copilot in the thread and it responds, having read the whole conversation. Sometimes it concedes. Sometimes it explains something you had not considered. Occasionally it is just wrong, and you resolve the thread and move on.
Making It Automatic Without Making It Annoying
Manual requesting works until someone forgets, which means review coverage depends on who opened the pull request. That is a strange property for a quality process.
Repository Settings, then Rules, then Rulesets. Create a branch ruleset targeting your default branch and enable Automatically request Copilot code review.
The sub-setting underneath it is the one people miss: re-run on new commits. It is off by default, which is why teams end up with reviews that describe code from three pushes ago.
Two other levels exist and interact. An organisation policy overrides everything, so if an admin has turned it off nobody can opt in. And there is a personal toggle in your own Copilot settings that applies to pull requests you open, which the org policy also overrides.
Tuning It So It Stops Repeating Itself
Out of the box Copilot reviews against a generic idea of good code. A .github/copilot-instructions.md file changes that.
# Review instructions
- This is an ASP.NET Core API. Model binding validates inputs at the
framework level, so do not flag interpolated strings in parameterised
query builders.
- Prefer flagging missing null checks on public method parameters over
naming preferences.
- Do not comment on formatting. Prettier handles it.
Keep it short. Three to five bullets beat a long document, because long instructions get squeezed out of the context budget and stop mattering.
The highest-value thing you can write in that file is what your framework already guarantees. That is the biggest single source of comments you will otherwise resolve every week for the rest of the project.
For larger codebases, per-path files under .github/instructions/ with an applyTo glob in the front matter let you give frontend and backend different guidance. They stack on the project-wide file.
The Billing Thing Nobody Mentions Until the Invoice
Copilot moved to usage-based billing in June 2026. Premium request units were replaced by GitHub AI Credits, metered on tokens, and code review carries a published multiplier of 13 against the requests meter.
Separately, because code review now runs on Actions, reviews on private repositories consume Actions minutes at the normal rate. Public repositories are exempt.
Which means if you enable automatic reviews on a repository where Dependabot opens forty pull requests a week, you are now spending from the same Actions pool your CI uses. Worth checking your spending limits before rolling it out broadly rather than after.
Now the Honest Part
Four things Copilot code review does not do, and each one is why teams end up adding something alongside it.
It cannot approve. Its output is comments, never an approval event. A branch protection rule requiring one approving review is not satisfied by it, and it cannot satisfy a CODEOWNERS requirement either. A critical issue sitting in a Copilot comment merges exactly as easily as no comment at all, unless a person reads it and acts.
It is not a security scanner. It reasons about the change. It does not perform taint analysis, secret detection, dependency scanning, or infrastructure-as-code checks. GitHub has those as Advanced Security, a separately licensed product Copilot neither replaces nor surfaces. If you adopted Copilot thinking AI review covered security, that gap is invisible until it is not.
It is scoped to the diff. It reads the change and nearby context. It is not indexing your repository to trace how a changed function is called three services away, and no amount of instruction tuning fixes that.
It does not track anything. No finding state, no ownership, no resolution timestamp. A comment is a comment. If you need to prove findings were resolved within a window, that is a different category of tool entirely.
The Same Feature Is Different on Azure DevOps
Worth knowing if your organisation runs both, which plenty do after an acquisition.
Copilot code review on Azure DevOps is a separate implementation with the same name. It is in public preview with staged regional rollout, and it carries hard caps: 10 GB repository, 100 changed files, the pull request must be active with no merge conflicts. Enabling it takes three levels, organisation then project then repository, and the automatic-review setting lives under branch policies rather than anywhere you would look first.
It also cannot satisfy a required reviewer or block a merge, same as on GitHub. So on the platform whose main strength is policy enforcement, the native AI reviewer sits entirely outside the policy layer.
GitLab's Duo and Bitbucket's Rovo Dev have the same two properties. Different vendors, different licensing, and none of them does dedicated security analysis or changes what can merge.
What I Actually Do Now
Copilot runs on every pull request through a ruleset, with a short instructions file telling it what our framework already handles. It gives every change a baseline read within a minute, which on a distributed team is genuinely better than waiting three hours for someone to open the tab.
And separately, a tool that posts a status check rather than a comment handles the part a comment cannot: security scanning that runs in the same pass, findings checked for whether they are actually reachable, and a gate that holds the merge when something critical shows up. That is what CodeAnt AI does, across GitHub, GitLab, Bitbucket and Azure DevOps, including self-hosted.
The distinction I would offer anyone setting this up: a fast reviewer and a control are two different things, and Copilot is emphatically the first one. Work out which you were trying to buy.
Originally published at codeant.ai, where there is a fuller version including troubleshooting and the platform-by-platform comparison.
Top comments (0)