How to Verify AI-Generated Code Before You Merge It

The problem with reviewing code you did not write

An AI coding agent can produce a working feature in minutes. The bottleneck moved: the constraint is no longer how fast code gets written, it is how confidently anyone can say the code does what it was supposed to do. Reading a large diff carefully takes longer than generating it did.

Type checks and unit tests confirm the code does what it was written to do. They cannot tell you whether the deployed application still works, because they never open one. That gap is where AI-generated regressions actually live.

The loop, in three commands

Install the open-source TestSprite CLI — free, Apache-2.0, Node 20.19+, 22.13+, or 24+:

npm install -g @testsprite/testsprite-cli
testsprite setup

Then the loop. Describe the behaviour you want guaranteed, run it against a real browser, and read the verdict from the exit code:

# 1 — create the test and run it
testsprite test create --project prj_abc123 --type frontend \
  --plan-from ./checkout-flow.plan.json --run --wait --output json
#   → exit 1: the run failed

# 2 — pull ONE self-consistent failure bundle
testsprite test failure get test_3a9f21c7 --out ./.testsprite/failure

# 3 — fix the code, then replay the same test
testsprite test rerun test_3a9f21c7 --wait --output json
#   → exit 0: passed

The bundle in step two is the part that matters. It contains the failing step, its neighbouring steps, screenshots, DOM snapshots, the test source, a root-cause hypothesis, and a recommended fix target — all sharing a single snapshot id. The CLI refuses to combine data from two different runs, so an agent is never reasoning over a context assembled from two different states of the application.

Why a durable suite beats a bigger context window

Every test that passes is banked. The next time the agent touches the codebase, that requirement is still being checked — whether or not it is anywhere in the current conversation.

This is the structural argument for external verification. A context window holds what the agent is thinking about right now. A test suite holds every requirement the project has ever gotten right, and it keeps holding them across sessions, across agents, and across the months when nobody remembers why a particular edge case mattered.

Set your agent up to do this itself

You should not have to relay commands between a web page and your coding agent. One setup command installs a skill file into the repository describing the loop in the form an agent actually consumes:

TESTSPRITE_API_KEY=sk-... testsprite setup --from-env --yes --agent claude

Supported harnesses are claude, codex, cursor, cline, antigravity, kiro, windsurf, and copilot. Installation is purely local. After that, the agent knows how to create, run, and triage tests without being told again in every session.

Before spending a turn on a command that will fail for environmental reasons, check the environment:

testsprite doctor    # CLI and Node versions, profile, credentials, connectivity

What to verify first

Not everything deserves an end-to-end test. In a codebase changing quickly under an AI agent, the highest-value coverage is narrow:

1. The flows that produce revenue. Sign-up, checkout, and billing. A regression here costs money immediately and is frequently invisible in unit tests.

2. Anything involving authentication. Session handling, redirects after login, and permission boundaries are where a plausible-looking refactor does the most damage.

3. Forms and validation. Cheap to describe, disproportionately likely to break when a component library is upgraded or a field is renamed.

4. The last three bugs you shipped. A regression test written after a fix is the single highest-yield test in any suite.

If you would rather have the first set proposed for you, exploration can draft them. Proposals are staged for review and nothing is written to your disk until you accept:

testsprite test plan generate --project prj_abc123
testsprite test plan accept --project prj_abc123           # all of them
testsprite test plan accept --project prj_abc123 --only prop_2 prop_5

Making the check mandatory

A verification step that runs only when someone remembers to run it is not verification. Put it in CI:

testsprite ci init github

That scaffolds .github/workflows/testsprite.yml using TestSprite/testsprite-action@v1, which annotates the PR checks tab with one error per failure, appends a results table to the job summary, uploads a JUnit report, and — importantly — fails the job on a partial run rather than reporting it green.

That is the path where your workflow drives the run. TestSprite also installs as a GitHub App that listens for the deployment events your pipeline already produces and comments results back on the pull request, which needs no workflow file and no repository changes at all.

In any other CI system the CLI needs only an API key in the environment:

export TESTSPRITE_API_KEY="$TESTSPRITE_API_KEY"
testsprite test run --all --project prj_abc123 --wait \
  --report junit --report-file testsprite-junit.xml \
  --summary-file testsprite-summary.json

Exit codes worth branching on

Codes 129, 130, and 143 mean the process was interrupted by a signal (128 plus the signal number), not that a test failed — worth distinguishing before reporting a run as broken.

Frequently asked questions