Using AI Agents for PR Review Without Losing Oversight

To use the GitHub Copilot agent for PR review, open the pull request, find Reviewers in the right-hand sidebar and press Request next to Copilot; from a terminal, gh pr edit <number> --add-reviewer @copilot does the same. Copilot reads the diff and leaves comments, often with suggested changes. By default its review is a Comment, not an Approve or Request changes, so it does not count toward the approvals your branch requires. Claude can review the same pull request, either through Anthropic’s managed Code Review or through a GitHub Actions workflow you own. Keep a person as the required approval, and write the outcome on the task the pull request belongs to.

This post is about an AI agent as the reviewer. If an agent wrote the pull request, start with the GitHub Copilot coding agent and agentic GitHub workflows; the gate described below applies to both.

What Copilot code review does

GitHub’s guide to using Copilot code review↗ (opens in a new tab) describes the whole loop, and it is short:

• You request it from the Reviewers menu. GitHub says the review usually takes less than 30 seconds.
• Comments can carry suggested changes. You can commit one suggestion, or a group of them in one commit, from the pull request page.
• “Fix with Copilot” on a comment hands the change to the Copilot cloud agent, which pushes a commit rather than you typing it.
• After you push new commits, you re-request the review from the same menu. Automatic reviews can be switched on in the repository settings instead, including on new pushes.
• It follows your repository’s custom instructions, such as .github/copilot-instructions.md, so review rules can live in the repository rather than in each person’s head.
• Thumbs up and thumbs down on each comment are how you tell it which comments helped.

What it does not do

GitHub is direct about the limits. Its code review overview↗ (opens in a new tab) says Copilot is not guaranteed to spot every problem, that it will sometimes be wrong, and that you should validate its feedback. It also skips some files entirely, such as dependency files (package.json and lock files alike), logs and SVGs.

The detail that matters most for oversight: by default, Copilot’s review does not count toward required approvals. There is a setting that changes this, in public preview and subject to change. When Copilot approvals are switched on in the repository, organisation and enterprise settings, Copilot can submit an approving review that satisfies the required-approval rule the way a teammate’s would, and that approval is dismissed if new commits are pushed. Whether to switch it on is a decision for whoever owns the repository. If the point of review is that a person has read the change, leave it off, or require more approvals than Copilot alone can give.

Claude as a reviewer: two routes

The first is managed. Anthropic’s Code Review↗ (opens in a new tab), in research preview for Team and Enterprise plans, is switched on by an organisation owner and posts findings as inline comments tagged Important, Nit or Pre-existing. Its check run always finishes with a neutral result, so it never blocks a merge through branch protection, and the documentation says plainly that findings do not approve or block the pull request. You tune what it flags with a REVIEW.md file at the repository root, and ask for a review on demand with a top-level @claude review comment.

The second is a workflow you own. Claude Code GitHub Actions↗ (opens in a new tab) runs Claude inside your own Actions runners. Run /install-github-app from Claude Code to set it up, or add the app, a secret and a workflow file by hand. With the review workflow, Claude posts its review on the pull request as inline comments, or as a single summary comment when it finds nothing.

name: Code Review
on:
  pull_request:
    types: [opened, synchronize, ready_for_review, reopened]
jobs:
  review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: read
      issues: read
      id-token: write
    steps:
      - uses: actions/checkout@v6
        with:
          fetch-depth: 1
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          plugin_marketplaces: "https://github.com/anthropics/claude-code.git"
          plugins: "code-review@claude-code-plugins"
          prompt: "/code-review:code-review --comment ${{ github.repository }}/pull/${{ github.event.pull_request.number }}"
          claude_args: '--allowedTools "mcp__github_inline_comment__create_inline_comment"'

Note the permissions block: the review job reads the repository and posts comments, and nothing in it merges. That is the shape to keep. Claude reads your CLAUDE.md for project rules in both routes, so the conventions you already wrote for coding sessions carry into review.

Or review before the pull request exists

Both tools can also review on your own machine, before anyone else sees the change. In VS Code, the Source Control view has a Copilot Code Review button for uncommitted changes. In Claude Code, /code-review reviews your branch and any uncommitted work in a separate subagent and reports the findings in your session; --comment posts them on a pull request instead. A local review costs nobody else’s attention, so it is a good habit before every push. It does not replace the review on the pull request: that one is where a second person sees the change, and where the record lives.

Keep a person as the gate

An AI reviewer is a filter that makes the human review faster. The gate is a setting, not a habit. GitHub’s protected branches↗ (opens in a new tab) give you what you need on the branch you merge into:

• Require a number of approving reviews before merging.
• Dismiss stale approvals when new commits change the diff, so a push after approval is reviewed again.
• Require the most recent reviewable push to be approved by someone other than the person who pushed it.
• Require review from code owners for the paths that need a specific person.
• Apply the rules to administrators too; by default they can bypass them.

With those set, the AI review can be as loud as you like. It adds comments; a person still reads the diff, answers or resolves each comment, and presses Approve.

Making the AI review worth reading

• Let it go first. Request the AI review when the pull request opens, fix what it found, then ask a person. The person reviews a cleaner diff and spends their time on design and intent.
• Tell it what not to report. Lint, formatting and type errors are already caught by CI; say so in the review instructions so the comments that remain are about behaviour.
• Resolve every comment with a reason. “Fixed in a1b2c3” or “Not a bug: the list is never empty here” — a comment dismissed without a word teaches nobody anything.
• Watch for repeats. GitHub notes that Copilot may repeat comments on re-review even when they were dismissed; that is noise to skim, not a new finding.
• Do not let one agent approve another agent’s work. If the pull request was written by an agent and reviewed by an agent, the only person who has read it is nobody.

Record the outcome on the task

The pull request records the conversation about the diff. It does not record whether the piece of work it belongs to is finished, tested and safe to ship, and it is closed and forgotten once merged. Put that on the task. On fenbs, the task’s ref (BUG-031, say) goes in the pull request title, and when the review is done the task gets a comment: the pull request, what the AI review found, what was fixed, what was waved through and why. Its Testing status and notes say how it was checked. Moving it to Completed is its own permission, so a team can keep that move with a person.

For work a person pre-approved for an AI assistant, the card says “AI done · check it” until someone presses “I’ve checked it”. That button is the board’s version of the approving review: an AI can do the work and the first review, and a named person signs off. Every step is recorded in History, including which changes were made by an assistant.