How to review pull requests from several coding agents

Ask every agent pull request to be small and to carry its own evidence, then review the queue in merge order, not arrival order. Let a second agent read each one first for the mechanical mistakes, and have a person who knows what was asked decide whether it merges.

One agent's pull request is a normal review. Five from three people's agents in one day is a queue, with its own questions: what lands first, what overlaps, and who reads whose.

What every agent pull request should carry#

The reviewer was not in the conversation that produced the code. The pull request description is the only handoff they get, so make the agent write it to a fixed shape:

## Task
What was asked, by whom, in one or two lines.

## What changed
- Files touched, grouped by area
- Anything outside the task's area, and why

## How it was tested
- The command run, and the last lines of its output
- What was not tested

## Shared contracts changed
- Signatures, schemas, units, routes, config keys (or "none")

## Made by
Agent and person: Claude Code for Priya. Branch: priya/claude/token-refresh

The "shared contracts" line is the one that matters most when several pull requests are open at once. It tells you which other branches may now be wrong. The "how it was tested" line is the one to distrust: check that the command was run after the last edit, not before it. We go deeper on what a good note says in how to share context between Claude Code and Codex, and the glossary defines a handoff in one line.

Five checks that catch most agent mistakes#

Agent code tends to look tidy and pass its own tests. The mistakes are in what it adds around the change, and in what it quietly removes.

Duplicate helpers are the easiest to approve: the new code is clean, and nobody notices the old helper until the two disagree. A 2026 study of agent pull requests on GitHub, More Code, Less Reuse, found that agents often passed over chances to reuse existing code and added more redundant code than human developers, while reviewers responded to those changes with more neutral or positive sentiment than to people's.

Weakened tests come second because they hide everything else. An agent asked to make the tests pass will sometimes do exactly that, to the tests.

Reviewing several pull requests on the same day: merge order and overlap#

Sort the queue by dependency, not by which arrived first. Contract changes go first, then the features that use them, then everything cosmetic. A worked example for one afternoon:

To find overlap before you start reading, list the files each open branch touches and print any file that appears in more than one. The same check, run when a branch is opened rather than reviewed, is in how to stop two AI coding agents editing the same files:

git fetch origin
for b in priya/claude/invoice-pdf sam/codex/csv-export jo/cursor/settings; do
  git diff --name-only "origin/main...origin/$b" | sed "s|^|$b |"
done | awk '{ n[$NF]++; who[$NF] = who[$NF] " " $(NF-1) } END { for (f in n) if (n[f] > 1) print f ":" who[f] }'

Two pull requests that share a file are reviewed together, by the same person, and merged one after the other. After each merge, rebase the rest and run their tests again. An approval given before the previous merge was given against a different main.

Who reviews whose work#

A rule that works for a small team: the person whose agent wrote it reads it first, because they know what they asked for. Then a different person approves anything that touches shared code. Nobody merges their own change to a shared area.

With three people, a fixed rotation saves the daily negotiation:

Put the person and the agent in the branch name, as in priya/claude/token-refresh, so the queue shows whose work each one is. On GitHub, required reviews and a code owners file for shared folders make the rule stick when people are tired. An agent's approval never counts as a person's.

Let a second agent look first, then a person#

A second agent is good at the five checks and tireless about them. Give it a fresh session, ideally a different tool from the one that wrote the code, and a narrow brief:

Review this pull request as a sceptical colleague. Do not change any code.
Check for: helpers that already exist elsewhere, tests that were weakened
or skipped, calls to APIs or options that do not exist in our installed
versions, changes outside the task, and missing edge cases (empty, error,
slow). Then list every shared contract it changes. Reply with findings
only, each with a file and line, most serious first.

Fresh context matters: the agent that wrote the code will defend its choices. The reviewer reports and does not push fixes.

Then a person reads, with the findings beside the diff. The agent catches the mechanical problems. The person decides whether this is the right change at all, which no checklist can.

When this is not enough#

Some pull requests should not be reviewed as they are. If one takes more than one sitting to read, send it back to be split before review, not during it. Anything touching sign-in, payments or permissions gets a line-by-line read from a person who knows that code, whatever the second agent said.

If the queue grows faster than people can read it, a reviewer agent will not fix it. Run fewer agents at once; how to split work between agents covers when splitting stops paying.

Where Joxo fits#

When the agents belong to different people, the hard part is knowing whose work a pull request is and what was asked. Joxo's task board shows who holds each task, and agents write the branch, the commit and the pull request into their handoff, so the reviewer starts from the task rather than from a diff with no story.

When a task with a pull request is finished, its agent can ask for a review. Joxo offers it first to a teammate's agent from a different maker when one is online, never to the author's own computer, and the reviewer checks out the branch, runs the tests and posts one verdict with its findings. You then approve it or ask for changes from your phone or the Tasks page: the second agent looks first, and a person decides, as above. Setup is one line per agent; more in how to coordinate AI coding agents across a team and the FAQ.

Frequently asked questions#

Should an AI agent review another agent's pull request?#

Yes, as a first pass. A second agent in a fresh session is good at mechanical checks: duplicated helpers, weakened tests, calls to APIs that do not exist, and changes outside the task. It should report findings and not push fixes. A person still reads the change and decides whether it should merge, because only a person knows whether it is the change that was wanted.

Who should merge a pull request written by a coding agent?#

A person, never the agent. On a small team, the person whose agent wrote the change reads it first, because they know what they asked for. For anything that touches shared code, a different person approves the merge. A fixed rotation, and the person's name in the branch, make this easy to follow when several pull requests are open.

How do you avoid merge conflicts when several agent pull requests land on the same day?#

Merge in dependency order rather than arrival order: contract changes first, then the features that use them, then cosmetic sweeps. Before reviewing, list the files each open branch touches and review any two that share a file together. After each merge, rebase the remaining branches and run their tests again before approving them.