An agent can produce a convincing explanation and still miss a requirement. Review the code for behavior, scope, tests, and security before you accept it. A careful review does not have to be slow, but it should be based on the diff and the project’s expected behavior.
Read the diff before the summary
Start with the files that changed and ask whether each one belongs to the task. Look for generated output, unrelated formatting, configuration changes, or edits that expand the scope. Then read the implementation in the context of its callers.
Use the agent’s summary as a map, not as evidence. Confirm that the described behavior matches the actual patch and that no important change is missing from the summary.
Check behavior and edge cases
Trace the normal path and at least one boundary or failure path. Ask what happens with missing data, empty input, permission failure, network timeout, or repeated requests when those situations apply to your code.
A test passing is useful evidence, but it does not prove that the test covers the user requirement. Read the assertions and compare them with the acceptance criteria.
- Are errors handled in a way that fits the rest of the project?
- Does the change preserve public behavior that was not meant to change?
- Are secrets, user data, and permission boundaries handled safely?
- Can a maintainer understand why each changed line is there?
Run checks you trust
Run the tests relevant to the changed behavior, then run broader checks when the scope warrants them. If a command fails, decide whether the failure is related rather than asking the agent to hide or weaken the check.
Check the project state before and after the run. Review lockfiles, generated files, and dependency changes carefully because they can affect more than the visible feature.
- Compare the diff with the original task.
- Read the test assertions and important code paths.
- Run relevant checks from a known project state.
- Ask the agent to explain any remaining uncertainty, then verify the answer.
Keep responsibility with the reviewer
The person accepting the patch is responsible for understanding its effect. If you cannot explain what a critical change does, ask for a smaller patch or review it with someone who knows that part of the system.
A useful agent should make review easier by naming changed files, explaining decisions, and reporting checks honestly. The final decision still belongs to the developer who knows the product and its users.