AI-Generated Code Review and Acceptance Checklist: Verify the Result

To review AI-generated code, check the diff and then check the behavior: confirm every new dependency and API really exists, read the test changes before the code changes, prove at least one test fails without the fix, rerun the checks yourself on the final diff, and finish by using the feature from its normal entry point and reading back the saved result. The checklist below covers both halves and gives you a short evidence record to keep.

A working demo is one observation. Acceptance asks a narrower, more useful question: does this exact version satisfy the agreed task, under the conditions that matter, and can someone inspect the evidence?

Use this checklist for a small application feature, an API change, or a bug repair in an authorized environment. Start with the normal user entry point and finish at the durable result. You can use the checklist manually; the related Skills organize the work but are not required to fill it in.

Do this first

1. Freeze version, role, environment, and one observable acceptance criterion.
2. Four AI checks: real deps, test-diff first, prove a test can fail, rerun on final diff.
3. Normal entry → durable readback (not toast-only).
4. One evidence row: PASS/FAIL/BLOCKED/NOT RUN/N/A (reason); blank ≠ PASS.
5. Human decide: accept, reject, or pause—not an agent summary alone.

Synthetic (not production): toast “saved”, readback still “Old” → FAIL until persist+readback PASS.

Where this checklist fits

Suitable for independent developers reviewing bounded changes with an identifiable baseline, requirements, and access to the relevant runtime. Scale the checks to the affected behavior rather than the number of files.

It is not a penetration test, accessibility conformance assessment, regulated-system certification, or production load-test plan. Payment, identity, sensitive-data, destructive-migration, and safety-critical changes need additional domain-specific review. Do not use a checked box as a security or legal guarantee.

Code review or acceptance: which one does this change need?

Most AI-generated changes need both. Code review tells you whether the diff is safe and sensible; acceptance tells you whether the feature actually works for the user. Popular review guides, such as GitHub's guide to reviewing AI-generated code and Sentry's playbook for reviewing AI-generated code, focus on reading the diff. This page adds the second half.

Code review answers: is this diff correct, safe and in scope?

• Main input: the diff, the tests and the dependencies.
• Typical checks: invented APIs or packages, scope creep, authorization, secrets, test quality.
• Typical proof: review notes, scanner output, a CI log.
• Misses on its own: a flow that compiles but breaks after save.

Acceptance answers: does this exact version do the agreed task for a real user?

• Main input: the running app, a test account and the saved data.
• Typical checks: the normal entry point, persistence readback, failure and recovery paths.
• Typical proof: before/after evidence tied to a version.
• Misses on its own: a security hole the user never sees.

The rest of this checklist is written for independent developers and small teams shipping bounded changes written by Claude Code, Codex, Copilot or a similar agent.

1. Freeze the acceptance target

Record the baseline and candidate commit or artifact, environment, browser/runtime, roles, approved data source, and permitted side effects. Uncommitted edits need a diff snapshot or hash as well as the commit. Attach the requirement source and assign REQ/AC IDs before looking at test results.

For each requirement, write an observable outcome independent of the implementation. “The Save handler runs” is insufficient; “the authorized user sees the new value after reopening the record” describes a result. Mark missing rules as BLOCKED rather than inferring the desired behavior from generated code.

Use PASS, FAIL, BLOCKED, NOT RUN, or N/A. N/A requires a reason the check is outside this feature, never merely missing tools. A blank evidence field cannot support PASS. Record exceptions as explicit decisions with owner, scope, and follow-up; do not silently turn them into passes.

2. Run the applicable checks

• [ ] Requirements: Map every REQ/AC to an implementation entry point, case, and result. Include promised behavior absent from the diff; record agreed exclusions. Check that the change did not add a new business rule or permission.

• [ ] Core function and persistence: Start from the normal role-specific entry point. Complete the task and verify the result. For writes, refresh or reopen and read the authoritative state through permitted access; correlate the same object and request. A success toast alone is insufficient.

• [ ] Boundaries and state: Check omitted, empty, invalid, lower-bound and upper-bound inputs where applicable. Use the actual counting unit and business rule. Exercise legal and forbidden state transitions, repeated clicks, stale views, and competing updates when these can affect the result.

• [ ] Errors and recovery: In an authorized isolated environment, exercise relevant timeout, rejection, partial failure, and interruption paths. Check that users know what happened and can recover. Verify retries do not duplicate side effects and a late response cannot undo a newer action.

• [ ] Security basics: Check server-side authorization for the actual action and object, including a second test account with different ownership. Verify rejected requests do not change data. Inspect applicable input validation, output encoding, and credential exposure in bundles/logs. Run only authorized checks, never attacks against unrelated systems.

• [ ] Accessibility and interaction: Complete the affected flow using the keyboard; inspect focus, names/labels, errors, and dialog dismissal. Check zoom and narrow layouts, readable contrast, and meaningful text alternatives. Add assistive-technology checks appropriate to the product; these basic checks do not establish conformance.

• [ ] Performance: Agree the operation, data size, device/network conditions, measurement method, and threshold before testing. Measure the complete user operation, not just an API call. Compare with the baseline under the same conditions; retain samples and resources observed. If no threshold exists, report measurements and a pending decision.

• [ ] Regression and review: Run affected existing checks and repository-required lint/type/build/tests. Exercise shared callers and adjacent valid/invalid paths. Review the final diff for omitted requirements and weakened assertions. For a repair, preserve a signal that fails before the fix and passes after it.

• [ ] Evidence and delivery: Link every claim to the tested version, actual steps/command, expected result, observed result, and raw evidence. Label mocks, fixtures, synthetic data, and static review. Confirm that evidence still matches the final diff. Report local verification, deployment, and target-runtime acceptance separately.

Four AI-specific checks a normal review skips

These four checks target problems the review guides above call out for AI-written changes: invented dependencies, weakened tests, tests that cannot fail, and "tests pass" claims that were never run on the final diff.

1. Confirm every new dependency exists and is the one you meant. Look up each new package in the official registry and in the lockfile before installing it. In a USENIX Security 2025 study of 16 code-generating models selected in January 2024, 19.7% of about 2.23 million packages referenced in the generated Python and JavaScript code did not exist. The average was at least 5.2% for commercial models and 21.7% for open-source models. Newer models may do better, but a package name that does not exist today can be registered by an attacker tomorrow.

2. Read the test diff before the code diff. A deleted test, a new skip, a changed expected value or a mock that replaces the code under test is the agent deciding what "correct" means. GitHub's guide specifically warns about tests that are deleted or skipped instead of fixed. Confirm those decisions first; then read the implementation.

3. Prove at least one test can fail. Run the new or changed test against the version before the fix, or temporarily break the guarded line, and confirm it fails. If it still passes, it protects nothing. Mutation testing tools such as Stryker automate the same idea by inserting small bugs and checking that a test fails.

4. Rerun the checks yourself on the final diff. An agent's summary is not a test result. Record the command, the number of tests that ran, the exit code and the commit or diff it ran against. A result from before the last edit does not count.

How much checking does this change need?

Scale the checks to what the change touches, not to how many lines it has. The tiers below are our working judgement; the high-risk triggers follow OWASP's secure code review guidance on when to look deeper.

• Low: copy, styles, docs, or an isolated refactor with unchanged tests. Minimum: build, lint, existing tests, and one look at the result.
• Medium: a feature inside existing boundaries, UI state, or a new endpoint without new permissions. Minimum: the low tier, the four AI-specific checks above, and one acceptance case from the normal entry point with readback.
• High: authentication, authorization, payments, personal data, migrations, deletion, CI/CD or deploy configuration, or new dependencies. Minimum: the medium tier, every applicable checklist section, and a second, independent review before merge.

Reviewing alone: when there is no second reviewer

If you work alone, make the check independent of the agent that wrote the code, and write down what stayed unreviewed. Team guides assume a second person: OWASP asks for approval by someone other than the author. A solo developer cannot fully meet that, so get as close as you can:

• Use a fresh session or a different agent for review, give it only the requirement and the diff, and ask for findings backed by evidence rather than a verdict.
• Verify against the running system, not the agent's report: open the page, reopen the record, check the deployed version.
• Keep high-risk changes small enough that you can read every line.
• Record "no independent human review" as an open gap in the evidence record instead of silently skipping it.

3. Keep a small, inspectable evidence record

For each case record: CASE ID → REQ/AC → role and data source → exact steps → expected result → actual result → status → pass/fail evidence → environment/version → remaining gap and owner.

Screenshots show visible state; they do not prove persistence. A 200 response does not prove the intended object changed. A green mocked test does not prove a dependency works. Match the evidence to the claim, redact secrets, and share only with authorized reviewers.

Use the companion Markdown template, or copy the case record below. The template contains nine starter rows and space to duplicate cases; a starter row is a coverage prompt, not proof that an entire category passed.

• CASE / REQ / AC: ____
• Role / starting state / data source and substitution permission: ____
• Exact reproducible steps or command: ____
• Expected result and rule source: ____
• Actual result: ____
• Status (PASS / FAIL / BLOCKED / NOT RUN / N/A): ____
• Pass evidence: artifact or redacted log, timestamp, version: ____
• Fail evidence: exact mismatch and artifact, timestamp, version: ____
• Persistence / external terminal-state readback: ____
• N/A rationale or remaining gap / owner / next step: ____
• Before-fix result / after-fix result / affected regression: ____
• Final-diff review evidence: ____

4. Worked example: a saved display name

Synthetic teaching example only. These inputs and outcomes are invented to demonstrate the record format; they were not run in the user’s production project or any live acceptance session.

Suppose an explicitly agreed rule allows 1–40 Unicode code points after trimming outer whitespace; a user can change only their own display name. This rule is an assumption for the example, not a recommended universal limit.

CASE-NAME-01 / AC-NAME-01: open Profile from the normal menu, save “River”, reopen Profile. Expected: “River” remains and the permitted readback identifies the same account. Hypothetical observation: the toast says saved but reopening shows the old value. Illustrative status: FAIL. Evidence to collect in a real run: before/after screen, redacted request and authoritative readback tied to the account and version. No such runtime evidence is supplied here.

CASE-NAME-02: try empty text after trimming, 1, 40, and 41 code points. Expected: reject empty and 41; accept 1 and 40 under the assumed rule. These are planned cases, NOT RUN. Count the actual samples before using them; code points, bytes, and user-perceived characters differ.

CASE-NAME-03: attempt to change account B using account A in the authorized test environment. Expected: denied with no change to B. CASE-NAME-04: interrupt a save, then retry according to the agreed recovery rule and inspect the final state. Both remain NOT RUN until executed with authorized test accounts and fault conditions.

5. Decide what is actually ready

Keep separate outcomes for repository standards, requirement coverage, and runtime acceptance. An unresolved FAIL, BLOCKED, or NOT RUN acceptance item prevents an overall completion claim for the agreed scope. “No demonstrable defects found in this diff” is a scoped review result, not a guarantee of no bugs.

If a check fails, preserve its evidence and classify the cause: product, test, environment, data, or unclear requirement. Do not weaken an assertion, remove a case, or rerun until lucky to obtain a pass. Repair only within authorization, rerun the original case and affected paths, then review the latest diff.

Use precise delivery language: implemented; locally verified; deployed; or live-path accepted. Local acceptance does not authorize deployment. Deployment does not by itself prove the user’s task works.

FAQ

Is code review enough for AI-generated code?

No. Code review shows whether the diff looks correct and safe; it does not show that the feature works after save, refresh or a failed request. Do both for any change a user will touch.

Can an AI agent review its own code?

It can help, but it should not be the final check. An agent that wrote the code can carry the same wrong assumption into its review, and OWASP's AI Security Verification Standard says the AI agent itself does not count as the human reviewer. Use a separate session for review and verify the result yourself.

How do I know AI-written tests are real?

Make each important test fail once on purpose: run it against the version before the fix, or break the guarded line, and confirm it fails. Then check that it asserts a concrete result, not just that a mock was called or no error was thrown. For a bug repair, How to Verify an AI-Generated Bug Fix walks through the before/after record.

What should I check first in an AI-generated pull request?

Check the scope and the tests first: does the diff match the requirement, and were any tests deleted, skipped or changed? Then check new dependencies, authorization and secrets, then run the feature.

Do I have to read every line?

For high-risk changes, yes. For low-risk changes, passing checks plus a look at the result is usually enough. Use the tiers above and write down which tier you chose.

I can't read code well. How can I still check AI-built software?

Check behavior you can observe: write the expected result in plain words, use the feature as a new user, reopen saved data, try empty and wrong inputs, and test with a second account that must not see the first account's data. For authentication, payments and personal data, get a technical reviewer.

Choose a related workflow

• talking-us: Unclear success rule or unresolved product decision: clarify requirements without changing the product.
• write-design-doc: Confirmed requirements but unclear API/data/state contracts: make the design implementable.
• test-case: Turn requirements into cases. Use design for planning or validation for authorized existing checks; mode names do not grant repair or data-substitution permission.
• bug-fixing: A reproduced failure: trace the first broken rule, repair only when authorized, and verify related paths.
• code-review-multiagent: Review the final diff against requirements and callers. Deep Solo is the default; independent agents are conditional on risk and host support.
• develop-closed-loop: Carry an authorized, specified change through implementation, testing, repair, regression, review, and delivery. Install required companion workflows separately.

Known limits and references

This is an original practical guide informed by the six workflow packages, not a report that their agent behavior was tested across models. Skills do not supply accounts, browsers, data, deployment access, or permissions. A single downloaded Skill is not the complete suite. Some UI-design branches refer to the external, unbundled frontend-design-lab workflow.

The template records evidence; it cannot detect defects by itself. Sampling needs a stated equivalence and uncovered branches. Synthetic examples cannot replace required real business data. When access is missing, keep dependent acceptance pending and continue safe independent checks.

For security basics, OWASP recommends permission validation on every request and enforcement at the appropriate trusted boundary: OWASP Authorization Cheat Sheet. For introductory accessibility checks and their limits, see W3C WAI Easy Checks. Neither reference makes this checklist a full audit.

For AI-specific review risks, see GitHub's guide to reviewing AI-generated code, Sentry's review playbook and OWASP's secure code review guidance. Package figures come from Spracklen et al., "We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs" (USENIX Security 2025). For the idea behind proving tests can fail, see Stryker's mutation testing docs.

Download the Markdown template