How to Review AI-Generated Code Before Accepting It

How to Review AI-Generated Code Before Accepting It

Accept AI-generated code only when a qualified reviewer can connect the requested intent to the entire diff, verify the behavior and failure paths, understand every trust change, and preserve a recoverable repository state.

The generator does not change the acceptance standard. It does create a few recurring review hazards: plausible invented interfaces, silent scope expansion, unnecessary dependencies, weakened tests, unsafe defaults, and explanations that sound more certain than the code deserves.

flowchart LR
    A["Restate intent"] --> B["Inspect repository state and whole diff"]
    B --> C["Trace interfaces and data"]
    C --> D["Run tests and add failure cases"]
    D --> E["Review security, dependencies, and operations"]
    E --> F["Confirm provenance and rollback"]
    F --> G["Named maintainer accepts understood subset"]

Restate the intended change

Begin with the requirement, not the generated summary.

Write the expected behavior, exclusions, affected users, known failure cases, and acceptance evidence. Then map each changed file to that intent.

If a change cannot be explained by the requirement, treat it as out of scope until someone justifies it. A helpful refactor, dependency upgrade, configuration cleanup, or formatting sweep can hide the behavior that actually needs review.

Confirm the repository state

Record the repository root, branch, starting commit, working-tree status, and tool versions. Make sure you are reviewing the intended worktree.

The duplicate-path mistake in [[What Building a Go App With Cursor in Four Hours Actually Proved]] shows why this comes first. A correct-looking diff against the wrong copy is not the intended change.

Read the full diff from the durable version-control system. Product review surfaces can be convenient, but Pro Git provides the stable concepts for repository history and comparison.

Inspect new files, deleted files, generated files, lockfiles, migrations, configuration, tests, and documentation. Do not limit the review to the most visually interesting code.

Trace every interface and data path

Resolve every function, type, endpoint, schema, event, environment variable, configuration key, and external service the change touches.

AI-generated code can call an interface that exists in another version, invent a parameter, assume a nullable value is present, or copy a pattern from the wrong module. Type checking helps, but runtime and semantic contracts can still be wrong.

Trace input from its source through validation, transformation, storage, logging, output, and deletion. Identify trust boundaries and authorization decisions.

If the change processes personal, regulated, confidential, authentication, payment, or security data, stop a general review and involve the responsible domain owners.

Review tests as code

Run the tests that passed before the change. Then run the focused tests for the new behavior.

Read every generated test. Confirm that it calls the real behavior, asserts the intended outcome, and would fail if the implementation were removed or broken. Watch for tests that mock away the important boundary, assert only a status code, swallow an exception, or rewrite expected values to match the implementation.

Add failure cases the generator omitted. Useful areas include empty input, malformed data, unauthorized access, missing dependencies, timeouts, retries, concurrency, partial writes, duplicate requests, and rollback.

Passing tests are evidence. They are not proof that the requirement, test selection, or environment was complete.

Inspect security and supply-chain changes

Review new dependencies, versions, install scripts, licenses, transitive risk, integrity records, and maintenance state. Ask whether the feature can use an existing dependency or standard library instead.

Review authentication, authorization, input handling, output encoding, secret access, file paths, network calls, command construction, logging, error messages, and default configuration.

NIST SP 800-218 recommends integrating secure development practices across the software lifecycle. The OWASP Code Review Guide describes manual security review as an important companion to automated analysis.

Those sources provide a foundation. They do not replace the project's threat model or current domain expertise.

Run the approved static analysis, dependency, secret, and policy checks. Treat tool findings as inputs for review, not automatic verdicts.

Check operations and failure recovery

A code change can pass unit tests and still fail operationally.

Review logs, metrics, traces, alerts, timeouts, retries, resource limits, feature flags, deployment sequence, migration compatibility, and rollback. Confirm that sensitive data does not appear in logs or error messages.

If the change includes a database or data migration, a Git revert may not restore the earlier state. Preserve backup, compatibility, rollout, observation, and recovery steps.

For distributed artifacts, the SLSA 1.2 specification provides a useful source and build provenance model. A plausible source diff and a verifiable built artifact are different evidence objects.

Compare documentation with behavior

Generated documentation often sounds finished because prose is easy to produce.

Run every documented command. Follow each setup step from a clean environment when practical. Compare named files, flags, environment variables, endpoints, examples, and error behavior with the actual implementation.

Remove promises the code does not make. Mark current limitations and required permissions. Do not let an agent's confident summary become the source of truth for the code it generated.

Confirm maintainability and ownership

Ask the named maintainer to explain the approach, alternatives, failure behavior, data path, dependencies, and recovery plan.

Look for duplication, hidden coupling, premature abstraction, inconsistent conventions, and complexity that only the generator can navigate. The change should fit the codebase, not merely compile within it.

Cursor's current agent best-practices guide advises careful review and verifiable goals. The product may help locate issues or run another review pass. The accountable maintainer still owns the acceptance decision.

Record the decision

Accept only the subset the reviewer understands. Split mixed changes. Reject unexplained edits. Preserve the evidence with the repository or change record.

The goal is not to prove that AI code is uniquely dangerous or uniquely productive. It is to make sure generation speed never becomes permission to lower the engineering standard.

This guide was developed with AI assistance from the immutable E037 transcript, NIST SSDF, OWASP code-review material, SLSA, Git documentation, current Cursor first-party guidance, and the linked acceptance framework. Dalton Anderson remains the author. Technical, security, current-source, and founder review are mandatory before publication. Publication is not authorized.