AI is decent at the first pass of a GitHub pull request review. It catches typos, missed null checks, an unused import, a test that doesn't test anything. It's bad at the part that matters most, which is deciding whether the change should exist at all. Use it as a second pair of eyes next to a human. It doesn't replace one.
TL;DR
- GitHub's built-in option is Copilot code review. You add Copilot as a reviewer and it leaves comments. It doesn't approve or block anything.
- Give it repo-specific instructions, or it'll nag you about the same style nits forever.
- Running a model on
gh pr difflocally works fine for a quick sanity check. - AI doesn't fix the real bottleneck, which is finding the PRs that need you and actually getting to them.
What can AI actually do in a pull request review?
Here's my honest list, sorted by how much I'd trust it.
Good at:
- Mechanical mistakes: off-by-one loops, unhandled promise rejections, a variable that shadows another one, a forgotten
await. - Things linters miss but humans find tedious: inconsistent naming inside one file, a copy-pasted block where only half got updated.
- Explaining unfamiliar code. Ask "what does this regex match?" and you'll usually get a useful answer.
- Spotting missing tests for a new branch of logic.
Mediocre at:
- Logic bugs that depend on files it wasn't shown. If the diff changes a function signature and the caller lives elsewhere, the model may never see the caller.
- Security. It'll flag the obvious SQL string concatenation. It won't reliably catch an authorization check that's missing because of how your middleware is wired.
Bad at:
- Architecture and design. Should this be a new service? Should this table exist? No idea.
- Intent. It hasn't read the ticket, the Slack thread, or the incident report that explains why the weird retry loop is there.
- History. "We tried this two years ago and it broke billing" is the most valuable review comment there is, and no model is going to write it.
So the useful framing is that AI handles the boring layer so humans can spend their attention on the layer that needs judgement.
Using Copilot code review on GitHub
If you already have Copilot, the built-in path is the least effort. Open a pull request, click Reviewers in the sidebar, and pick Copilot. Usually within half a minute it posts review comments, often with suggested changes you can commit straight from the PR.
A few things worth knowing, all covered in GitHub's Copilot documentation:
- Copilot submits a Comment review, never Approve or Request changes. It doesn't count toward required approvals, so your branch protection still needs a human.
- You can re-request a review after pushing changes, the same way you would with a person.
- You can have it review every PR, and re-review new pushes, automatically through a repository ruleset, so nobody has to remember to add it.
Tell it about your repo
Out of the box it reviews against generic "good code" taste, which means comments you don't care about. Add a .github/copilot-instructions.md file to the repo. Something like this:
# Review guidance
- Services return Result types; flag any new thrown exception in /services.
- Don't comment on import order or formatting. The linter handles it.
- Raw SQL belongs in /db/queries only.
- Any change to /billing needs a test. Say so if one is missing.
Keep it short and specific. A two-page style guide gets you two pages of style comments. A file that says "don't comment on X" is often the most useful bit.
Rolling your own with the GitHub CLI
If you don't have Copilot, or you want a different model, the GitHub CLI gets you the raw material:
# grab the diff for a PR
gh pr diff 1234 --repo your-org/your-repo > pr.diff
# or check it out locally so a tool can read surrounding files
gh pr checkout 1234
Then hand the diff to whatever model you use, with a prompt along these lines:
Review this diff as a senior engineer. List only real problems:
bugs, missing error handling, missing tests, security issues.
Skip style and formatting. If nothing is wrong, say so.
That last line matters. Models feel obliged to find something, and "if nothing is wrong, say so" cuts down on invented problems.
The big limitation is that a diff is only the changed lines. Checking the branch out and letting an agent-style tool open the files around the change gives noticeably better results than pasting a diff into a chat box.
One boring but important caveat: check your company's policy before you send proprietary code to a third-party model. "I pasted the auth service into a chatbot" is not a conversation you want to have with security.
Where AI review goes wrong
The failure modes are predictable, which at least makes them manageable.
- Confident nonsense. A suggestion that looks right, uses a method that doesn't exist in your version of the library, and gets committed with one click.
- Comment volume. Twenty nitpicks bury the one comment that mattered. After a couple of weeks people start resolving bot comments without reading them, and at that point the bot is worse than nothing.
- False coverage. "Copilot already looked at it" quietly turns human reviews into rubber stamps. The AI pass is supposed to free up attention, not replace it.
- No context. It reviews the code it can see against rules it can guess. Your team's actual rules live in people's heads.
My rule of thumb: treat every AI comment like one from a sharp new hire who read the diff and nothing else. Often useful, sometimes wrong, never the final word.
A workflow that splits the work sensibly
Here's a split that plays to each side's strengths:
- The author runs the AI pass first. Before requesting human review, ask for a Copilot review or run your own prompt, fix the obvious stuff, and dismiss the noise. The human reviewer never sees the typo comments.
- The human reviews what AI can't. Is this the right approach? Are the tests testing behaviour or implementation? What breaks if this is wrong?
- Route to the right person. A CODEOWNERS file auto-requests reviewers by path, so the billing PR goes to whoever owns billing.
- Keep PRs small. Both models and humans review a tight, single-purpose PR far better than a sprawling one. Nobody gives a 2,000-line diff a real review, carbon-based or otherwise.
There's more on the human side of this in my GitHub PR review workflow guide.
The bottleneck AI doesn't touch
Most slow reviews aren't slow because reading the diff is hard. They're slow because the PR sat in a queue nobody was looking at. The review request got buried in notification email, or it was tab number fourteen and you closed the window.
GitHub's search qualifiers help a lot here. Save these as bookmarks:
is:pr is:open review-requested:@me
is:pr is:open user-review-requested:@me draft:false
is:pr is:open author:@me review:changes_requested
is:pr is:open reviewed-by:@me
review-requested:@me includes requests made to teams you're on. user-review-requested:@me only shows PRs where someone asked for you specifically, which is usually the list that actually matters. The full set is in GitHub's issue and PR search docs.
This is the problem I built PRFlow for. It's a Chrome side panel that keeps your open PRs across repos visible next to whatever tab you're on, showing status (pending, changes requested), labels, comment counts and diff size. It has filters for the queues above: needs my review, created by me, and reviewed but not merged. So the PR waiting on you doesn't depend on you remembering to check.
To be plain about what it doesn't do: PRFlow has no AI review. It doesn't write comments, and it doesn't replace GitHub's diff view. You still click through and review on GitHub, with or without Copilot. It covers the getting-to-the-PR part, which in my opinion is where most of the waiting happens. If tab sprawl is your particular pain, this post on too many GitHub tabs goes deeper, and there's a roundup of other Chrome extensions for code review if you want options.
Is AI pull request review worth turning on?
For the mechanical layer, yes. It's cheap, it's fast, and catching a missing await before a human spends time on it is a real win. Just don't expect it to tell you whether the PR is a good idea.
If you turn it on, turn it on with an instructions file, and watch comment volume for the first couple of weeks. When people start resolving bot comments without reading them, you've got noise, not review. Trim the instructions until the comments are worth reading again.