A polished pull request description does not prove that AI generated code is correct. Review the change against the task, inspect what it touches, and run the checks that matter. A short checklist helps you look for the errors that are easy to miss when a patch arrives quickly.
Check intent and scope first
Read the original issue or prompt before you read the summary. Confirm that the patch solves the requested behavior, follows the project conventions, and leaves unrelated files alone. Watch for a test that was deleted, weakened, or skipped because it exposed a real failure.
Compare the changed files with the agent’s explanation. Ask why each dependency, configuration change, and generated file is needed. If the change crosses a security boundary or alters data, involve the person who owns that area.
Run the checks and inspect important edge cases
Run the project tests, type checks, formatter, and static analysis that apply to the change. Confirm that a regression test fails before the fix and passes after it when practical. Exercise a failed request, missing field, empty state, and other edge cases that match the feature.
Check new dependencies and verify their names, source, maintenance, and license. Review authentication, authorization, input validation, error handling, and sensitive data in any affected path. An AI review can suggest questions, but it cannot certify the patch as safe.
| Area | Question |
|---|---|
| Behavior | Does the patch meet the issue and preserve existing behavior? |
| Tests | Do checks exercise the new behavior and the failure cases? |
| Security | Can untrusted input, identity, or data access bypass a control? |
| Dependencies | Does each package exist, have a purpose, and fit the license? |
| Scope | Are generated files, secrets, or unrelated edits present? |
Read the final summary as a claim to verify
Make sure the pull request says which commands actually ran and which did not. Confirm screenshots and measurements against the application. If something failed, include that result rather than describing the work as fully complete.
GitHub’s review guidance covers functional checks, context, code quality, dependencies, and AI specific pitfalls. Use it to strengthen your team’s process, then add a repository checklist for requirements that are specific to your product.
- Read the task and compare it with the full diff.
- Run the relevant checks and inspect edge cases.
- Review dependencies, access control, and sensitive data.
- Verify every claim in the summary before approving the merge.
