reviewing-ai-generated-code

Reviewing AI-generated code: fluent is not correct

Model-written code reads well, which is exactly the risk: it is optimized for plausibility, and a reviewer's guard drops when the code is clean and confident. The security failures cluster in predictable places, dependencies that may not exist or may be attacker-registered, defaults copied from insecure examples, validation quietly omitted, and logic that looks right but is not. Reviewing it means aiming at those clusters, not skimming for style.

When to use

• You are reviewing an AI-authored change, an assistant's suggestion, or a large generated diff.
• Generated infrastructure, config, or access-control code is entering the codebase.
• You are setting a review bar for machine-assisted contributions.

Scope check

Review code for projects you own or contribute to with authorization. If you can't name the authorization, stop.

The loop

1. Verify every dependency the code introduces. For each package the change adds, confirm it exists, is the established package (not a lookalike or a name the model may have invented), and is the one you intend. A hallucinated package name an attacker later registers turns "the model suggested it" into installed attacker code. Do not let a plausible import in unverified.

2. Check the defaults and the omissions. Generated code tends to reproduce the most common pattern, which is often the insecure-by-default one: permissive cross-origin rules, disabled verification, a broad permission, a missing auth check, a hardcoded or example secret, an unparameterized query. Read for what should be there and is not, not only for what is.

3. Test the claim against the behavior. Model code often states an intent in a comment or a name the code does not fulfill: a function named validate that does not reject, a check that is computed and then ignored, error handling that swallows and continues. Confirm the security-relevant logic actually does what its surface promises.