# how to review an ai-generated pull request

2026-09-30, updated 2026-09-30

By Jawad Jalal. Founder of Wayari. Builds the desktop app and its coding-agent workflow.

read the goal beside the diff, check what actually ran and inspect the failure path. an ai-written summary is a starting point for review.


Review an AI-generated pull request against its original goal, the exact commit checked and the behaviour the change introduces. Read the failure paths and the unrelated edits before deciding to merge.

A fluent summary makes a change easy to approach. It does not prove that the change does what the summary says.

Start with the request you made. Keep it open beside the diff.

## how do you know the goal was finished?

If the job was to show a login error and allow retry, find both behaviours. A visible error with a permanently disabled button finishes half the job.

List the requested outcomes, then mark the code or observation that supports each one. Anything you cannot connect to evidence needs another look.

Wayari puts a goal check beside the review. It can check sentences that name paths against the diff. It lists the rest for a person to inspect. [The reviewer post](/blog/the-reviewer-is-never-the-author#what-was-asked-and-what-changed-anyway) explains that limit.

A sentence marked as needing your look is unfinished review work. It is not evidence that the requirement passed.

## how do you check that the evidence is current?

A green run on yesterday's head does not check today's push.

Compare the commit in the checks with the commit you intend to merge. If they differ, ask for the relevant checks again.

Read skipped checks too. `unchanged` means a previous answer was reused under the gate's rules. `cannot-check` means there was no answer. Those deserve different decisions.

The [gate documentation](/docs#gates) describes those records. The useful evidence says which command ran, where it ran and what happened.

## which failure paths should you inspect?

The happy path is usually the first thing a builder tests. Review the branch where the network fails, the input is empty or the user tries twice.

For a download button, that means a failed request and a second click. For an export, it means no rows, many rows and a row with a comma inside a field. For a permission change, it means the person who should still be refused.

Pick cases from the feature's actual risks. A generic checklist that nobody adapts eventually becomes a row of ticks.

## how do you handle unrelated edits?

A lockfile change may be necessary. A deleted test may be suspicious. A new default can change every existing caller even when the new screen works.

Ask why those edits are part of this job. Read configuration and public interfaces with the same attention as application code.

Wayari's behaviour diff compares help text, JSON shapes and other declared surfaces. If it cannot compare them, it says so. The absence of a comparison gives you no reason to assume compatibility.

## does an independent reviewer make the patch safe?

The author knows what it intended. Another reader can notice what the patch actually does.

Wayari assigns a reviewer that did not write the change. Its findings name a file, a line and a scenario. Read them with `wayari review` or on the pull request.

A reviewer can stop or run out of time. The pull request can still arrive. Read the record before treating a quiet review as a clean one.

The [review documentation](/docs#review) describes those outcomes. Human approval and time-bounded merge grants are explained in [how Wayari merges](/blog/why-wayari-stops-at-the-pull-request).

## what should you record before merging?

For the login example, keep a short record beside the pull request. Fill it with observations from this change.

| Requirement | Evidence to look for | Still needs your look |
| --- | --- | --- |
| Wrong password shows an error | Changed handler and visible error on `/login`. | Error wording and placement. |
| Retry works | Button becomes usable and another attempt completes. | Behaviour after a network failure. |
| Correct password still signs in | Successful login at the commit being reviewed. | Production configuration if only local was checked. |

## what should block a merge?

Block when a requested behaviour is missing, the evidence checks a different commit or a finding shows a real failure that remains in the patch. Ask for the missing proof when you cannot tell.

Keep style preferences separate from those failures. A finding that names the broken scenario gives the builder a repair it can reproduce.

Before merging, open the changed feature once yourself when you can. The [browser check](/blog/a-green-test-suite-never-opened-the-page) catches defects a diff and a test summary can both miss.

## can you merge when the tests pass but review stopped?

Read why it stopped and inspect the unfinished requirements yourself. Passing checks prove the cases they ran. They do not supply a missing review. [How Wayari merges](/blog/why-wayari-stops-at-the-pull-request) explains the separate approval and merge-grant rules.


[HTML version](https://wayari.com/blog/how-to-review-an-ai-generated-pull-request)