Review AI-written code
like the change matters.

Check what the change was meant to accomplish.

Before reading every line, restate the expected behavior. Compare the change with the issue, acceptance criteria, or design decision that authorized it. Ask what changed, what did not need to change, and whether the diff includes unrelated rewrites.

Generated code can look coherent while solving a neighboring problem. Make sure the implementation handles the actual inputs and constraints, and that it does not silently remove behavior the project already relies on.

Inspect the paths where a small mistake has a large effect.

Make sure you can explain the behavior that will run. An AI explanation can help you ask better questions, but check the answer against the code and its callers.

Use checks that can catch the failure you care about.

Run the project’s relevant tests and add cases for the changed behavior, including a boundary or failure case. Then use the checks the project relies on: type checking, linting, static analysis, dependency scanning, or a manual workflow check. A green suite is evidence about the cases it covers, not proof that every behavior is correct.

For security-sensitive code, pay closer attention to data flow, authentication and authorization, input handling, and new dependencies. Keep automated security tools as one part of the review; they do not replace understanding the design or the consequences of a flaw. Continue with the security evidence and checklist for AI-generated code ↗.

GitHub’s own guidance asks users to understand and review suggested code, and to use tests and tools such as linting and code scanning to validate it. NIST’s Secure Software Development Framework gives software teams a broader set of practices for integrating security into the development lifecycle.

Small scope makes mistakes easier to see.

Ask for a focused patch and separate unrelated cleanup from behavior changes. Review file names, generated files, configuration, and dependency manifests, not just the central function. If the patch is too large to understand, narrow it or divide it into reviewable steps.

Code review should improve the project, not reward confidence or volume. GitHub’s responsible-use guidance likewise warns that generated code may be incomplete, incorrect, or insecure, and recommends careful review and testing—especially for sensitive work.

Leave a clear answer to each of these questions.

• Does the change satisfy the requested behavior without expanding its scope?
• Can I explain the changed code and the important assumptions it makes?
• Are input boundaries, permissions, secrets, and error paths handled safely?
• Do tests cover the new behavior and a meaningful edge or failure case?
• Did relevant project checks pass, and do I understand what they did not check?
• Are new dependencies, generated files, configuration, and licensing implications understood?
• Could another person review the patch and reproduce the important checks?

Record the checks you ran and any remaining limitations. Then review the final diff once more; the version you merge should be the version you inspected.

Build review into the engineering loop.

For the step between an AI-built demo and software people can rely on, read how to move from vibe coding to a maintainable product ↗. For the longer view across changing requirements, see how to check whether AI-written code stays maintainable ↗. For a wider look at repository context and agent actions, read why agents need evidence ↗.