GitHub Copilot Code Review: Complete Guide

Copilot code review reads a pull request and leaves review comments, with suggested fixes where it has one.

It is a layer, and a genuinely useful one — consistent, tireless, and applied to the whole diff rather than the parts a human has attention for. It is also, by GitHub’s own statement, not guaranteed to spot all problems, which is the specification rather than a disclaimer.

Before you start

• Pull request reviews — the process this joins
• Custom instructions — the mechanism it reads
• AI-assisted Git code reviews — the local layer that runs first

Requesting a review

Copilot is requested as a reviewer, in the same way a person is. It reads the diff and posts comments.

The two modes:

On request. Somebody adds Copilot as a reviewer. Deliberate, and the right default while you are learning what it produces.

Automatically. Configured to review pull requests as they open, and optionally on new pushes. Covered in Automatic reviews.

Re-review is not automatic. GitHub’s documentation is explicit: unless Copilot has been configured to review each push, it will only review a pull request once. For a subsequent review after changes, re-request it through the sync control in the Reviewers menu.

That surprises people — a pull request that changes substantially after its first review has been reviewed in its earlier form only.

What it reads

Not the whole repository. The diff, plus configuration it finds.

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

Path-specific instructions are the mechanism that most improves review quality, because review criteria are rarely uniform. What matters in a database migration is not what matters in a React component, and a single instruction set covering both is either too vague to help or too long to follow.

Some files are excluded by default — dependency files, logs and SVG files among them. Worth knowing when you wonder why a lock file change drew no comment.

Instructions are read from the pull request's head branch

Copilot code review reads its customisation from the head branch — the branch containing the changes — not from the base branch.

That is deliberate and useful: 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. Secure AI code review covers it properly, along with the other untrusted-input concerns.

Approvals and accountability

The property that most affects how this fits your process.

By default, Copilot reviews do not count toward required approvals. A pull request requiring one approval still requires a human one.

That default can be changed. Where Copilot approvals are enabled in repository, organisation or enterprise settings, a Copilot review can satisfy approval requirements in the way a human reviewer’s does.

Turning that on is a policy decision worth making deliberately rather than discovering. It changes what “approved” means on your pull requests, and it does not change who is answerable when something ships broken — which remains whoever merged.

Availability

Copilot code review is available on Copilot Pro, Pro+, Business and Enterprise plans, subject to organisation policy. Which customisation mechanisms apply differs by surface, and whether Copilot approvals count toward required reviews is a repository, organisation or enterprise setting. Confirm the current position in the Copilot code review documentation.

Reviewing large pull requests

The case where AI review’s advantage over a human is largest, and where its limits are also clearest.

The advantage: a human reviewing a 1,200-line change reads the first 200 lines carefully, skims the rest, and approves. That is not a criticism of the reviewer — it is what attention does. Copilot reads all of it at the same standard.

The limit: reading all of it is not the same as understanding the change. A large pull request is usually large because it does several things, and the interactions between those things are exactly what neither a skimming human nor a systematic reader catches.

The practical consequences:

Use it as a reason to look at the parts you skipped. A finding on line 900 is a finding you were never going to reach.

Do not let it justify the large pull request. A review that produced no findings on a 1,200-line change is weak evidence that the change is sound, and no evidence at all that it is well-scoped. “Copilot reviewed it” is not a substitute for splitting a change that should have been three. See PR best practices.

Expect the findings to be local. A comment about a null check is about that line. Nothing in an AI review is likely to say “this change and the one on line 700 are inconsistent with each other”, which is the class of defect large pull requests actually produce.

For a genuinely large change, the useful framing is that AI review handles the mechanical sweep so human attention can go to the structure — which only works if somebody then spends that attention on the structure.

What it is good at

Consistency. The same standard on the four-hundredth pull request as on the first. Human reviewers drift in both directions, and the drift is invisible.

The whole diff. A human skims a 900-line change. This does not.

Mechanical defects. Null handling, unhandled error paths, resource leaks, off-by-one, a copy-paste that was not fully edited. This is where defects actually come from, and it is exactly the category human attention slides off — nobody’s review energy is highest on the fourth similar function.

First-pass triage. Clearing the obvious so a human reviewer’s attention goes to design and intent rather than to a missing await.

Applying written standards. Where you have encoded review criteria as instructions, it applies them uniformly — which is something no team of humans does reliably, because humans have preferences, memories and bad days.

Reviewing at unsociable hours. A pull request opened at 18:00 on a Friday gets the same review as one opened on a Tuesday morning, which is not true of the human alternative.

What it structurally cannot do

Know whether the change should exist. A product question.

Understand why your architecture is the way it is. It sees the code, not the incident that shaped it.

Catch what needs organisational knowledge. That this table is replicated, that this endpoint has a partner contract, that another team owns this module.

Be accountable. Somebody merged the change and answers for it. An AI approval transfers no responsibility, and a process behaving as though it does has removed a control without noticing.

Skills and MCP as review context

Two mechanisms beyond instructions, both worth knowing because they address different limits.

Agent skills carry long procedures that would be impractical as always-on instructions. A full security review checklist with examples, a migration safety procedure, a domain-specific set of criteria — loaded when the agent judges them relevant, costing nothing otherwise.

.github/skills/
├── security-review/
│   └── SKILL.md
└── migration-review/
    └── SKILL.md

The description in a skill’s frontmatter determines whether it gets loaded, which makes it the most important line in the file. A skill described as “reviews things” will not be selected for a migration; one described as “checks database migrations for reversibility, locking and column drops” will.

See Agent skills.

MCP servers give review access to context outside the repository — an issue tracker, internal documentation, an architecture decision record store. A reviewer that can read the linked issue knows what the change was supposed to do, which is otherwise the single largest gap in AI review.

Two cautions, covered fully in MCP + GitHub:

Read-only. A review has no reason to write anywhere.

Every connected server is context and attack surface. External content reaching a reviewer is content that can attempt to influence it, which is the concern Secure AI code review addresses.

What a good review comment looks like

Worth knowing so you can tell whether yours are working, and so you can write instructions that produce them.

A useful finding names four things: where, what, why it matters here, and what would resolve it. A comment saying “consider handling the null case” is weaker than “if get_user returns None here — which it does for deleted accounts, per line 40 — this raises AttributeError before the error handler runs”.

Confidence helps triage. An instruction asking for it changes the output usefully:

For each finding, state how confident you are and what would change your
assessment. If a finding depends on code you have not seen, say so.

That single addition addresses most of what makes AI review comments tiring: without it every finding arrives with identical apparent weight, so triage requires reading all of them equally carefully.

Specificity beats coverage. Five well-grounded findings are more useful than twenty of which five are grounded, because the twenty require the reader to do the sorting.

Suggested fixes

Copilot can propose changes alongside findings, applicable directly in the pull request.

Convenient, and it compresses two judgements into one interaction:

Is the finding real? Frequently it lacked context — it did not see the caller, the decorator, the type that makes the concern unreachable.

Is the fix correct? Even for a real finding, the proposed change may address the symptom rather than the cause, or introduce something else.

Decide the first before looking at the second. They are separate questions and the interface presents them together.

The habit that helps: for a finding you believe, write the fix yourself where it is small. Reading a proposed diff and clicking apply is not faster than typing three characters, and typing it means you engaged with the change.

Reading the output well

Findings are questions. Treating them as defects to be argued with is exhausting; treating them as questions costing seconds to answer is sustainable.

A finding that seems wrong usually means missing context. The fix is a reply explaining what it could not see — which also documents the reasoning for the next reader.

Volume is a configuration signal. Fifteen comments on a twelve-line pull request means instructions are wrong or absent, not that quality dropped.

Silence is not clearance. No comments means it found nothing it was looking for. GitHub is explicit that it will not spot everything.

Getting the configuration right

1. Start on request, not automatically. Reviewers opt in and form an opinion before it appears uninvited.

2. Read the first two weeks as data about your configuration. What proportion of comments were acted on? What did a human catch that it missed?

3. Write instructions from the misses. The findings humans caught and Copilot did not are the gap your instructions should close.

4. Add path-specific rules where criteria genuinely differ — migrations, infrastructure, anything security-sensitive.

5. Then consider automatic review, once the volume is proportionate.

6. Say explicitly that it does not replace peer review. Otherwise somebody will reasonably conclude otherwise, and the first time it matters will be an incident review.

Step 3 is the one that turns a generic reviewer into a useful one, and it is the step teams skip.

Where it fits with the other checks

Copilot code review is one of several things looking at a pull request, and they are not interchangeable.

Check	Finds	Nature
Linters and formatters	Style, some correctness	Deterministic
Tests	Behaviour	The only layer that proves anything
Code scanning	Vulnerability patterns, with data flow	Deterministic analysis
Dependency review	Dependency risk in this change	Deterministic
Copilot code review	Mechanical defects, convention violations, omissions	Probabilistic
Human review	Design, intent, organisational context	Accountable

Two observations that matter for how much weight to put on it.

It is the only probabilistic layer that produces comments. Everything above it either passes or fails deterministically. That difference should shape how you gate on it — which is why “require code scanning results” is a ruleset rule and “require a Copilot review” generally is not.

It overlaps with the local layer deliberately. Terminal review finds similar things before the pull request exists. Catching something locally means it never consumes reviewer attention — the duplication is the point, and the cheapest layer that catches a problem is the right one.

Rolling it out

The sequence that avoids the two failure modes: too noisy on day one, and quietly replacing human review.

1. One team, on request only. Reviewers opt in.

2. Two weeks of observation. Track the proportion of comments acted on, and what humans caught that Copilot did not.

3. Write instructions from the misses, then from the noise.

4. Add path-specific rules for areas with genuinely different criteria.

5. Measure again. The acted-on proportion should have moved.

6. Then automatic review, if volume supports it.

7. State the policy explicitly — that this does not replace peer review, and whether Copilot approvals count.

Step 7 is not a formality. The failure mode is not that anybody decides to remove human review; it is that review gets gradually lighter because a thread of resolved AI comments looks like a reviewed pull request.

Responding to a finding you disagree with

A small point of etiquette that has a real effect on whether the layer stays useful.

Reply, do not just resolve. A finding dismissed silently teaches nobody anything. A reply saying “handled by the @transactional decorator on line 12” documents the reasoning for the next human reader — who will otherwise have the same question.

A recurring disagreement is an instruction. If you are explaining the same thing on every pull request, that explanation belongs in repository instructions. The third time you type it is the signal.

A wrong finding is usually missing context, not a wrong model. “It did not see the decorator” is different from “it was wrong about decorators”, and the first has a fix: put the fact somewhere it will be read.

Some disagreements are worth having with your team. A finding about a convention you deliberately violate is a prompt to ask whether the convention or the violation should change. That conversation is occasionally the most valuable output of the review.

The framing that keeps this healthy: the review is a participant in the pull request discussion, not a gate to be cleared. Threads where somebody explained why a finding did not apply are more useful to the next reader than threads that were silently resolved.

Common mistakes

Expecting automatic re-review. It reviews once unless configured otherwise.

Treating approval as review. It is a signal; somebody is still accountable.

Enabling it everywhere on day one. Volume without tuning teaches people to scroll past.

No instructions. Generic review produces generic findings.

Applying a suggested fix before deciding the finding is real. Two judgements, one click.

Reading silence as clearance. It found nothing it was looking for.

Ignoring the head-branch property on public repositories. The configuration is in the diff.

Removing human review because this is fast. Different layers, and only one is accountable.

Measuring whether it helps

Three numbers, and the wrong one is the tempting one.

The wrong number: comments produced. It measures activity. A configuration producing forty comments per pull request is not four times better than one producing ten; it is probably worse, because nobody reads forty.

Acted-on proportion. What fraction of findings led to a change or a considered dismissal. This is the direct measure of whether the configuration fits the codebase. Low means generic instructions, missing context, or criteria that do not match what your team cares about.

Escapes. The number that matters most, and the slowest to collect. Defects that reached production having passed AI review. Each one is a specific gap, and each is an instruction worth writing. This is the number that actually tracks the layer’s value, and it is slow to collect.

Review round trips. Indirect but useful, and the easiest of the three to pull from existing pull request data without instrumenting anything new: if AI review is doing its job, the number of human review cycles spent on mechanical issues should fall, and the comments humans write should shift toward design and intent.

The one to watch for trouble is the acted-on proportion. When it falls, people have stopped reading — and once that habit exists, the two findings that mattered are scrolled past along with everything else. Recovering from that is harder than tuning the configuration was.

Organisation rollout

At scale the question shifts from “does it work here” to “is it configured consistently”.

Organisation-level instructions apply across repositories, which suits genuinely universal review criteria — a security requirement, a standard everybody holds — and suits nothing else. An organisation instruction wrong for one team is wrong on every review that team gets, and no repository-level file cleanly overrides it.

Repository instructions carry the specifics. Stack, conventions, the things this codebase gets wrong.

Path-specific instructions carry the variation. Migrations, infrastructure, front-end.

Custom agents can live at organisation level, which makes a well-built reviewer a shared asset rather than something each team rebuilds.

The coverage question worth asking: which repositories have review instructions at all? A team with excellent instructions and forty repositories without any has a review layer that is generic almost everywhere. That is usually a bigger gap than any tuning problem, and it is invisible unless somebody looks.

The rollout that works is the same shape as Pillar 5’s security configurations: universal standards defined once at the organisation, specifics owned by the teams, and a periodic check that the specifics exist.

Mental model

Copilot code review is a reviewer who reads every line, never gets bored, applies exactly the standards you wrote down, knows nothing about your product, and cannot be held responsible. Useful, bounded, and not the last check.

What you learned

• Copilot is requested as a reviewer; re-review is not automatic unless configured
• It reads the diff plus repository, path-specific, agent and skill configuration
• Configuration comes from the pull request’s head branch, which has a security consequence
• Dependency files, logs and SVGs are excluded by default
• Reviews do not count toward required approvals by default, and that setting can be changed
• Path-specific instructions are what make review criteria fit the file
• It is good at consistency and mechanical defects, and cannot judge whether a change should exist
• Deciding a finding is real and evaluating its fix are separate judgements
• Silence means it found nothing it was looking for

Exercise

Use a disposable repository with Copilot code review available.

1. Open a pull request with an obvious defect — an unhandled null, a missing await. Request a review. Predict: does it find it?

2. Push a second commit introducing another defect. Predict: does it review again automatically?

3. Add .github/copilot-instructions.md with a specific review criterion. Open a pull request violating it. Predict: does the review mention it?

4. Add a path-specific instruction file for one directory. Open pull requests inside and outside that path. Compare.

5. Modify the instructions in the pull request itself and see whether the review reflects the change. Predict: does it read the head branch?

6. Check whether Copilot’s review counts toward your required approvals. Predict: does the merge button unblock?

7. Delete the repository.

Related lessons

Automatic Copilot code reviewsEnabling it by default, and the noise question.

Custom instructions for AI code reviewMaking review criteria fit your codebase.

Secure AI code reviewThe head-branch property and untrusted input.

AI vs human code reviewWhere each layer's value actually is.