Review AI-generated code against the behavior the change is meant to preserve

The documented foundation

GitHub's guide to reviewing AI-generated code recommends functional checks, examination of project context, dependency scrutiny, and human review. It specifically calls out nonexistent APIs, ignored constraints, and tests that are removed or skipped instead of repaired.

Ceron's guide to auditing AI-built applications calls for checking authentication, database permissions, exposed secrets, and deployment configuration before launch. It distinguishes functional testing from adversarial testing. These points support a practical principle: assess the proposed behavior and its evidence, rather than treating the method of generation as a quality guarantee.

Source: GitHub: Review AI-generated code · Ceron: Vibe Coding Security: What to Audit Before Deploying an AI-Built Application

Start with an observable contract

Before reading every changed line, write a short description of what should happen for a concrete input and what must remain unchanged. That description gives the reviewer a reference independent of the implementation. It can be especially useful when a patch looks polished enough to make its assumptions difficult to notice.

Consider a hypothetical change that lets a user retry an interrupted export. The intended behavior might include producing one complete file, preserving the selected records, and avoiding a duplicate charge. A patch could implement the retry button correctly while failing one of those conditions. The review should therefore follow the entire operation, including the state that persists between attempts, rather than stopping at the new interface.

Analysis: Tests are evidence about selected cases

A passing test establishes something about the case it exercises under the conditions in which it ran. It does not automatically show that the case captures the requirement. A test written from the implementation's assumptions could repeat the same misunderstanding in a second form.

For the export example, a reviewer could derive cases from the contract: interruption before completion, repeated retry, a changed selection, and an unavailable destination. The purpose would be to distinguish correct behavior from plausible alternatives. If the existing test suite changes, inspect those changes directly. Removing a failing assertion can make a report look better without explaining whether the underlying behavior improved. GitHub's guide explicitly identifies this kind of test change as a review concern.

Source: GitHub: Review AI-generated code

Follow the new obligations

A dependency, configuration setting, background task, or permission can create work beyond the visible feature. An effective review identifies those obligations and checks who will own them. This is a proposed review method, not a claim that generated code necessarily introduces more obligations than human-written code.

Suppose the illustrative export patch adds a package to handle retries. The reviewer would want to understand why it is needed, whether the referenced API exists in the selected version, and how the project will maintain the integration. Those questions connect the immediate patch to future operation. They also create a useful opportunity to simplify the design if the new mechanism solves a broader problem than the requested change requires.

Use another reviewer to challenge assumptions

A second pass is most useful when it has a specific question. Asking whether the patch looks good can invite a broad impression. Asking how duplicate work is prevented after interruption directs attention to a concrete property. An AI assistant can help generate questions or trace paths, while the resulting claims still need inspection.

A review record should connect a concern to evidence: the relevant behavior, the path examined, and the check that supports the conclusion. If a question depends on business rules or operational knowledge, assign it to someone who can resolve that uncertainty. Additional confident prose does not replace missing context. Ceron's audit guide makes the same distinction concrete: checking that a feature works does not establish that its security boundaries hold under adversarial testing.

Source: Ceron: Vibe Coding Security: What to Audit Before Deploying an AI-Built Application

Finish with a bounded account of confidence

A concise completion note can state the intended behavior, the checks performed, and any material case left unresolved. It should distinguish an executed check from a suggested one. That makes the result useful to the next reviewer and to someone investigating the change later.

The process need not become a large checklist for every small edit. Its depth should follow the behavior at risk and the cost of an unnoticed mistake. The essential discipline is to preserve the link between the request, the change, and evidence that the change satisfies it. AI-generated code can then be reviewed as a concrete engineering proposal, with useful assistance where available and explicit judgment where the evidence runs out.