How to review an untested path in an AI-written PR

If an AI-written PR says a path was not tested, find the changed behavior it affects, ask what would fail if it is wrong, and request the smallest check that would answer that question. If the risk is too high to leave open, request changes. If you accept the gap, say why in the review so the next person does not mistake silence for evidence.

This is a more useful pull request review than asking the author to run the whole test suite again. A green suite can coexist with a path nobody exercised. The question is which behavior is still unknown and whether that uncertainty is safe to ship.

Find the path behind the gap

Review Assist separates verification.performed, the checks that ran, from verification.not_verified, the paths or scenarios that did not. The guided review shows Checks performed and Not verified side by side. Start with one item in Not verified, then locate the tour stop and diff hunk it concerns. Read the code before deciding whether the gap matters.

For example, a PR adds a 60-second session cache. Unit tests cover cache hits and expiry, but the document says logout followed by reuse of the same token was not verified. That is a specific missing behavior. It is different from a failing logout test, and different again from a test that ran but asserted only that logout returned 200.

If the document only says ‘not fully tested,’ ask the author to name the path, input, and expected result. A vague gap cannot support a review decision. If the diff has an unexplained change, resolve its purpose first; you cannot judge verification against an unknown intent.

Ask for evidence that can change the decision

For the cache example, the narrow check is: log in, warm the cache, log out, then retry the same token before the TTL expires. The expected result is a rejected request. A useful review comment names that sequence and asks for a test result or a code path that proves invalidation occurs before reuse.

• •What changed? Name the branch, condition, or external effect introduced by the PR.
• •What could go wrong? State the consequence if this exact path behaves differently from the author's claim.
• •What would settle it? Request a focused test, a manual reproduction with the observed result, or a trace to an existing guarantee. A test filename alone is not evidence that the risky branch ran.

The Intent Document can record test, manual, build, lint, and typecheck results, but those entries are author-provided evidence to inspect. Review Assist's local submission checks schema, coverage, staleness, cross-references, and likely secrets. The GitHub App recomputes diff coverage. Neither gate runs the missing scenario or proves the recorded test result is true. The specification defines the verification fields, and the architecture separates the local checks from the App check.

Decide whether the gap blocks this PR

Use impact and reversibility, not the number of unchecked items. An untested logout or permission path can leave access open. An untested migration can affect existing data. Ask for a focused check before approval when the plausible failure is serious, hard to detect after merge, or hard to undo.

A lower-impact path may be reasonable to leave open when the behavior is easy to observe and roll back, and the team consciously accepts that risk. Record the condition in the review: what was not run, why the PR can proceed, and who will verify it later. Do not rewrite not_verified as ‘passed’ to make the document look complete.

If the missing check exposes an unverified assumption, connect the two in your comment. For the cache example, ‘logout invalidates this entry’ is the premise, while ‘reuse of the token after logout’ is the missing exercise. One focused test can address both.

Recheck the new head

When the author adds a test or changes the code, review the result on the new PR head. Confirm the test actually takes the previously untested branch and fails when its expected safeguard is removed. Then check that the Intent Document describes the new evidence and any gap that remains. A previous check or comment described the previous diff.

That is the compact code review checklist for an untested path: locate it, name the consequence, ask for decisive evidence, and record the decision. The goal is not a longer list of tests. It is a review record that tells the next engineer which behavior was established and which risk the team accepted.