Reviewing AI-Generated Code

A starting question

An assistant changes a login form and says, “Done; tests pass.” Would you ship it without reading the change?

No. A test can pass while the wrong behavior is tested, a necessary edge case is missing, or an unrelated file has changed. Generated code is a proposed change, not a verified result. GitHub’s agent guidance explicitly warns that plausible code can be incorrect or insecure.The warning applies to the generated output, not just to one particular product.¹

Read the change, not just the summary

A diff shows added, removed, and modified lines. Read it file by file. First check scope: did the tool modify only the files needed for the task? Then trace the affected path from input to output. Look for changed error handling, data validation, permissions, dependencies, and configuration—not only the visible UI.

This is the same basic discipline used in a pull request. GitHub’s pull-request documentation separates the diff, discussion, and automated checks because they answer different questions.A green check reports what ran; it does not replace reading the proposal.²

Check assumptions and edges

For the login form, ask: What happens with an empty password? A wrong password? An expired session? A failed network request? Does an error message reveal more than it should? Does the change use an existing authentication function, or invent a second one?

You do not need to predict every possible bug. Identify the input, failure, and permission boundaries most likely to matter. OWASP’s review guidance highlights security-sensitive areas such as secret handling and error behavior.Security review has its own depth; this lesson gives a first-pass habit.³

Run checks and observe behavior

Run the project’s relevant tests and build checks. Then reproduce the original problem and try the edge cases you identified. If a test fails, investigate; do not ask the same assistant to dismiss it as “unrelated” without evidence. If no test covers the change, add one that would fail for the original bug and pass for the intended fix.

A small change is easier to review than a broad rewrite. If the assistant changed too much, narrow the task or separate the work before merging it.

Recap and try it

The review is complete when you can describe the change, its assumptions, its important failure paths, and the evidence you checked. The assistant’s confidence is not part of that evidence.