GitHub Copilot Code Review: how to check AI code before merging

What is Copilot Code Review

It is a GitHub feature that analyzes changes in a pull request or in the editor, leaves comments with severity levels, and, where possible, suggests specific fixes. In simple terms: you isolate new work into a branch, show the difference from the main version of the project, and ask the AI to look for problems before merging.

This process is particularly useful in Vibe Coding. An agent might change a dozen files, while a beginner might only see that the page loaded. A review forces you to pause and check not just the external result, but the logic of the changes.

If you need to check many files identically, distribute them among several agents, and collect a joint report, use the new GitHub Copilot Dynamic Workflows. Standard Code Review remains a simpler choice for a single pull request.

What changed in September 2026

GitHub has updated the interface and review logic. The summary comment now shows the current pull request rating, the depth level used, and grouped results. Copilot more accurately closes its own comments after new commits and can mark the reason as Won't Fix or Incorrect. If multiple compatible suggestions are accepted as a batch, GitHub generates a meaningful commit message.

On September 23, a separate Code Review personal settings page was introduced for all paid Copilot plans. In it, you can enable automatic review during pull request creation, exiting draft mode, new pushes, and even drafts, as well as set your own default check level. For enterprises, a shared default level is available with the ability to override it at the organization or repository level.

Step-by-step: from AI fix to merge

1. Create a separate branch. Don't let the agent work directly in main. A name like feature/contact-form explains the purpose immediately.
2. Verify changes locally. Run the application, tests, linter, and build. AI review does not replace code execution. If the project doesn't build, fix that first.
3. Open a pull request. Write what was changed, why, how it was tested, and what risks you see. A good description provides the same context to both Copilot and humans.
4. Add Copilot to Reviewers. Choose a check level: Lite for a small routine change or Balanced for complex logic, authorization, payments, migrations, and interaction between several services. Don't rely on the label Default: from September 28, it means Balanced.
5. Read the reason, not just the ready patch. For each comment, check the file, the error scenario, and the consequences. If a suggestion is correct, accept it individually or along with a compatible group.
6. Repeat tests. After accepting a fix, run checks again. Even a correct local fix can break another scenario.
7. Request a re-review. Click re-request near Copilot in the reviewers list or open Profile → Copilot settings → Code review and enable automatic checking of new pushes.
8. Involve a human for critical changes. Access to data, authorization, payments, infrastructure, and production configuration requires a human decision, even if Copilot found no issues.

Lite or Balanced

Current GitHub rule: as of September 28, the value Default is set to Balanced for new and existing repositories and organizations. A manual request via the Reviewers block still allows you to select a different level once.

Based on current GitHub estimates, one review typically consumes AI credits costing approximately $0.05 to $1 in Lite and $0.25 to $5 in Balanced. The amount depends on the pull request size and repository instructions and may vary; GitHub Actions minutes are billed separately.

Give Copilot your project rules

Without context, AI sees general practices. With context, it can check your specific rules: allowed dependencies, error formats, mandatory tests, and security boundaries. To add rules for the entire repository, add a file .github/copilot-instructions.md.

# Review Rules

- Do not accept secrets or API keys in client code.
- For every new API route, check authorization and input validation.
- Do not add new dependencies without an explanation in the pull request.
- For bug fixes, require a test that reproduces the issue.
- Respond briefly: risk, reproduction scenario, minimal fix.

For individual directories, you can use files .github/instructions/*.instructions.md, while common rules for different AI agents should be kept in AGENTS.md. An important nuance: during a review, Copilot reads instructions from the branch with the changes. Therefore, a new rule can be verified in the same pull request, but an unintentionally weakened rule will also enter the context.

Pull request description template

Copy this framework into the PR description. It is useful for both Copilot and human reviewers:

What Copilot won't check for you

• The complete correctness of the product. A function might be technically neat but solve the wrong problem.
• All file types. GitHub notes that reviews exclude, among others, dependency management files, logs, and SVGs. These require separate checks.
• Real environment behavior. Code review does not replace running tests, checking mobile versions, accessibility, or production configurations.
• Every single vulnerability. GitHub explicitly warns that Copilot may miss issues and make mistakes.

If the review uses GitHub Actions, agentic skills, or MCP servers, check what external context was involved. Do not give the tool access to systems that are not required for this check. And before publishing, ensure there are no secrets in the changes — use our API key security checklist.

How to verify Copilot's comments

Don't start with the accept button. First, reproduce the scenario the comment is talking about: what data is coming in, in what order the code is executed, and what happens at boundary values. Then open adjacent functions and tests — the problem might not be in the line Copilot highlighted, but in the agreement between several parts of the system.

Ask the AI to explain a minimal failure example, but turn it into a test yourself. If the test fails before the fix and passes after it, you have much stronger proof than a convincing comment. If the observation is incorrect, record the reason in the discussion: for example, the check is already performed at a previous level or the proposed change violates a product requirement. Such a short history will help the next reviewer avoid returning to the same question.

Short checklist before Merge

• Changes are made in a separate branch, not directly in main.
• The pull request has a specific goal and does not mix several independent tasks.
• Build, tests, and linter passed after the latest edits.
• Balanced is selected for complex or sensitive code, Lite for simple code.
• Personal or repository default verified: Lite is intentionally selected for minor reviews, or the need for Balanced is confirmed.
• Every Copilot suggestion is verified, not automatically accepted.
• After fixes, a re-review of the current commit has been performed.
• Secrets, logs, dependencies, and excluded file types are checked separately.
• Critical changes were reviewed by a responsible person.

Frequently asked questions

Is Code Review available for free?

Copilot Code Review is included in paid Copilot plans. Organization members without a separate license can access it on GitHub.com if the administrator has enabled the necessary policies and AI credits payment. The free Copilot plan does not include its own monthly quota for this feature.

Can fixes be applied immediately?

Yes. Individual and batch suggestions are available, as well as passing the task to a Copilot cloud agent via Fix with Copilot. However, after any automatic fix, you must re-read the diff and rerun tests.

Does this replace human review?

No. The best role for Copilot here is the first filter, which finds obvious and some non-obvious problems before a human reviews the code.