# How to Review AI-Generated Code Safely

> Use a contract-first review loop to inspect AI-generated code, test risky boundaries, and decide whether a proposed change is ready to merge.

- Canonical HTML: [https://unrust.dev/use-cases/review-ai-generated-code](https://unrust.dev/use-cases/review-ai-generated-code)
- Markdown representation: [https://unrust.dev/use-cases/review-ai-generated-code/index.md](https://unrust.dev/use-cases/review-ai-generated-code/index.md)

Published: 2026-07-14

## Direct answer

Review AI-generated code as a proposal, not as proof. Restate the required behavior in your own words, inspect where the change crosses inputs, permissions, storage, or network boundaries, and run focused checks for the ordinary case and the riskiest edge. Polished naming and a confident explanation are not evidence that the code fits your application, dependencies, or team conventions.

## Start with behavior you can verify

Read the ticket, failing test, API contract, or product rule before you read the generated explanation. Put the expected input, output, failure behavior, and boundaries into a short statement, then compare every important branch in the diff against that statement.

## Spend review time at the edges

Generic code often looks most convincing in the middle of the happy path. Review validation, authorization, null handling, retries, persistence, and error reporting deliberately because those are the places where a plausible default can quietly become a production defect.

## Checklist

- Can I state the intended behavior without repeating the generated explanation?
- What happens with missing data, rejected access, retries, or an external failure?
- Does the diff follow the surrounding codebase's error and test conventions?

## Practice loop

1. Write the required behavior and two failure cases before opening a generated diff.
2. Mark every input, permission, storage, and network boundary in the proposed change.
3. Run or add the smallest focused test for the highest-risk boundary before merging.

## Limits of this page

This checklist improves evidence gathering, not certainty. A review still needs the local product context, dependency documentation, and a risk-appropriate test strategy; a short diagnostic session cannot establish why someone missed a review detail.

## Source context

Editorially reviewed for Unrust using public language documentation, common code-review practice, and small original examples written for this resource system.

## Related resources

- [How to Understand an AI-Generated Pull Request](https://unrust.dev/use-cases/understand-an-ai-generated-pull-request/index.md): Understand an AI-generated pull request by mapping the request to the diff, tracing its data flow, and isolating every assumption before approval.
- [Reviewing AI-Generated TypeScript Code](https://unrust.dev/languages/typescript/reviewing-ai-generated-code/index.md): Review AI-generated TypeScript by checking whether type assertions, inferred shapes, and runtime validation actually preserve the contract at every external boundary.

Next step: [Take the free diagnostic](https://unrust.dev/diagnostic/index.md)