In this article

Review AI-generated code by reading the complete diff, checking its trust boundaries and testing the behavior independently. A passing test run is useful evidence, but it cannot prove that the tests cover the requirement—or that the change did not weaken them.

This is a review method, not a claim that we benchmarked any coding assistant. GitHub's responsible-use guidance explicitly recommends reviewing and testing generated code, especially in sensitive applications.

Write the acceptance condition first#

State what must happen in language that does not depend on the implementation.

For a shopping application: “A signed-in customer can view only their own orders.” That is more useful than “The order endpoint returns 200.” The latter can pass even when the endpoint leaks another customer's order.

Identify what should remain unchanged, such as authentication, supported formats and error responses. Use this small contract to judge the diff rather than letting the generated implementation define success.

Read the entire change#

Review application code, configuration, dependency files and tests. Look for changes outside the requested scope.

Pay particular attention to:

  • Deleted assertions or skipped tests.
  • Catch blocks that turn failures into empty successes.
  • New permissions or broadly shared resources.
  • Dependency additions for trivial functionality.
  • Configuration changes that disable validation.

An assistant's summary is a useful introduction. It is not a substitute for inspecting the changed files.

Trace authorization and data boundaries#

Take one concrete request and follow it from input to output. Where does the code decide who is allowed to act? Which identifier does it trust? Where is the database query constrained?

In the order example, a query by order ID alone is insufficient if the application requires customer isolation. The authenticated customer's identity must participate in the authorization decision. Guessing another order ID should not grant access.

Also check whether secrets, tokens or personal data can enter logs, URLs or client responses. Review the error path, not just the successful path.

Verify dependencies and APIs#

Confirm that a proposed package exists in the expected registry and that its official documentation supports the API being used. Check compatibility with the project's installed version.

For a small change, ask whether the dependency earns its maintenance cost. If the answer is unclear, prefer the project's existing capabilities rather than adding a library because an assistant suggested it.

For factual claims in comments or implementation notes, use the AI answer verification workflow.

Test a counterexample#

Run checks that could disprove the acceptance condition:

  1. A second customer requests the first customer's order.
  2. The request has a malformed identifier.
  3. The database operation fails.
  4. A repeated request arrives.
  5. An optional value is missing.

Choose cases relevant to the change rather than mechanically adding every edge case. Inspect what the tests assert. A mock that always returns the expected result may test little about real behavior.

Keep a short review record#

Record the requirement, the checks you performed, their actual results and the limits of verification. “Unit tests passed; external payment sandbox not exercised” is more informative than “Fully tested.”

The 2025 Stack Overflow AI survey records developer concerns about accuracy and privacy. That audience signal motivates careful review; it does not establish that a particular assistant or generated change is unsafe.

Decide whether to ship#

Ship when you understand the change, the relevant checks pass and remaining uncertainty fits the risk. Ask for another review when you cannot confidently explain a critical boundary. Reduce the change if it is too broad to assess.

For mobile releases, a successful review is only one stage. The CascadeCI introduction explains how build execution, upload and store availability differ.