# How to Review Pull Requests From AI Coding Agents

> How to review AI agent pull requests: inspect the run behind the diff, read test and CI changes first, check behavior live, and keep a second human in the loop.

Updated October 24, 2026 (first published July 10, 2026) · by the AQ team · Canonical: https://aq.dev/guides/reviewing-pull-requests-from-ai-agents/

To review a pull request from an AI coding agent, change what you review: read the test and CI changes before the implementation, inspect the run that produced the diff (what the agent read, ran, and reacted to), verify behavior in a running app instead of simulating the code in your head, and make sure a second human looks at the change, not just the person who asked for it. Agents like Claude Code, Codex, and GitHub Copilot's coding agent have made PRs cheap to produce; review is now the bottleneck, and a review process designed for human-authored PRs will not survive the volume.

Review is also what makes running agents at scale safe at all. A team can let five agents work overnight precisely because every change still passes through a human gate before it merges. This guide is the practitioner's workflow for keeping that gate real when the PR count triples.

## Why agent PRs break the normal review process

Human PRs arrive with context attached: you know who wrote it, you were in the design discussion, you can ask "why did you do it this way?" and get an answer grounded in intent. Agent PRs strip that away. The diff is often large, plausible-looking, and confidently wrong in one specific place. Three failure modes recur:

- **Plausible wrongness.** Agent code reads clean. The bug is not sloppy syntax; it is a wrong assumption executed flawlessly, which skims right past a tired reviewer.
- **Untracked scope.** Agents fix what you asked and then helpfully "improve" three adjacent files. Every unrequested change is unreviewed risk.
- **Volume.** Rubber-stamping starts the day reviewers fall behind, and with agents, falling behind takes one afternoon.

The fix is not heroic diff-reading. It is changing the unit of review.

## Get a second human on the PR

The most common failure in agent-PR review is structural, not technical: the review collapses into self-review. A July 2026 [LeadDev analysis](https://leaddev.com/ai/ai-coding-agents-kill-team-collaboration) of 25,264 agent-generated pull requests across 2,361 popular GitHub repositories found that in 79 percent of agentic PRs the same developer both reviewed and modified the agent's contribution, and only about one in eight workflows involved multiple humans. One person prompting, merging, and fixing the same change means nobody with distance ever looked at it, which is exactly the [self-review problem](https://aq.dev/self-review-problem/) code review exists to prevent.

Platforms are starting to enforce this. As of October 2026, GitHub's documentation states that if your repository requires approvals before merging, your own approval of a Copilot coding agent PR you asked for does not count toward the required number; another reviewer must approve it. Whatever harness you run, adopt the same rule by convention: the person who prompted the agent prepares the PR for review, and a different human approves it.

## Review the run, not just the diff

A diff tells you what changed. The run tells you why, and the why is where agent bugs live. Did the agent read the relevant code before editing it? Did it run the tests, and did it react to a failure by fixing the cause or by weakening the assertion? Did it thrash (a signal the task was underspecified) or move linearly?

Five minutes scanning the session transcript routinely surfaces what an hour of diff-reading misses: the moment the agent misread a requirement, silenced a failing test, or guessed at an API. This is the single highest-leverage habit in agent-PR review, and it requires that the run still exists when review happens: a session that died with a laptop lid or scrolled out of a local terminal cannot be inspected. The full method is its own guide: [how to review an AI coding session](https://aq.dev/guides/how-to-review-an-ai-coding-session/).

## Read the test and CI changes first

Agents are good at making CI pass; that is precisely why a green check means less on an agent PR than it used to. GitHub's own reviewer guidance for agent PRs, current as of October 2026, treats any change that weakens CI as a merge blocker and recommends checking workflow files, test configuration, and coverage settings before reading application code. The classic agent shortcuts are deleted assertions, widened tolerances, skipped cases, and a test command that cannot fail.

So order the review deliberately:

- **CI and workflow files first.** Any edit under the CI directory, to coverage thresholds, or to lint configuration gets read before anything else.
- **Test diff second.** If tests changed, review those hunks before the implementation. A test edited to match broken behavior is the most expensive bug an agent ships.
- **Ask what is not covered.** Agents write tests that pass, which is not the same as tests that constrain. Check error paths and boundaries yourself, or prompt the agent to test a case you suspect and watch it run. "Tests passed" is a claim to verify, not a fact: [how to verify agent work](https://aq.dev/guides/verify-ai-coding-agent-work/) covers re-running the evidence.

Treat CI as the floor, not the bar: red means the PR is not reviewable yet, green means the real review can begin. Note that the floor needs a gate of its own: as of October 2026, GitHub Actions workflows do not run automatically when Copilot's coding agent pushes changes; a person reviews the branch and clicks "Approve and run workflows" (repository admins can optionally disable that approval step, which GitHub added as an option in March 2026 while keeping approval the default).

## Review behavior, not just code

For anything with a surface (UI, API, CLI), the diff is a proxy; behavior is the ground truth. Reviewers approve visually broken changes all the time because the diff "looked right." Run the branch and click through the actual feature the agent built. For UI changes, two minutes in a running app beats twenty in the diff. The practical blocker is setup cost: if checking behavior means a local checkout, dependency install, and environment setup per PR, nobody will do it at agent volume, so make a running preview of the branch a one-click artifact of the workflow rather than a favor the reviewer does.

## Keep one PR per task, small and rebased

Everything above gets easier when the unit of work stays small:

- **One task, one branch, one PR.** If an agent's work wants to be three PRs, make it three tasks, each in its own isolated worktree or clone.
- **Keep it rebased.** A stale branch hides integration bugs until after approval. Rebase onto the latest main before serious review, so the diff you approve is the diff that merges.
- **Reject scope creep mechanically.** Unrequested changes come out of the PR, even good ones. They can be the next task. This is the cheapest rule to state and the one that most protects review quality.

## Can AI review the AI's PR?

Partially. An AI reviewer is a useful first pass at agent volume: as of October 2026, GitHub offers Copilot code review on pull requests (generally available, with GitHub's own docs noting it is not guaranteed to spot all problems), and Anthropic's Claude Code GitHub Actions integration reviews or responds on a PR when mentioned. These catch mechanical issues (dead code, obvious logic slips, style drift) and cut the noise a human has to wade through. What they cannot do is close the loop on intent: whether the change does the right thing for the reason the task existed is still a human call, and an AI approving AI work recreates the self-review problem with extra steps. Use the machine pass to protect human attention, not to replace it; [what AI code review can and cannot catch](https://aq.dev/guides/what-ai-code-review-can-and-cannot-catch/) draws the line in detail.

## Where AQ fits

AQ is the multiplayer coding harness where engineering teams run AI coding agents like Claude Code and Codex together: shared live terminals, a code editor, and app previews, in your own cloud. The review workflow above is built in rather than bolted on. Every agent runs in a persistent session that survives laptop close, so the run that produced a PR is still there at review time: a reviewer opens the workspace and scrolls back through what the agent read, ran, and fixed, or watches it live. Because workspaces are shared, the second human enters the same session and can prompt the agent directly ("run the failing test and show me"), and handoffs keep full context instead of starting from a cold diff.

Behavior review costs one click: each workspace runs its own dev server with a shareable preview link that works without an account for viewing. Reviewers pin comments on the preview itself (screenshots supported for teammates) and send them to the agent as prompts, so "this dropdown clips at 375px" goes from observation to instruction in one step, and the fix lands on the same branch and PR. The small-PR shape is enforced naturally: each workspace is one isolated git worktree on its own branch with a one-click rebase onto main, and its PRs are tracked per workspace. That trust layer is what makes the rest of AQ safe to use at full speed: you can [run many agents in parallel](https://aq.dev/guides/run-multiple-ai-coding-agents-in-parallel/) or [overnight](https://aq.dev/guides/overnight-coding-agent-runs/) because every run can be replayed and every change still meets a human reviewer.

Review bandwidth is the scarce resource in the agent era. Spend it on judgment (does this change do the right thing?) and let the process carry the mechanics: runs you can inspect, tests read first, previews you can click, a second human on every merge.

## Frequently asked questions

### Should a human review every pull request an AI agent opens?

Yes, and ideally a different human than the one who prompted the agent. A July 2026 LeadDev analysis of 25,264 agent-generated PRs found the same developer both reviewed and modified the agent's contribution in 79 percent of them, which is self-review by another name. GitHub already enforces the principle for its Copilot coding agent: as of October 2026 your own approval of a Copilot PR you asked for does not count toward required approvals.

### How is reviewing an AI agent's PR different from reviewing a human's?

The context is missing and the volume is higher. Agent code looks clean but can be confidently wrong in one spot, so you review the run (what the agent read, ran, and reacted to) and the behavior (in a running app), not just the diff, and you read the test and CI changes before the implementation. Strict scoping (one small PR per task) is what keeps the process alive at agent volume.

### What should I look at first in an AI-generated pull request?

CI and test changes. The classic agent shortcut is making the check pass rather than fixing the code: deleted assertions, widened tolerances, skipped cases, edited workflow files or coverage thresholds. GitHub's reviewer guidance for agent PRs treats any change that weakens CI as a merge blocker. Read those hunks first, then the implementation.

### Should CI passing be enough to merge an agent PR?

No. Agents are specifically good at making CI green, sometimes by weakening tests rather than fixing code. Treat CI as the floor: it filters out unreviewable PRs. The bar is human review of the test diff, the behavior in a running preview, and the run that produced the change.

### Can I use AI to review an AI agent's pull request?

As a first pass, yes: AI review catches mechanical issues and cuts noise before a human looks. But an AI approving AI work recreates the self-review problem, so keep a human on the final approval, especially for intent (is this the right change?) and for anything touching tests, CI configuration, or security boundaries.

### How do I send review feedback back to the agent?

Prompt it in its own session instead of round-tripping through comments the agent never reads. In AQ a reviewer opens the same workspace and types follow-up prompts into the live session, or pins comments on the dev-server preview (with screenshots) and sends them to the agent as prompts. The fix lands on the same branch and PR.

---

About AQ: AQ is the multiplayer coding harness where engineering teams run AI coding agents like Claude Code and Codex together: shared live terminals, a code editor, and app previews, in your own cloud. Start at [aq.dev](https://aq.dev/).