Understand the change before reading every line
Code review starts with the problem and the intended behavior. Ask for a short description: what it did before, what changed and how it was tested. When an AI tool has generated a lot of code, that description helps you judge whether the scope matches the request or whether the output includes decisions nobody asked for.
Code that looks consistent can still implement a wrong assumption. For example, a change to a form does not justify broadening a permission on the server. Review the context and the contracts between components before settling for good variable names and tidy formatting. If the change is hard to explain, it is probably worth shrinking.
Look for the places where data turns into authority
Check user input, file access, queries, HTML generation and connections to external services. At every boundary, ask which data is treated as trusted and where authorization is enforced. Client-side validation can improve usability, but it does not replace validation on the server.
As an illustration, an edit request contains a record ID. You need to verify that the user is allowed to edit that record, not just that the ID is valid. A passing test for one user does not cover an attempt to access another user's data.
Check what the tests actually prove
Tests generated alongside the implementation may mirror exactly the same assumptions. Pick an important behavior, change the conditions and see whether the test catches the failure. Depending on the risk of the change, add a duplicate request, missing input, a slow service or the wrong permission.
Do not measure review quality by the number of tests or lines of coverage alone. Ask which significant failure would remain invisible. A contract test or a short integration scenario can tell you things that one more assertion on static text cannot.
Review dependencies and operational changes
If the change adds a library, check why it is needed, what it brings into the artifact and how it will be maintained. Look at the lockfile, configuration and build commands too. Sometimes the main impact lies outside the file the agent described in its summary.
GitHub's responsible use documentation notes that AI agents can produce suggestions that require review and validation. An additional review tool can help surface findings, but it does not turn a suggestion into an approval. Responsibility for the release stays with the process the team has defined.
Decide based on clear evidence
Before merging, go over the final diff and the relevant test results. Make sure the main path and the failure modes can be explained. When a limitation or risk remains unresolved, document it in a way another reader can understand.
- The change is tied to a defined problem and its scope is explained.
- Permissions and input are validated where the action is performed.
- Tests cover meaningful behavior and a failure case.
- New dependencies and configuration have been reviewed.
- There is a way to verify the result after deployment and detect a failure.