Review AI-Generated Code Before It Reaches Production

AI-generated code deserves the same engineering standard as any other change, but it benefits from a different review order. Start with the behavior you must preserve, then inspect the diff for assumptions the prompt did not state.

Write the contract before reading implementation details

State the input, output, failure behavior, authorization boundary, and non-goals in a few sentences. This makes it possible to identify a plausible-looking implementation that solved the wrong problem.

Review the diff, not just the generated explanation

Read every changed file. Watch for unrelated refactors, new dependencies, broadened permissions, changed defaults, hidden network calls, and error handling that converts a failure into a misleading success. Generated summaries are useful navigation aids, not evidence.

Test the negative path deliberately

npm run format:check
npm run typecheck
npm test
npm run build

Add or run a test for invalid input, a downstream failure, an unauthorized caller, and an empty or partial result where relevant. A happy-path test mainly proves that one example happened to work.

Treat sensitive boundaries as mandatory human review

Authentication, authorization, payments, secrets, destructive operations, migrations, and external side effects need an owner who understands the system’s threat model. Do not let an AI tool’s confidence substitute for a permission or data-flow review.

Keep the change small and attributable

Prefer a narrow pull request with a clear expected outcome. Record the commands run and the manual scenario checked. If the code needs a larger refactor, split it so a reviewer can validate the behavioral change separately from cleanup.

The goal is not to distrust AI assistance. It is to keep responsibility with the team that deploys the code: define the contract, inspect the real diff, exercise failures, and require human judgment at sensitive boundaries.