How to review a code change made by AI
To review a code change made by AI, compare the original request with the diff and check the resulting behavior. The tool’s summary guides your reading but does not replace evidence in the files.
A useful review answers three questions: does the change solve the problem, preserve what matters and allow verification? Let us organize that reading before accepting the suggestion.
1. Restate the goal in one sentence
Write the problem using a before-and-after example. “The filter should include items exactly at the threshold” is easier to assess than “improve filtering.”
Separate required behavior from optional improvements. If the goal is fixing a condition, replacing a library should not go unnoticed as an inevitable part of the solution.
2. Observe the extent of the change
Check which files changed and the role of each one. A correction may require several files, but their connection to the problem should be explainable.
The git diff documentation describes comparing changes. In a local repository, an initial reading can use:
git diff --stat
git diffThese commands show changes not yet staged for commit. If the files are already staged, use git diff --cached to inspect that other area.
3. Read behavior before polish
Start with conditions, inputs, outputs and error handling. Then assess names, organization and comments.
For each important section, ask which situation now works and which may produce a different result. Do not confuse a visual reorganization with a behavioral change requiring a test.
| Layer | Review question |
|---|---|
| Scope | Was this necessary for the request? |
| Logic | Which input changes its result? |
| Integration | Who uses this function or output? |
| Evidence | Which check demonstrates the behavior? |
4. Request an explanation you can check
Use AI to locate points of concern, keeping the request tied to the actual files.
Review this diff against the stated goal.
List only changes that affect behavior.
For each, cite the snippet, explain its effect and propose
a test distinguishing the old version from the new version.
Separate discovered defects from questions needing context.
Do not edit files at this stage.A question lacking context should not become an asserted defect. Ask the response to identify what you need to know to decide, such as an external rule or a function consumer.
5. Check the relevant verification
Run tests related to the changed behavior and record their results. If a correction followed the test, recheck the affected part.
The guide to proposing tests with AI helps you choose cases that genuinely distinguish mistakes. Avoid turning a review into checks unrelated to the change.
6. Record a clear decision
The GitHub pull request review documentation distinguishes comments, approval and change requests. Even outside that interface, the distinction helps communicate review status.
Finish with what changed, the evidence checked and any concrete outstanding issue. Someone who did not follow the AI conversation should be able to understand the decision.
Frequently asked questions
What should I check first in an AI-made change?
Compare the requested goal with the files and behaviors changed. Changes outside the scope need a clear justification.
Does an AI explanation replace reading the diff?
No. The explanation helps guide the review, but the diff shows the actual changes.
What evidence should I request before accepting a change?
Request the cases checked, their results and remaining limitations. Check that the tests exercise the version you intend to accept.