Code Review Checklist for AI-Generated Code

Run the examples yourself

The download includes the before, intentionally buggy and fixed JavaScript versions, their tests, a local verification script and recorded results. The CI workflow is a template; it has not been run in hosted CI.

Download verification examples (ZIP)

Choices stay in this page's memory only.

1. Requirements and scope

Establish the target before discussing implementation quality. A reviewer who sees only an agent’s summary can miss a requirement that the summary omitted. Identify the affected behavior, the consumers that depend on it and the constraints that must remain true. Use a short written acceptance statement rather than a general instruction to “make it work.”

Write the expected outcome independently of the proposed implementation. Include a concrete example with meaningful units, such as 3,800 cents for two nineteen-dollar items, so a plausible-looking calculation can be checked against an external expectation.Identify the exact revision, base revision and files being reviewed. Confirm whether new, generated or untracked files belong in scope; an omitted file cannot be assumed reviewed because the rest of the change looks complete.Follow changed interfaces into their consumers, including callers outside the diff. Check units, nullability, error behavior and serialization contracts instead of assuming an unchanged file remains compatible with a changed producer.List meaningful exclusions and unresolved assumptions. Record unavailable services, missing configuration and code you could not inspect; do not turn a limited review into a claim that the whole repository has been audited.

2. Inputs, state and failure handling

Treat normal inputs as only one part of the contract. Review how state changes across retries, exceptions and concurrent requests. A useful finding describes a triggering condition and an observable consequence, which makes it possible to confirm the problem or reject the claim.

Test empty, missing, malformed and boundary inputs that matter to this change. Check the actual failure path and returned error, rather than merely noting that validation exists somewhere else in the project.Check numeric units, rounding, range and precision at each boundary. A value called price can mean dollars, cents or a formatted string; an implicit unit migration can pass syntax checks while changing a business result.Inspect partial success, cleanup and cancellation. Determine what has already changed when an operation fails and whether the response could encourage a caller to repeat an effect that has already happened.Examine retries and concurrent calls for duplicate side effects or stale state. Use an explicit idempotency expectation where needed, and distinguish an in-memory demonstration from guarantees requiring a database or external service.

3. APIs, dependencies and configuration

Read the documentation and configuration that correspond to the deployed version. Correct syntax does not establish that a package exists, an API has the assumed signature or an integration is enabled. Avoid accepting a newly added dependency solely because the coding assistant names it confidently.

Confirm each newly used third-party API in the relevant version’s official documentation. Check required arguments, return values and error behavior, then verify that the code uses the supported interface.Review added or upgraded dependencies, lockfile changes and installation scripts. Distinguish a known-vulnerability check from permission to use the dependency or evidence that its business behavior matches your needs.Inspect environment variables, feature flags and default values. Verify that a missing setting does not silently disable a required check, enable a dangerous fallback or change the meaning of the result.Check licenses and data destinations before adopting a new service or copied rule set. Self-hosting an application does not by itself establish that model inference, logs or other processing stays within your chosen boundary.

4. Authorization and sensitive data

Locate the enforcement point rather than relying on a button being hidden. Use the application’s actual identity and ownership model when designing negative tests. Keep production secrets out of demonstrations and verify that diagnostic output does not expose the values being inspected.

Confirm that the server or authoritative component validates ownership and permission on every relevant operation. A client-supplied owner identifier or an unpredictable record ID is not a substitute for checking the caller’s rights.Exercise a meaningful unauthorized case, such as one tenant requesting another tenant’s record. Confirm the result at the boundary that enforces access, not only in a helper tested with already-filtered data.Trace secrets and sensitive fields into logs, error messages, analytics and external requests. Check both success and failure paths; redaction in one logger does not establish that every copy is protected.Review changes affecting authentication, billing, destructive migrations or verification policy with the appropriate human owner. Match review effort to potential consequences instead of assuming machine-generated changes all have the same risk.

5. Tests and review integrity

The test suite is evidence only for the assertions it contains and the cases it actually executes. Protect those assertions from being adjusted merely to agree with a new implementation. A failure can expose a bug, an incorrect expectation or an incomplete test environment; investigate the cause.

Add a regression that fails on the defective revision and passes after the intended repair. Keep the expected value tied to the requirement, and save enough context to reproduce both outcomes.Check that new tests challenge behavior rather than restate the implementation. Include relevant negative or boundary cases and ask which incorrect implementation would still pass the current assertions.Inspect deleted tests, weakened assertions, updated snapshots and suppressed diagnostics separately. Require a behavioral reason for each change; accepting a new baseline is itself a review decision.Validate reviewer findings before applying their fixes. Request file and line, trigger, consequence and evidence; mark unsupported hypotheses as unconfirmed and preserve legitimate negative controls that refute a suspected problem.

6. Delivery and the acceptance record

Close the review with a specific decision. A passed local test is not evidence that a hosted workflow ran or that repository protection is enabled. Identify the tested revision, the artifact to be delivered and any remaining exception that an owner has explicitly accepted.

Confirm every mandatory check completed successfully on the relevant revision. Treat missing, skipped, cancelled, timed-out or invalid analysis as unavailable evidence according to your policy, not as a finding-free report.Check that failures actually block the intended merge or release path. Review workflow triggers, required check names and bypass settings; producing a report and enforcing a gate are separate tasks.Rerun the original checks after the fix and reject stale review output after a new push. Preserve the connection between the changed code, its test results and the exact build that will be deployed.Record unresolved issues, scope exclusions and the approving owner. Do not label the change universally safe or correct; state which requirement was checked, with which method, under which conditions.

A short walkthrough: the price-unit migration

Our original demonstration changes a catalog from dollars to cents while leaving its invoice consumer unchanged. The amount test expects 3,800 cents but the buggy version returns 380,000. That confirms a producer-consumer contract failure. The separate claim that negative quantities are accepted is incorrect: the function rejects them and the negative test passes.

Use the checklist to separate those conclusions. The interface item exposes the unit mismatch, the regression item demonstrates its effect, and the review-integrity item rejects the unsupported quantity claim. Four passing tests after the repair cover those four cases; they do not cover taxes, currencies or real payment processing.

How to use this with AI Code Verify

Paste a supported snippet into the browser checker for its displayed fixed checks. Source analysis stays in your browser; the checker does not upload code, call an LLM or examine related files. Continue the checklist in your own project for consumer behavior, full type checking, dependencies, executed tests and authorization boundaries.

Keep an item unchecked when its evidence is missing. If you need a deeper method, use the main verification framework or CI guide. Printing the list can help a human review, but completing every checkbox is a record of your review process rather than a certification.

Where this site's tool fits

Our single-snippet static checker runs local fixed rules. It does not connect a repository, execute your tests, perform cross-file analysis or prove a program correct. Use it as one layer of the workflow.

Sources and editorial notes

Product capabilities can change. Links below are primary references used for this guide; examples are demonstrations unless explicitly stated otherwise. Suggest a correction.