Before merging any AI-generated change, run through ten checks in order: verify every new dependency actually exists, run the type checker, read what the tests actually assert rather than just confirming they pass, read the failure paths and not only the happy path, check boundary and edge cases directly, give anything touching authentication or user data a full line-by-line read, confirm every called function genuinely exists on its claimed API surface, watch for unnecessary complexity the assistant added beyond what was asked, scan for any secret or credential that should not be in the diff, and finally, run the feature yourself before trusting a green build. None of these ten takes long individually. Skipping several of them together is how a plausible-looking change reaches production with a real defect inside it.
This works as a checklist rather than a vague instruction to “review carefully” because AI-written code fails in a small number of recurring, predictable places, not randomly across a diff. Each check below targets one of those places specifically.
Why a checklist works here
A checklist is only useful when the failure modes it targets are consistent enough to name in advance. That is exactly the situation with AI-generated code: it does not fail evenly across every possible category of mistake. It clusters around a handful of specific patterns invented dependencies, invented API calls, unhandled edge cases, and tests that describe what the code does rather than what it was supposed to do. Naming those patterns in advance, as a fixed list, catches most of the risk without requiring a reviewer to somehow anticipate every possible failure from scratch on every single review.
The ten checks
1. Verify every new dependency actually exists and resolves. An assistant can suggest a package name that sounds plausible and simply does not exist, and installing it can run arbitrary code the moment it downloads. This is worth its own check every time a diff touches a manifest file. The full routine for this specific check, including what to do if the package is already installed, is covered separately.
2. Run the type checker or equivalent static analysis before reading a single line by eye. A type checker catches a large share of invented or mismatched function calls automatically, because it checks the call against the real declared API surface rather than the assistant’s memory of it. This is the single cheapest, highest-leverage check on the whole list.
3. Read what the tests actually assert, not just that they pass. AI-generated tests often mirror the implementation closely enough to pass trivially without genuinely verifying behavior. A passing test suite that was written by the same process that wrote the code is weaker evidence than a passing test suite written independently against the original requirement.
4. Read the error-handling and failure paths, not just the happy path. AI-generated code tends to handle the success case correctly and leave error handling vague, missing, or copied from a different context. The happy path being correct tells you almost nothing about whether the failure path is.
5. Check boundary and edge cases explicitly: empty input, missing data, timeouts, retries, duplicate requests, concurrent updates, partial failures. These are exactly the cases a model is least likely to have generated a genuinely correct response for, because they require reasoning about the specific system’s failure behavior rather than pattern-matching a common solution shape.
6. Give anything touching authentication, payment, or user data a full, line-by-line read, with no exceptions. The reasonable default for most code is proportional review effort. Sensitive-path code does not get that default; a threat-model-first approach identify the sensitive paths, verify authorization boundaries, check secrets and dependency provenance, test the failure modes, and require a specific human sign-off is the appropriate level of scrutiny here, not an abbreviated version of it.
7. Confirm every called function or method genuinely exists on its claimed API surface. This is one level deeper than check 1: the import can be completely legitimate while a specific method call on it is invented or has the wrong signature. This is harder to catch on sight because nothing about the import line looks wrong; the fast routine for confirming a specific call is real is covered in its own dedicated piece.
8. Watch for complexity the assistant added beyond what was actually asked for. AI-generated code often becomes bloated not because anything is broken, but because the model is too eager to generalize a narrow request into a broader, more “flexible” implementation. Extra abstraction that nobody asked for is extra surface area for the first seven checks to miss something.
9. Scan the diff specifically for secrets or credentials that should not be there. A large context window or a “give it the whole repo” workflow makes it easy for an API key or a credential to end up somewhere it should not, without anyone deciding that should happen. This is a fast, mechanical check and worth running even when nothing else about the diff looks concerning.
10. Run the feature yourself before merging. A green build and a passing test suite are necessary, not sufficient. Actually exercising the changed behavior, even briefly, catches the category of problem that automated checks are structurally unable to see: the code that runs, passes every test, and is still wrong in a way nobody wrote a test for.
What this checklist does not replace
This list is the fast, ordered pass for a typical AI-generated change. Two situations need more than a checklist item can cover in one line, and each has its own dedicated method: a pull request too large to read start to finish in one sitting needs a different review structure entirely, not just more time on this same list; and a suspected hallucinated package or invented function, once check 1 or check 7 flags something, needs the specific verification routine covered in its own piece rather than a guess based on how the assistant explained its own choice. All of this sits inside the broader working discipline in working with an AI coding assistant.
FAQ
Do I need to run all ten checks on every single AI-generated change?
Proportionally, yes, but “proportionally” matters: a five-line change to a low-risk internal utility does not need the same time investment as a change touching authentication. The checks scale in depth, not in whether they apply at all.
Which single check catches the most problems if I only have time for a few?
Running the type checker (check 2) and reading the actual test assertions (check 3) together catch a large share of both invented-API problems and logic problems for the least time invested. Neither replaces the others, but they are the highest-leverage pair.
Does a checklist like this slow down development compared to just merging AI suggestions directly?
Reviewing responsibly always costs some time compared to not reviewing at all. The alternative to spending that time up front is spending more of it later, debugging a defect that shipped because a specific, predictable failure mode was not checked for.
Is this checklist different for GitHub Copilot versus Cursor versus Claude Code?
No. The ten checks target failure patterns that come from how current AI coding assistants generate code in general, not from any one product’s specific implementation. The same list applies regardless of which tool produced the change.
What if the AI-generated change is small, like a five-line fix?
Smaller changes still deserve checks 1, 2, and 7 at minimum, since a hallucinated dependency or an invented function call can appear in five lines just as easily as in five hundred. The depth of checks 3 through 6 can scale down with the size and risk of the change.
