An AI reviewer reads every line of every pull request, never gets tired, never skips the boring parts, and has no idea what your product does or why the change was requested.
Both halves of that are true simultaneously, and the second half is why this cluster spends as much time on what AI review cannot do as on how to configure it.
Start with Copilot Code ReviewThe layered model
Section titled “The layered model”AI review is a layer. It is not the layer.
A vertical chain: developer self-review, AI review, automated tests and scans, human peer review, repository policy. Each layer catches different classes of problem.
The ordering is deliberate. AI review sits early, where its speed matters and its lack of judgement costs least — it cleans up the obvious before a human spends attention. Putting it last, as a final gate, inverts its strengths.
Note which layer is load-bearing. Tests and scans are the only ones that prove anything. Human review is the only one where somebody is accountable for the merge. AI review is neither, and is still worth having.
What AI review is genuinely good at
Section titled “What AI review is genuinely good at”Consistency. It applies the same standard to the four-hundredth pull request as to the first. Human reviewers do not, and both directions of that drift are real.
The boring, valuable checks. Null handling, error paths not covered, resource leaks, off-by-one, a copy-paste that did not get fully edited. These are where defects actually come from, and they are exactly what human attention slides off.
Reading the whole diff. A human reviewer skims a 900-line change. AI reads all of it.
First-pass triage. Clearing the mechanical problems so a human reviewer’s attention goes to design
and intent rather than to a missing await.
What it structurally cannot do
Section titled “What it structurally cannot do”Know whether the change should exist. Whether this feature is the right answer to the underlying problem is a product question.
Understand your architecture’s reasons. It sees the code, not the incident three years ago that made you do it that way.
Catch what depends on organisational knowledge. That this module is owned by another team, that this table is replicated, that this endpoint has a partner contract.
Be accountable. This is the one that matters. Somebody merged the change; that person answers for it. An AI reviewer’s approval transfers no responsibility whatsoever, and any process that behaves as if it does has quietly removed a control.
The lessons
Section titled “The lessons”- Lesson 1: 01. GitHub Copilot Code ReviewRequesting and configuring Copilot code review — what it reads, path-specific instructions, skills and MCP context, re-review behaviour, required approvals, and the documented limits.
- Lesson 2: 02. Automatic Code ReviewsEnabling Copilot code review by default at repository or organisation level, choosing what it reviews, controlling noise, and the difference between an automatic review and a required one.
- Lesson 3: 03. Custom Instructions for ReviewWriting repository, path-specific and organisation review instructions that change what Copilot finds — with the file precedence, what makes a criterion checkable.
- Lesson 4: 04. AI vs Human ReviewWhat each review layer is actually for — the defect classes AI catches reliably, the judgements only a human can make, and how to combine them without either becoming a formality.
- Lesson 5: 05. Secure AI Code ReviewThe security properties of AI review on untrusted pull requests — head-branch instruction reading, prompt injection through diffs, what a review can and cannot be trusted to enforce.
- Lesson 6: 06. Pull Request AutomationUse AI to automate the mechanical parts of a pull request — descriptions, labelling, triage, reviewer routing, merge readiness — and draw the line where a human decision has to stay.
Lesson 1 is the cornerstone: what Copilot code review does, what it reads, what it misses. Lesson 2 covers automatic review and the noise it can generate. Lesson 3 is customisation — making review enforce your standards rather than generic ones. Lesson 4 is the balanced comparison, and the page to send somebody who thinks AI review replaces peer review. Lesson 5 is security, including the head-branch property below. Lesson 6 covers the wider automation around a pull request, and separates deterministic automation from AI judgement.
What review reads
Section titled “What review reads”Copilot code review is not reading your codebase from scratch. It is reading the diff plus whatever configuration it finds, and the configuration is the part you control.
| Source | Effect |
|---|---|
| The pull request diff | The change under review |
.github/copilot-instructions.md | Repository-wide review guidance |
.github/instructions/*.instructions.md | Rules scoped to matching paths |
AGENTS.md | Cross-tool agent guidance |
.github/skills/ | Task-specific knowledge loaded when relevant |
| MCP servers | External context, where configured |
The path-specific mechanism is the one that changes review quality most, because review criteria are rarely uniform. What matters in a database migration is not what matters in a React component, and a single set of instructions covering both is either too vague to help or too long to follow.
Some files are excluded from review by default — dependency files, logs, SVGs — which is sensible and worth knowing when you wonder why a lock file change drew no comment.
GitHub is explicit that “Copilot is not guaranteed to spot all problems or issues”. Treat that as the specification rather than a disclaimer: the layer is probabilistic, so nothing that must be caught can depend on it alone.
Noise is the failure mode
Section titled “Noise is the failure mode”The way AI review actually fails in practice is not a missed bug. It is fifteen comments on a twelve-line pull request, of which two matter.
That outcome trains a specific and durable behaviour: contributors stop reading AI comments. Once that habit exists, the layer has negative value — it costs review latency and delivers nothing, and the two real findings are now scrolled past along with everything else.
The controls are ordinary tuning:
- Instructions that say what you care about, so the review is about your standards
- Path-specific rules, so the criteria fit the file
- Careful use of automatic review, particularly on repositories with high pull request volume
- Treating comment volume as a signal — a sudden increase usually means an instruction changed, not that quality dropped
The metric worth watching is not how many comments AI review produces. It is what proportion of them lead to a change. If that number is low, the configuration is wrong, and leaving it wrong is how the layer gets switched off.
One security property worth knowing now
Section titled “One security property worth knowing now”Copilot code review reads its customisation — repository instructions, path-specific instructions,
AGENTS.md, skills — from the pull request’s head branch: the branch containing the changes.
That is a deliberate and useful design. It means you can change your review instructions and see the effect in the same pull request, rather than merging blind.
It also means that on a repository accepting pull requests from untrusted contributors, the review configuration is part of the code being reviewed. A contributor can modify the instructions that shape the review of their own change.
This is not a catastrophe and it is not nothing. The controls are the ones you already have: human review of the diff — including its instruction files — and rulesets that decide what can merge. Secure AI Code Review covers it properly, with the other untrusted-input concerns.
Prerequisites
Section titled “Prerequisites”Adopting it without losing the room
Section titled “Adopting it without losing the room”AI review changes a shared social process, which makes rollout as much a communication problem as a configuration one.
-
Turn it on for one team, on request rather than automatically. Reviewers opt in, see what it produces, and form an opinion before it appears uninvited on their work.
-
Read the first two weeks of comments as data about your configuration. What proportion were acted on? What did it miss that a human caught? Those two numbers drive everything after.
-
Write instructions from the misses. The findings a human caught and AI did not are the gap your instructions should close.
-
Add path-specific rules where review criteria genuinely differ — migrations, infrastructure, anything security-sensitive.
-
Then consider automatic review, once volume is proportionate.
-
Say explicitly that it does not replace peer review. If this is not stated, somebody will reasonably conclude otherwise, and the first time it matters will be an incident review.
Step 6 is not a formality. The failure mode is not that anybody decides to remove human review; it is that review gets lighter, gradually, because a green AI comment thread looks like a reviewed pull request.
Common mistakes
Section titled “Common mistakes”Treating AI approval as review. It is a signal. Somebody still has to be accountable for the merge.
Enabling automatic review everywhere on day one. Volume without tuning teaches everyone to scroll past AI comments, and that habit outlasts the fix.
Not writing review instructions. Generic review produces generic findings. The specific things your codebase gets wrong need saying.
Expecting instructions to be followed exactly. They shape a probabilistic process. Anything that must hold is a test or a ruleset.
Ignoring the head-branch property on public repositories. The review configuration is part of the diff.
Removing human review because AI review is fast. The layers catch different things, and only one of them is accountable.
After this cluster
Section titled “After this cluster”Review is AI reading work that already exists. The final cluster is AI producing it — delegated agents, skills, MCP, and the automation that takes an issue to a merged pull request.
Next cluster — AI Agents + GitHub