Preview deployments keep AI coding agents honest before merge

AI coding agents are fast. That is the whole problem. An agent can open a pull request with three new pages, a changed auth flow, and a refactored API route before you finish your coffee. The diff looks reasonable. The description is confident. And somewhere in there is a broken redirect, a layout that collapses on mobile, or an environment variable the agent assumed existed.

Reading the diff is not enough anymore. You need to click through what the agent built before it merges. Preview deployments give you that gate: every pull request gets its own live URL, built from that branch, running with production-like settings. Review the running app, not just the code.

Why agent output needs a running review

Human developers carry context the reviewer shares. When a teammate opens a PR, you know roughly what they touched and why. Agent-built PRs are different in three ways.

First, agents change more surface area per PR. Ask for a settings page and you may also get a new layout file, a touched middleware, and a migration you did not request. The diff is wide and the intent is buried.

Second, agents write plausible code that fails at runtime. Missing environment variables, wrong redirect targets, components that render fine in isolation but break inside your real layout. Static review misses these because each file looks fine on its own.

Third, agents do not dogfood. A human developer ran the app while building it. An agent may never have loaded the page in a browser at all. The preview URL is the first time anyone actually sees the thing working.

The merge rule that follows is simple: no agent PR merges without a green preview deployment that a human opened and checked. It sounds slow. In practice it takes five minutes and catches the failures that cost hours after merge. This is one step inside a wider shipping checklist for AI-built apps that every team running agents should adopt.

How preview URLs work as a review gate

The mechanics are straightforward. Connect the repository to a hosting platform that builds previews per pull request. Every push to the branch rebuilds the preview. Each preview gets a unique URL tied to that branch or commit.

Vercel documents three default environments — local, preview, and production — where preview covers exactly this pre-production check step (Vercel environments). The same pattern exists on other platforms, but the idea is identical: the PR carries a live link, and that link is the review surface.

A practical gate looks like this:

# review gate for agent-built pull requests
merge_requirements:
  - preview_build: success
  - typecheck_and_lint: pass
  - human_opened_preview: true
  - checklist_completed: true

Status checks can enforce the first two automatically. The last two are process: the reviewer confirms they actually opened the URL and walked the checklist. For agent PRs, make that confirmation explicit in the PR template rather than implied.

One detail worth setting up early: preview environment variables. Agents frequently introduce calls to new variables — an analytics key, a feature flag, a third-party secret. If previews do not have those variables, the preview fails for reasons unrelated to the code. Keep a documented set of non-secret preview defaults so agent PRs build cleanly:

# preview-safe defaults, reviewed quarterly
PREVIEW_API_URL=$PREVIEW_API_URL
PREVIEW_FEATURE_FLAGS=$PREVIEW_FEATURE_FLAGS
PREVIEW_ANALYTICS_ENABLED="false"

Note the form: references, not pasted secrets. Never put real keys in docs or chat logs.

The five-minute preview checklist

You do not need a full QA pass on every agent PR. You need a short, repeatable walk that catches the failure modes agents produce most. Run this on the preview URL before approving.

First, load the changed pages cold. Open the preview URL in a fresh tab, not from cached state. Agents break entry points: a page that only renders after client-side navigation, a redirect loop on first load, a blank screen because data fetching assumed a session that does not exist yet.

Second, check auth boundaries. If the PR touches anything near login, roles, or protected routes, open the protected page logged out and the login page logged in. Agents are notably bad at guard coverage — they add the happy path and skip the redirect back. For a deeper treatment of this exact failure, see our guide to auth guards in production builds.

Third, resize to mobile width. Agent-generated layouts skew desktop. A two-column grid the agent added will overflow a 390px viewport, or a modal will sit off-screen. One resize pass catches most of it.

Fourth, submit every form the PR touched. Empty submit, invalid input, valid input. Agents wire the success path and forget validation states, loading states, and error messages. Watch what happens on failure — a silent no-op is the most common agent form bug.

Fifth, open the browser console. Agent PRs throw warnings and errors that never surface in the diff: a missing key prop flood, a failed fetch to an endpoint that does not exist yet, a hydration mismatch from rendering different content on server and client. A clean console is a fast proxy for a careful PR.

Log the result in the PR with a short comment so the check is visible:

Preview check on branch preview URL:
- [x] Cold load, changed pages render
- [x] Auth boundaries hold both directions
- [x] 390px layout, no overflow
- [x] Forms: empty, invalid, valid submits
- [x] Console clean

Five lines. Anyone reading the PR later can see the running app was actually reviewed.

What to automate around previews

The human walk matters, but automation removes the boring parts and keeps agents from merging surprises at midnight.

Start with branch preview comments. Most platforms post the preview URL on the PR automatically. If yours does not, add it. The agent — and the reviewer — should never have to hunt for the link.

Next, add smoke checks that run against the preview URL, not just the code. A lightweight script that hits the changed routes and asserts status codes catches dead pages before a human ever opens the tab:

// smoke.ts — run against the preview URL after each build
const routes = ["/", "/pricing", "/settings", "/login"];

for (const route of routes) {
  const res = await fetch(`${process.env.PREVIEW_URL}${route}`);
  console.log(route, res.status);
  if (!res.ok) throw new Error(`route failed: ${route}`);
}

Keep this list short and tied to real user paths. Ten routes that matter beat a hundred generated assertions nobody maintains.

Visual regression snapshots are the third layer, and the one most worth adding once agent PRs touch styling regularly. A screenshot comparison on the changed pages flags the shifted hero, the overlapping nav, the suddenly unstyled button. You do not need full coverage — snapshot the pages the PR changed and the shell layout around them.

Finally, protect production explicitly. Previews are disposable; production is not. The broader production-readiness pass — backups, rollbacks, monitoring, secrets — belongs in a separate checklist that agent PRs do not get to skip either. Our production shipping checklist covers that layer in full.

The merge rule and the exceptions

The rule: every agent-authored PR merges only from a green preview that a human opened. Put it in the contributing guide. Put it in the PR template. Enforce what you can with required status checks and leave the human confirmation as a checkbox with a name attached.

There are legitimate exceptions. Documentation-only changes, comment edits, and config changes with no user-facing surface do not need a click-through. Define those narrowly — a short allowlist in the contributing guide — so the exception does not swallow the rule. Anything that renders, redirects, authenticates, or accepts input goes through the preview.

There is also the question of who counts as the author. If a human wrote the code and an agent formatted it, the normal review applies. If the agent planned the change, wrote the files, and described the PR, treat it as agent-authored even if a human pressed the button. Judge by who made the decisions, not who pushed the commits.

Pair this with good starter discipline. Many agent failures trace back to a template that made bad output easy — no type checking in CI, no auth scaffolding, no preview wiring at all. Picking a foundation that already ships those rails cuts the whole category down, which is the argument we make in our starter-kit guide.

Make previews the default, not the favor

The teams that review agent output well share one habit: the preview URL is where review happens, and the diff is supporting material. That inversion is the whole shift. Diffs tell you what changed. Previews tell you what broke.

Set it up once — previews on every PR, preview env vars documented, smoke checks running, PR template carrying the five-line checklist — and every agent PR after that gets an honest review gate for five minutes of human time. The agents stay fast. The merges stay safe.

Sources

• Vercel documentation on local, preview, and production environments, including preview environment behavior.
• Internal review practice from shipping agent-assisted pull requests behind preview gates.