AI coding agents now open pull requests on their own, and more of them land in front of designers and product managers every month. Many of these pull requests get no human review at all. The code looks tidy, the description sounds confident, and approving feels like the natural next step. That instinct is exactly what makes agent pull requests risky.

Reviewing an agent's work differs from reviewing a colleague's. An agent can't explain its choices in a meeting, its description may promise more or less than the changes deliver, and its code tends to repeat itself in ways that are easy to approve without noticing. On the other hand, agents leave records of what they tried, and they respond to review comments, so a review can steer the work rather than just judge it. Comparing what the description promises with what the files actually show is the heart of the job.

The principle is simple: an agent's pull request is a claim to verify, not a result to trust. Your review is often the only human check it gets, so treat it as real work rather than a formality, and keep reviews focused so your attention lasts for the pull requests that need it most.

Human review of AI pull requests

AI agents now open pull requests at scale. GitHub reported more than 1 million pull requests created by its coding agent between May and September 2025 [1], and each one still needs someone to decide whether it should merge.

GitHub's documentation for Copilot cloud agent is explicit about this: its draft pull requests must be reviewed and merged by a person, and the agent can't approve or merge them itself [2].

That human check is easy to underestimate. Agent code usually looks tidy and confident, which makes careful review feel unnecessary at exactly the moment it matters most.

Agent pull requests left in draft

Agent pull requests left in draft

Agents often open pull requests as drafts, and many never leave that state on their own. A study of 33,596 pull requests from five coding agents found that only 9.8% were ever marked ready for review, and 94.7% of those changes were made by people rather than agents [3].

Copilot cloud agent, for example, can't mark its own pull requests as ready for review at all [4]. Being tagged on an agent's draft means the agent wants attention, not that the work is finished.

The draft label prompts two questions: is this done, and who decides? Marking it ready is a human decision, and it should come after a look at the changes, not before.

Comparing the description with the changes

Comparing the description with the changes

An agent's pull request description is a claim about what it did. The Files changed tab is the evidence. Reading the two side by side is the heart of reviewing agent work.

Mismatches go both ways. A description promising a typo fix next to 14 changed files has done more than it says. A description listing five improvements next to one changed file has done less. Either way, the diff is the truth.

Agents describe their work in confident, polished language that reads like a finished report. Treating each sentence as something to verify, rather than a summary to trust, keeps the review honest, and it applies to any notes the agent leaves on its own work too.

Following the agent's session log

Copilot cloud agent records a session log for each task, showing its internal reasoning and the tools it used to understand the repository [5]. Each commit message links to the log, and View session in the pull request's timeline opens it.

The log answers questions the diff can't: what the agent was trying to do, which files it read, and where it changed course. When a change looks strange, the log often shows the misunderstanding behind it, like a requirement it misread.

Other agents keep similar records under different names. Skimming them is the closest thing to asking an agent why it made a choice.

Duplicated code in AI pull requests

AI agents tend to write new code where existing code could be reused. A study presented at MSR 2026 found that agent-generated pull requests contain more redundant code than human ones, and that reviewers still expressed more neutral or positive feelings toward them [6].

The authors suggest that the surface-level plausibility of AI code hides the redundancy, so technical debt builds up silently. Duplicated code means a later fix may be needed in several places, and the copies can drift apart.

A non-developer can't always spot duplication in code, but can ask about it. A comment like Does this already exist somewhere? costs nothing and often reveals a second copy of a function or a component.

Asking an agent for changes

Agents respond to review comments. On a Copilot cloud agent pull request, mentioning @copilot in a comment asks it to make further changes, and it pushes new commits to the same branch [7]. Copilot only responds to comments from people with write access to the repository [8].

Specific requests get specific results. @copilot keep the price on line 12 at $4 and undo that change only works far better than this is wrong. One clear request per comment also makes each fix easier to check.

Steering the agent in review is often faster than closing the pull request and starting over, as long as the core of the work is right.

Review fatigue with AI pull requests

Reviewing AI work takes sustained attention, and attention runs out. When agents produce pull requests faster than people can read them, the risk is that reviews get shorter, approvals come quicker, and the most plausible-looking changes get the least scrutiny.

A few habits help: keeping agent pull requests small, reviewing at set times rather than in between other work, and agreeing which kinds of change always get a second reviewer.

Automated review doesn't remove the need. GitHub's own documentation notes that Copilot is not guaranteed to spot all problems in a pull request [9]. Neither are tired people, which is why the volume of AI work is worth managing, not just reviewing.

Taking over an agent's pull request

Sometimes an agent gets close but not quite there. Instead of a long back-and-forth, a person with write access can finish the work: the agent's branch is an ordinary branch, so its files can be edited in the browser like any other, and the new commits join the same pull request.

Taking over makes sense for small corrections, like copy, a color, or a wrong value, where explaining the fix takes longer than making it. Larger problems are better solved by closing the pull request and asking again with a clearer request.

A short comment saying what was changed by hand keeps the record clear, so later readers know which parts came from the agent and which from a person.