How to review a pull request an AI agent opened

Review an AI agent's pull request in a fixed order: check that the checks are still honest, then check that the change does what was asked, then read the code. Most of the risk in an agent's pull request is not in the code style. It is a weakened test, an invented dependency, or code that passes every check and does the wrong thing. Those are cheap to find if you look for them first, and easy to miss if you read the diff from the top. Anything a machine can check should be checked before a person opens the pull request, because review time is now the part of the process that runs out first.

Why is review the bottleneck now?

Because the volume went up and the number of reviewers did not.

Faros AI measured over 10,000 developers and found that teams with high AI adoption merged 98% more pull requests, while review time rose 91% and average pull request size rose 154%. GitHub reported 43.2 million pull requests merged a month in 2025, up 23% in a year. LinearB's 2026 benchmarks, across 8.1 million pull requests, found that AI-generated pull requests wait 4.6 times longer before anyone picks them up, and that 32.7% of them are accepted against 84.4% of those written by hand.

That is the same pattern we describe in how much agent work a human should review. Writing code got cheaper and reading it did not, so the queue moved to review.

Is AI-written code worse?

On the evidence so far it carries more issues, and the security results have barely moved.

CodeRabbit compared 470 open source pull requests and found 1.7 times as many issues in those written with AI, with logic errors about 75% more common. The sample is small and CodeRabbit sells AI review, so treat the multiple as a direction rather than a constant. Veracode tested over 100 models on security-sensitive tasks in 2025 and found that 45% of cases introduced an OWASP Top 10 weakness. Its 2026 update put the average security pass rate at 56%, virtually unchanged, while code that compiles was close to 100%.

Code that compiles but is insecure or wrong is exactly what a fast read misses.

What should you check first?

Check the things that make the other checks lie.

1. Did the pull request weaken CI? A lowered coverage threshold, a skipped or deleted test, or a changed workflow condition. GitHub's own guidance on agent pull requests is blunt: "Any change that weakens CI is a blocker." An agent that cannot make a test pass sometimes makes the test stop running instead.
2. Do the new dependencies exist? A USENIX Security 2025 study of 16 models found that 19.7% of package references were to packages that do not exist, and that 43% of invented names came back every time the same prompt was run. Repeatable invented names can be registered by an attacker in advance. Look up every package the agent added.
3. Is there a test that fails on the old code? A new test that would also have passed before the change proves nothing about the change.
4. Did it touch the workflows or the permissions? Changes to .github/workflows or token scopes deserve a separate, slower read.

None of these needs you to understand the feature. They take minutes, and a failure on any of them sends the pull request back before you spend an hour on it.

Then check the change against what was asked

The most common failure in agent work is not broken code. It is working code that does something slightly different from what the task asked. GitHub calls it hallucinated correctness: it compiles, passes its tests, and is wrong.

You can only catch it if the task said what done means before the work started. Read the definition of done first. Then trace the critical path in the diff against each line of it. A clause the diff does not address is a finding, however good the rest of the code is. If the task had no written definition of done, the review has nothing to measure against, and that is the problem to fix first.

How big should an agent's pull request be?

Small enough to read in one sitting.

The SmartBear study of review at Cisco recommends no more than 200 to 400 lines at a time, at under 500 lines an hour. Google's engineering practices call 100 lines usually reasonable and 1,000 usually too large, and allow a reviewer to reject a change for size alone. Those figures predate agents, but human reading speed has not changed. An agent can write 2,000 lines in a few minutes. That does not make a 2,000-line pull request reviewable.

Send it back and ask for smaller pieces if it touches unrelated files, if its purpose does not fit in one sentence, or if it has no plan.

What should not be done by hand?

Anything deterministic. Running the tests, the type checker, the linter, the dependency audit and the security scan is work for a machine, and it should finish before the review request reaches a person. GitHub's automated reviewer now handles more than one in five code reviews on GitHub. That is a reasonable first pass, provided it is not the same model reviewing its own work.

The person's job is what the machine cannot settle: whether the change is the right one, whether it fits the system, and whether its evidence holds up. That is also why the author should not be the approver. GitHub's rule for Copilot's pull requests is that the person who asked for the work cannot be the approval that counts.

How does Cognibl handle this?

Each task's pull request is summarised on the task as one headline and a next step: checks, reviews, open comments, conflicts and draft state together. An agent pushes through Cognibl's git proxy, which refuses a push to the base branch, so its work always arrives as a pull request. A repository can declare its own checks, and the harness runs them before the agent's run ends. A reviewer agent can mark each clause of the definition of done as met, not met or cannot tell. It can never review its own work. A task only completes with a proof of work attached. If a merge is later reverted, the task says so instead of staying done.

See how Cognibl reads a pull request.