Human review of agent PRs: what to check before you accept

How to review a pull request written by an AI agent: what to check, which changes need human sign-off, the risks and how to avoid approving out of habit.

info Quick Definition
Human review of agent PRs is a person reading a pull request generated by an AI before merging it. They check whether the change does what the ticket asks, whether it is safe and whether it fits the project. Whoever merges it answers for every line, even though they did not write it.

This page is about human judgment on a PR that is already open. How branches are created and diffs are read is in branches and pull requests, and how to show a change before applying it is in previewing changes. Here we cover what changes when the author is an agent.

What changes when you review an agent’s code?

An agent’s PR usually arrives tidy: consistent formatting, reasonable names, green tests. That invites a skim. Google’s review guidance is a good starting point because it does not distinguish authors: it asks reviewers to look at design, functionality, complexity, tests, naming, comments, style, consistency and documentation, and to read every line assigned to them without assuming any part is fine unread (Google, What to look for in a code review).

Three of those questions weigh more with an agent:

  • Complexity. Google asks reviewers to watch for over-engineering: code that is more generic than needed or adds functionality the system does not need today. An agent can add an extra layer as easily as a line.
  • Tests. Google’s question works as it is: would these tests fail if the code broke? If the same agent wrote the change and its tests, check it.
  • Functionality. Code that compiles and looks right does not answer whether it does what the ticket asked, or what happens in edge cases.

What do you check in each PR?

A guide to review standards for AI-generated code proposes ten checks (Metacto, Establishing code review standards for AI-generated code). Grouped, they look like this:

  1. Requirement fidelity. Compare the diff with the ticket’s acceptance criteria, not with what the agent says it did.
  2. Real APIs only. Every module, function, SDK method, command-line flag and config key must exist in the version the repository uses. This is the practical face of hallucinations.
  3. Dependency provenance. A study presented at USENIX Security 2025 generated 576,000 code samples with 16 models and found that at least 5.2% of the packages recommended by commercial models and 21.7% of those recommended by open-source models did not exist (Spracklen et al., We Have a Package for You!). Models have changed since then, but the risk remains: someone can register a package under an invented name and wait for an agent to install it. Before accepting a new dependency, check that it exists, who maintains it and since when.
  4. No secrets in the code. Also check tests, logs and sample data. What to do about an exposed key is in environment variables and secrets.
  5. Input validation and permissions. Protected routes must check who is calling, not just the screen.
  6. Error handling. Empty inputs, denied permissions, a dropped network.
  7. Tests for failure paths, not only the happy path.
  8. Nothing weakened. A PR that skips tests, lowers the coverage threshold or loosens a linter is not ready, even if everything is green.
  9. Architectural fit. The project’s naming, data flow and module boundaries.

One question no list replaces: would I understand this if a colleague had written it? If not, ask for an explanation before you approve. If you do not code, reading code without coding gives you the minimum questions.

Who can approve an agent’s PR?

It depends on the platform, but GitHub gives a clear example with its Copilot coding agent. According to its documentation, a PR created by Copilot needs the same thorough review as any other. If the repository requires approvals, the approval of the person who assigned the task does not count toward the minimum: someone else must approve before merging. Also, GitHub Actions workflows do not run by default on Copilot’s changes until a person clicks “Approve and run workflows”, and the documentation asks reviewers to be especially alert to any change in .github/workflows/ (GitHub Docs, Reviewing a pull request created by Copilot). An administrator can turn that approval off, so do not assume it is on.

The general lesson: the person who requests a change should not be the only one who approves it. On other platforms, confirm which rules exist instead of assuming them.

What needs human sign-off?

Metacto’s guide sorts changes by risk. For high-risk ones (authentication, authorization, cryptography, payments, personal data, database migrations, public APIs, infrastructure and production agent permissions) it proposes that AI only drafts, and that a person rewrites or deeply verifies the code, with senior approval, a security review and a migration plan or threat model. For internal UI, docs or tests with no new trust boundary, the usual approval with automated checks is enough. This is one consultancy’s proposal, not a standard, but the logic is simple: the costlier the mistake, the less of the decision you delegate. It is the same principle as human in the loop.

The same guide recommends that whoever opens the PR declare how much the AI did: whether it drafted the code, the tests, the dependencies or the configuration, and what they personally verified.

Can another AI review it?

It can work as a first pass. But Metacto’s guide is explicit: AI review tools are not an approval authority and should not decide whether a requirement is satisfied, because a generated comment has no accountability and no business context. We add a reasonable consequence, though not a measured one: an automated reviewer that shares assumptions with the agent that wrote the code will tend to confirm its mistakes instead of catching them.

Example

Illustrative example: an agent opens a PR to add email validation to the sign-up form. The diff is small and the tests pass. The reviewer opens the ticket and sees it asked for validation in the form, but the agent also changed the function that sends the welcome email. She goes down the list: the validation function it uses exists, there are no secrets, but the new test only covers a valid email. She asks for two things: revert the out-of-scope change and add a case with a malformed email. The PR comes back fixed and is approved in the second round.

For the side that hands out the work, read agent work queues; to isolate each task, git worktrees for agents. The blog article on a two-agent ticket workflow describes a case where one agent plans and reviews another agent’s work.

Common mistakes

  • Approving because the tests pass, without looking at what they check.
  • Reviewing only style: the expensive part is in the logic and in what should have changed and did not.
  • Accepting a giant PR. Ask for it to be split into one per task.
  • Not verifying that the APIs and packages exist.
  • Clicking “Approve and run workflows” without looking at what changed in .github/workflows/.
  • Thinking “the AI did it” shares the responsibility. Whoever merges, answers.

Sources

Frequently asked questions

How do you review a pull request written by an AI agent?
With the same rigor as one from a person: compare the diff with the ticket’s criteria, check that the functions and packages it uses exist, look for secrets, confirm the tests would fail if the code broke, and check that the change fits the architecture.
Why does AI code need review even when the tests pass?
Because passing tests does not prove the change is what was asked for. A guide to reviewing AI code warns against accepting a patch just because the tests happened to pass, and flags generated tests that assert implementation details instead of behavior as a bad sign.
Which AI changes need explicit human sign-off?
Those touching authentication, authorization, cryptography, payments, personal data, database migrations, public APIs and infrastructure. An industry guide proposes that in these cases AI only drafts, and a person rewrites or deeply verifies the code, with a security review.
Can another AI review the PR instead of a person?
It can do a first pass, but it should not be the authority that approves. The cited guide holds that AI review tools do not decide whether a requirement is satisfied: the merge decision belongs to accountable people.
Can the person who asked an agent for a change approve its PR?
It depends on the platform. With GitHub’s Copilot coding agent, if the repository requires approvals, the approval of the person who assigned the task does not count toward the minimum: someone else must approve before merging.