AI Wrote 500 Lines of Code. Now What?

Resist reviewing it top to bottom

A 500-line diff invites the same mistake whether a human or an AI wrote it: reading start to finish at a uniform pace, which means the riskiest section gets the same shallow attention as a trivial one. Triage first by skimming the file list, and identify which files carry real logic versus which are boilerplate, generated config, or tests.

Read the highest-risk files closely first, while your attention is freshest, and save the mechanical or repetitive parts for last, where a faster skim is genuinely sufficient rather than a compromise.

Verify before you read every line

Before doing a careful manual review, run the automated checks that exist precisely to catch this class of problem: the full test suite, type checking, linting, and if available a build in a clean environment. A large diff that fails any of these needs fixing before line-by-line review is worth your time.

If the change touches an area with weak test coverage, that is a signal to write a few targeted tests yourself before trusting the diff, rather than reviewing code whose behavior you cannot actually verify.

• Triage files by risk before reading anything closely
• Run tests, types, and linting before manual review
• Read high-risk logic first while attention is fresh
• Write missing tests for weakly covered areas before approving

Deciding what to do with it

Not every large diff deserves an all-or-nothing decision. It is reasonable to accept the mechanical parts, ask for targeted revisions on a specific risky section, and reject or rewrite a piece entirely if it took an approach you do not want in the codebase.

If more than a third of the diff needs significant rework, it is often faster to re-scope the original task into smaller pieces and regenerate than to keep patching a large change that started from a flawed premise.