What to check first
Start with one question: does this PR do exactly what it claimed to do?
- Did the change stay inside the stated module or flow?
- Are there unrelated file changes, formatting churn, or accidental edits?
- Did the AI simplify business logic in a way that changes behavior?
If the scope has drifted, ask the agent to explain each extra change separately before you review anything else.
Second pass: does it actually work
At this stage, do not chase style nits. Look for the failures that would break users or the pipeline.
- Is there coverage for the new behavior, not just the happy path?
- Were tests added or updated for the new code path?
- Does the code depend on hidden values, call order, or local state?
A common AI-PR trap is a solution that looks convincing while only exercising the path the model imagined first.
Third pass: maintainability and security
If the functionality looks correct, check whether the change creates future debt.
- Do the names make the intent easy to understand?
- Is there duplication that should be pulled into a helper?
- Did the PR introduce secrets, tokens, raw URLs, or unsafe assumptions about input?
- Did access or permissions expand “just in case”?
If the code will be hard to change two weeks from now, that is reason enough to send it back, even if the tests pass.
When to send it back immediately
Return the PR for changes if you see any of these signals:
- The PR does more than the stated goal.
- The tests do not cover the new behavior.
- There is a hidden assumption about format, time, or execution order.
- The code includes a security shortcut such as “we will fix it later” or “it is internal anyway.”
Bottom line
An AI-generated PR often looks done before anyone has really checked it. Do not try to read everything. Ask three short questions instead: is this the right change, does it work, and does it create a new risk?
If the answer to any of those is “no,” send the PR back and ask the agent to narrow the change and close the test gaps.
Quick checklist
- Check whether the PR stayed inside the stated task.
- Find evidence for correctness risks directly in the diff.
- Confirm there is a test for the new behavior.
- Check at least one negative or edge-case scenario.
- Review maintainability and security assumptions separately.
- Give an explicit decision: approve, request changes, or block.
Review an AI-generated pull request without blind trust
You are reviewing an AI-authored pull request. Context: - Goal of the change: [describe in one sentence] - Files changed: [paste file list] - Tests present: [paste relevant tests or say "none"] - Risk area: [scope / correctness / maintainability / security / other] Task: 1. Identify anything in the PR that goes beyond the stated goal. 2. List the top 3 correctness risks and the exact evidence in the diff. 3. Check whether the tests prove the new behavior, including at least one negative case. 4. Point out any maintainability or security concerns. 5. Return a merge decision: approve, request changes, or block. Output format: - Scope issues - Correctness risks - Test gaps - Maintainability/security notes - Decision and why