A Pre-Merge Checklist for Agent-Generated Code

Start with the file list, not the code. SpecStory's checklist for AI code recommends listing changed files with git diff --name-only --no-renames origin/main...HEAD and treating every file the task never named as out of scope until someone supplies a reason SpecStory's AI code review checklist. The same page reports that OWASP's secure coding with AI cheat sheet calls missing these edits the most common review failure mode in agentic coding.

Git's documentation confirms the flags: --name-only prints only the changed paths and --no-renames stops rename detection from hiding a delete-plus-add pair as a single rename the git-diff manual. That matters because a rename entry can conceal a file that was replaced rather than moved.

A worked example. A ticket asks for editable delivery addresses in checkout, and the diff touches 11 files. Nine map to the address form, its validation and its tests. One changes a session helper the ticket never mentions, and one edits a lint configuration. Both are out of scope until the author explains them; the lint edit is also a quality gate change, which stage 2 covers.

Two more diff-level checks before you read logic:

The size row is not cosmetic. Human defect detection falls toward zero past roughly 400 lines reviewed at once, according to the SmartBear and Cisco study cited in Augment Code's review guide Augment's guide to reviewing AI code. If the file list is too long to check, ask for a split rather than skimming. A split costs one round trip; a skipped review costs an incident.

Also resist the description. The pull request body is text the agent wrote, often a summary of what it believes it did. Compare the change against the original request, written as checks, and find each one in the diff.

Read tests before application code, because tests are where an agent can most cheaply manufacture a green run. SpecStory's checklist puts deleted, skipped and weakened tests first in its test group, and it flags edits outside the test files too: a disable comment, a loosened lint rule or a changed CI file all weaken gates without touching an assertion SpecStory's AI code review checklist.

Metacto's ten-check standard treats gate weakening as a standard in its own right: the pull request must not skip tests, loosen lint rules, lower coverage, bypass hooks, force commands to succeed or silence security checks Metacto's review standards. Google's "what to look for" page asks the same question in gentler form: will the tests actually fail when the code is broken Google's review guide on tests.

The decision rule that makes this fast: for each added or changed test, name the smallest code change that would make it fail. If you cannot name one, the test asserts that the code ran, not that it behaves. expect(items).toBeDefined() survives a cart that empties itself. expect(items).toHaveLength(2) does not.

Run the mutation check once, by hand, on the test that matters most:

# 1. Break the behavior the new test claims to cover
#    (edit the address update to drop the cart's items)
# 2. Run only the new test file
npx jest cart.test.ts
# 3. Expect a failure. If it passes, the test is not testing the behavior.
# 4. Restore the file and confirm green.
git checkout -- src/cart.ts

Two failure shapes to look for in the test diff. The first is assertion drift, where a precise matcher became a loose one between commits. The second is bloat: a batch of near-identical tests that adds review time without new coverage, which SpecStory describes as adding time without catching more bugs SpecStory's AI code review checklist. Bloat is not a blocker, but it is a reason to ask for one test that names the behavior over six that repeat it.

Finally, check where the tests run. A test that passes locally but never executes in CI is documentation, not a gate.

Dependency review moved earlier for generated code, because a model can write an import for a package that does not exist, and an attacker can register that name. Metacto calls the pattern slopsquatting and recommends verifying each new package on the canonical registry, confirming it is needed, and pinning it through the lock file Metacto's review standards. Endor Labs lists hallucinated dependencies among the common vulnerabilities in AI-generated code Endor Labs' vulnerability roundup.

GitHub's dependency review does part of this automatically. It shows which dependencies were added, removed or updated along with release dates, how many projects use a component, and vulnerability data, and the dependency review action fails a check by default when it finds a vulnerable package GitHub's dependency review docs. That handles the known-bad case. It does not answer whether the package should exist in your project at all, so the reviewer still owes a judgment call.

Work the four questions in order for each added package:

The install-script row deserves emphasis, because it executes on every developer laptop and in CI before any reviewer reads the code. A package whose only function is one utility call rarely needs a build step.

For Python, Redfox's guide on building a secure review agent shows the hash-pinned pattern in practice: compile a lock file with hashes and install with --require-hashes, so a swapped artifact fails instead of installing Redfox's secure review agent guide. The same logic applies in any ecosystem: the lock file is the artifact you review, not the manifest alone.

One ordering note. Do dependency checks before running the branch locally. A package with an install script has already run by the time you finish reading the diff on your machine.

The commit message is the one piece of context that travels with the change into history, and it is the piece an agent is most likely to fill with a transcript. A pasted log of tool calls tells a future reader what the agent did, not why the change exists or what could break.

The standard to hold: the message states intent (what behavior changes), risk (what could break and who is affected), and the verification performed. James Croft's pull request guide makes the same argument for descriptions: tell the reviewer what changed and why, explain the reasoning behind the approach, and describe how it was tested Croft's pull request guide. Google's change author materials carry the same thread, and the engineering practices repository notes that when a future reader tries to understand a change, the reason why is often the most important and hardest part to find Google's engineering practices repository.

A message that passes looks like this:

Allow address edits during checkout without losing cart items

Intent: customers can change delivery address on the review step and
return to the same cart state.

Risk: touches session serialization for the checkout flow. Guest carts
and multi-address orders are the exposed paths.

Verified: cart.test.ts and address.test.ts pass; manual run of the
guest-cart path after the last edit.

A message that fails states "Updated files per request" or pastes the agent's step list. Both force the next reader to reconstruct intent from the diff, which is exactly the work review was supposed to save.

Reject the commit and ask for a rewrite rather than fixing it yourself. The author owns the change, and making them articulate risk is the cheapest way to find out whether they understood it; Google's guidance is explicit that reviewers should not take on fixing the change for the author BSSw's summary of Google review guidance.

A checklist that lives in a wiki gets skipped. Put it where reviewers already work: the pull request template. SpecStory notes that a team can save the list as pull_request_template.md at the repository root, in docs/, or in .github/, and once the file is on the default branch its text fills the body of pull requests opened in the browser (though not ones opened through the API) SpecStory's AI code review checklist. The VisIt project uses the same mechanism and adds a convention worth copying: strike out items that do not apply instead of leaving them blank, so a reader can tell unchecked from inapplicable the VisIt pull request review guide.

Then decide what blocks and what informs. Not every check deserves equal weight, and treating them as equal is how review becomes a bottleneck.

Wire the automatable rows into continuous integration so the reviewer spends attention on the judgment rows. GitHub's dependency review action already fails on vulnerable additions when the branch requires the check to pass GitHub's dependency review docs. Add a step that fails on skipped tests and one that prints install scripts found in newly added packages.

Record the outcome. Leave a short comment on the pull request naming which stages you ran and what you found, so the second reviewer does not repeat the pass. The VisIt guide's point about review states applies here: "Comment" without approval leaves the author unsure whether changes are required, so use approve or request changes explicitly the VisIt guide.

Keep a named owner for every agent change. Metacto's standard assigns an owner to each check and requires explicit human sign-off for authentication, payments, infrastructure, migrations, public APIs and personal data Metacto's review standards. An AI reviewer can pre-screen that list, but it is not an approval authority on those paths.

Two process rules keep the gate honest. First, do not let a large agent pull request wait in the queue hoping someone reads it closely; ask for a split early. Second, do not lower the standard to keep velocity, a rule Google's guidance states plainly BSSw's summary. The gate is the thing that converts agent throughput into durable code health.

Where teams want the same ordered pass applied consistently across many repositories, the work is part review discipline and part tooling. Quanta Intelligence's experts read your context and hand back finished deliverables, which suits teams that want this gate encoded once rather than re-argued per repository: Quanta Experts.