"Looks good" isn't evidence: how to verify AI-generated code

When a coding agent says “done”, what you have is a candidate. To verify AI-generated code, check it against the requirement and read the diff. Run the tests, lint, type checks and the build. Then get a review from something other than the model that wrote it. Code generation is not completion. Verification is completion.

A successful build is one piece of evidence, not proof the requirement was met. I learned that from AI-assisted work.

This guide matches each claim to the evidence behind it and puts the checks in order. It also has two prompts to copy, and what six coding agents offer to run checks for you. The tool behaviour comes from each tool’s official docs, last verified on 4 October 2026; none of it was tested for this post.

Part 2 of this series has a short verify step as the last stage of its workflow. This part goes deeper: how do you know the code is actually correct?

A passing build can hide a missing requirement

The risky workflow is a short one:

Prompt → AI writes code → app runs → "looks good" → done

An application running is not proof that the change is correct. A build can pass while:

• a requirement is missing
• an edge case is broken
• authorisation is wrong
• existing behaviour has regressed
• the architecture is violated
• the tests don’t cover the new path

GitHub’s tutorial on reviewing AI-generated code says the same thing in one line: “Be skeptical of code that “looks right” but doesn’t match your intent.”

Match every claim to its evidence

A claim about AI-generated code is only as good as the check behind it. Each claim has a better kind of evidence than the agent’s word:

Each row catches something different. A clean build tells you nothing about the requirement, and a green test suite tells you nothing about a file the agent changed by accident.

The model that wrote the code can’t be its only judge

Asking the same AI that wrote the code whether it works isn’t meaningful. It writes the code, you ask, and it says “Yes, the implementation looks good”. That’s one signal, counted twice. I’d never use the same signal for generation and verification.

The chain I’d want is generation, then independent checks that give different signals, then a human review. When an AI does review, give it a fresh start. Anthropic’s best practices explain why: a reviewer in a fresh sub-agent context “sees only the diff and the criteria you give it, not the reasoning that produced the change”. Part 1 covers setting up a reviewer sub-agent.

The checks, from requirement to evidence

The checks for AI-generated code follow the same order as Prompt 1 further down.

Re-read the requirement first

Turn the requirement into acceptance criteria, then hold the code against them:

Requirement → acceptance criteria → implementation → verification

Then ask “Did we actually solve the original problem?” rather than “Did the AI finish the task?”

Read every changed file, then the diff

Every changed file and the final diff answer one question: what exactly changed? Look for:

• unrelated modifications
• accidental refactoring
• unnecessary dependencies
• changed configuration
• removed validation
• security-sensitive changes
• generated files
• unexpected API changes

The diff is your audit trail.

Ask whether the tests prove the behaviour

Swap “did you write tests?” for a better question: do the tests prove the behaviour we care about? Good tests for a change cover the happy path, edge cases, failure cases, regression cases and the business rules that matter.

A passing test suite can still miss an untested requirement. Also check that the tests changed for the right reasons. GitHub’s tutorial puts it bluntly: “Watch for tests that are deleted or skipped, instead of fixed.”

Run lint, type checks and the build

Lint, type checks, the build and static analysis give the same answer every time. Don’t make the AI reason about things your tooling can verify deterministically. Let the tools catch what humans miss.

Try the edge cases and failure paths

Edge cases and failure paths are where plausible code breaks. Anthropic’s best practices list “the trust-then-verify gap” as a common failure. In their words: “Claude produces a plausible-looking implementation that doesn’t handle edge cases.” The hostile review prompt below is built to find them.

Look for security and dependency risks

Check every new dependency. GitHub’s tutorial asks you to “Check if suggested dependencies exist and are actively maintained”, and warns about “hallucinated or suspicious packages (such as packages that don’t actually exist)”. The same page lists “hallucinated APIs, ignored constraints, or incorrect logic” as things to look for. A security-sensitive change gets a security review.

Record the evidence

Write down what was checked, the command or evidence used, the result, and anything still unverified. Prompt 1 below asks the agent for exactly that, so you get the evidence in writing.

Verification hooks and review commands in six coding agents

Most coding agents can run verification checks for you through hooks, so nobody has to remember. Part 3 explains what a hook is. Here is what each tool offers for verification:

Each row comes from that tool’s official docs, last verified on 4 October 2026; none was tested. Copilot’s agent hooks in VS Code are in Preview.

All six can run a hook after an edit or a tool call. Five document a hook that sends the agent back for another pass when it tries to finish; the Windsurf docs don’t. Four have a built-in AI review of your changes.

Claude Code is the worked example here. Its hooks guide shows an agent hook on the Stop event that checks the tests before Claude may stop. It goes in .claude/settings.json:

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "agent",
            "prompt": "Verify that all unit tests pass. Run the test suite and check the results. $ARGUMENTS",
            "timeout": 120
          }
        ]
      }
    ]
  }
}

The same page says agent hooks are experimental, and to prefer command hooks for production workflows.

What the agent can check, and what stays with you

AI and tooling are good at the checks that have a clear answer. Humans own the decisions that need judgement:

GitHub says the same about its own reviewer. Its code review docs say: “Copilot is not guaranteed to spot all problems or issues in a pull request. Sometimes it will make mistakes. Always validate Copilot’s feedback carefully. Supplement Copilot’s feedback with a human review.” AI accelerates engineering, but it doesn’t remove engineering judgement.

Two prompts to copy

Neither prompt relies on a tool-specific feature. Prompt 1 goes further than Part 1’s implement and verify prompt and Part 2’s follow-up: as well as each result, it asks for the command or evidence behind every check.

Prompt 1: verify the work

Paste it after the agent finishes coding, before you accept the change.

The implementation is complete.

Do not assume the task is done.

Verify the work independently.

1. Re-read the original requirement.
2. Identify the acceptance criteria.
3. Review every changed file.
4. Inspect the final diff.
5. Run relevant tests.
6. Run lint and type checks.
7. Run the build where applicable.
8. Check edge cases and failure paths.
9. Look for unintended behaviour changes.
10. Look for security or dependency risks.

For each check, report:
- what you checked
- the command or evidence used
- the result
- anything still unverified

If something fails, investigate the root cause and fix it.
Do not commit, push, deploy, run destructive commands or make external
changes unless I explicitly authorise it.
If two reasonable attempts fail, stop and report the failure rather than
repeatedly guessing.

Do not claim completion without verification evidence.

Prompt 2: hostile review

Use it for a second opinion. Run it in a fresh session or a sub-agent if your tool has them, so the reviewer sees the diff and not the reasoning behind it.

Change to review: <the diff, branch or commit>
Requirement: <paste the requirement or acceptance criteria>

Assume this implementation contains a serious bug.

Try to prove it wrong.

Look for:
- edge cases
- incorrect assumptions
- security issues
- race conditions
- error handling problems
- regressions
- missing tests
- violations of existing architecture

Do not rewrite the code yet.
Do not commit, push, deploy, run destructive commands or make external
changes.

Report findings with evidence.

A reviewer told to find gaps “will usually report some, even when the work is sound”, say Anthropic’s best practices. Act only on findings that affect correctness or the requirement.

A checklist for AI-generated code: the definition of done

The full checklist, a definition of done for AI-written code, ready to copy:

AI CODING: DEFINITION OF DONE

□ Requirement understood
□ Relevant existing code inspected
□ Implementation completed
□ Tests added/updated
□ Tests passed
□ Lint passed
□ Type checks passed
□ Build passed
□ Final diff reviewed
□ Unintended changes checked
□ Edge cases considered
□ Security implications considered
□ Acceptance criteria verified
□ Remaining uncertainty documented
□ Human review completed where necessary

If you find the same verification work happening on every task, that’s a workflow worth packaging. Part 5 of this series is about when repeated work like that deserves a skill, and how to write one.

Quick answers

How do you verify AI-generated code?

Verifying AI-generated code means checking it against the original requirement, reading the final diff, and running tests, lint, type checks and the build. Then get a review from someone or something other than the model that wrote it, and keep a record of what is still unverified.

Can an AI coding agent review its own code?

An AI coding agent can review code, but the same session that wrote it is biased towards its own reasoning. A reviewer in a fresh session or sub-agent, which sees only the diff and the criteria, gives a more independent signal.

Is a passing build enough to trust AI-generated code?

A passing build only shows that the code compiles. AI-generated code can build cleanly while a requirement is missing, an edge case breaks, authorisation is wrong or the tests skip the new path.

What should a human check in AI-generated code?

A human should own the decisions tools cannot make. That means product intent, business rules, architectural trade-offs, acceptable risk, user experience (UX) and security-critical choices, and whether the change solves the user’s actual problem.

Can a coding agent run tests automatically after each edit?

Claude Code, OpenAI Codex, Gemini CLI, Cursor, Windsurf and GitHub Copilot all document hooks that run a command after the agent edits a file or calls a tool. A test or lint command there runs every time, not only when the agent remembers.

More on AI coding is in the AI category.