Review AI-generated code

Read the requirement before the summary

Start with the requested behavior and acceptance criteria. Then inspect the actual diff. An agent’s summary can help you navigate, but it can omit changes or describe checks inaccurately.

Confirm the branch and commit under review. Check for configuration, dependency, infrastructure, and test changes as well as application code. A small visible feature can include a large change to permissions or deployment behavior.

Review the highest-consequence behavior first. Formatting and naming matter, but they should not distract from a missing data boundary.

Trace identity to the resource

Consider this incomplete, fictional endpoint. The example illustrates a review problem; it is not production code.

async function getInvoice(request) {
  const user = await requireSignedInUser(request);
  return database.invoice.findById(request.params.id);
}

The function obtains an authenticated user. It does not show an authorization decision for the invoice. A reviewer must inspect whether another layer enforces that decision. The unused user value is a reason to investigate, not proof of an exploitable defect by itself.

Trace the request through the actual system. Identify the trusted user and organization. Check how the query limits access to the requested record. Inspect error behavior and tests for forbidden requests.

Do not assume that a hidden button protects the API. A caller can send a request without using the interface. Do not assume that a valid record ID grants access.

Ask what evidence could reject the change

A passing test may use an administrator fixture or mock authorization. Check whether it exercises the boundary that matters. Add a case with a different organization and a real authorization path where appropriate.

For a user interface change, inspect the rendered result. Check keyboard operation, empty states, loading behavior, and errors. A type check cannot establish that a dialog is usable with a keyboard.

For a dependency change, verify why it is needed. Review the version, license, and security findings. Do not accept an unrelated upgrade only because the agent generated it during the task.

Keep review independent

A second model can identify useful problems. It can also repeat assumptions from the implementation. Give a reviewer the requirement and diff. Avoid telling it that the change is already correct.

Require findings to identify a concrete failure path and the relevant code. Treat unsupported warnings as questions to investigate. Treat confident approval as another opinion until the important claims have evidence.

Human review remains a decision about responsibility. A reviewer should understand enough of the change to explain its behavior, risks, and verification. If the diff is too large, reduce the scope or divide it into reviewable changes.

Close the review on the final revision

After a correction, rerun the affected checks. Inspect whether the correction creates a new problem. Ensure that required review applies to the final revision under the repository’s policy.

Write the acceptance decision in terms of behavior and evidence. Record any remaining limitation with an owner and a next action. Do not convert an unresolved issue into a claim that all checks passed.

Use the code review exercise to practice identifying the missing decision before examining a real change.