TL;DR: To verify code written by an AI agent like Claude Code, Cursor, or Copilot, don't stop at "the diff looks right" — you have to run the app and confirm the change behaves as claimed. Type checks and unit tests catch structural problems; they don't catch a button wired to the wrong handler or an empty state that never renders. The reliable loop is: agent opens a PR → a preview deployment builds → something drives the running app in a real browser → you get a pass/fail verdict before you review. screencli is an AI reviewer that does exactly that step automatically on every pull request.
How do you verify code written by an AI agent like Claude Code or Cursor?
Verify agent-generated code by exercising the running application, not just reading the diff. The most trustworthy signal is a browser (or client) actually performing the user flow the change touches and confirming the expected result appears — the checkout completes, the modal opens, the error toast shows on bad input.
Reading the diff and running tsc tells you the code is well-formed. It does not tell you the code is correct. Agents are very good at producing plausible, well-formed code that compiles and still does the wrong thing. The gap between "compiles" and "works" is exactly where agent output fails, and it's the gap a verification loop has to close.
This matters more every month. The PullFlow State of AI Code Review 2025 report, which analyzed 40.3 million pull requests, found that 14.9% of PRs now involve an AI agent — a 14x increase since February 2024. More code is being generated by agents than any human review process was designed to absorb.
Why "it compiles" isn't enough for agent-generated code
A green build is a necessary condition, not a sufficient one. Here's what the standard checks miss:
- Type checks confirm shapes line up. They can't tell you a handler was wired to the wrong function.
- Linters enforce style and catch a narrow band of bugs. They don't open a page.
- Unit tests verify the units the agent chose to test — and agents routinely write tests that assert their own (possibly wrong) implementation, so the test passes and the behavior is still broken.
- A diff review shows you the intended change. It can't show you the runtime side effects, the state that never updates, or the network call that 500s.
The data backs this up. A CodeRabbit analysis of 470 real-world pull requests found AI-generated PRs carry roughly 1.7x more issues than human-written ones across logic errors, security, maintainability, and performance. And a January 2026 GitHub study, "More Code, Less Reuse," found agent-generated code introduces more redundancy and technical debt per change — while reviewers, worryingly, "actually feel better about approving it." Confidence in the output is rising faster than its correctness.
The specific ways agent-written code goes wrong
If you're going to trust Claude Code or Cursor output, know its failure modes. Four recur constantly.
Plausible-but-broken UI
The agent adds a button, a form, a settings panel. The JSX is clean, the styling matches, the component renders in isolation. But the button's onClick points at a stale handler, the form submits to the wrong endpoint, or a loading state never resolves. It looks done in the diff. It's broken the moment a human clicks it. This is the single most common agent failure, and it is invisible to every check that doesn't render the page.
Missing edge cases and error states
Agents optimize for the happy path described in the prompt. Ask for "a form that saves the user's profile" and you'll get a form that saves the profile — when everything succeeds. The empty state, the validation error, the network failure, the "field is already taken" case: frequently absent, because nobody asked for them explicitly and no test exercised them.
Hallucinated APIs, packages, and imports
Agents confidently reference functions, config keys, and dependencies that don't exist. The most measured version of this is package hallucination. In a study presented at USENIX Security 2025 ("We Have a Package for You!"), researchers generated 576,000 code samples across 16 leading models and found 19.7% — nearly one in five — of recommended packages did not exist, spanning over 205,000 unique fabricated names. Attackers now pre-register the names models reliably hallucinate ("slopsquatting"), turning a correctness bug into a supply-chain risk. Hallucinated internal APIs are subtler and just as common: the agent calls user.getPreferences() because it sounds right, and it isn't a real method.
Confident-but-wrong logic
Off-by-one errors, inverted conditionals, a permission check that returns true on the wrong branch. The code is syntactically perfect and semantically wrong. GitClear's 2026 Maintainability Gap report tracked this drift at scale: as AI authorship rose, code-block duplication climbed 81% over 2023 and error-masking constructs rose 47% — the kind of quiet defects that pass review and surface in production.
The verification loop that actually runs the app
Here's a loop that closes the compiles-vs-works gap for any agent (Claude Code, Cursor, Cline, Windsurf) without you hand-testing every change:
- The agent opens a PR. Same as today — the agent edits code and pushes a branch.
- A preview deployment builds. Vercel, Netlify, or Cloudflare Pages deploys the branch to a unique URL. This is the running app for exactly this change — nothing mocked.
- Something drives the running app in a real browser. Navigate to the flows the diff touched, click through them, submit the forms, trigger the error paths. This is the step that catches the broken
onClickand the missing empty state. - You get a verdict before you review. Pass/fail plus a recording of what happened, posted where the PR lives — so a human starts from evidence, not from a cold diff.
- The agent iterates on failures. A failed browser check is a far better signal to hand back to Claude Code or Cursor than "a test is red," because it describes the user-visible break.
You can run step 3 yourself from inside your agent loop with a one-liner before you even open the PR:
npx screencli verify https://pr-274-checkout.preview.app \
-p "Add an item to the cart, go to checkout, complete the purchase, confirm the order ID renders"For the deeper mechanics of driving a real browser from an agent, see How to Use Playwright and Claude Code to Verify AI Agent Work and Preview Environments + Visual Verification for Agentic Coding.
Verification layers compared: what each one actually catches
| Layer | Catches | Misses | Runs the app? |
|---|---|---|---|
| Type checks / linter | Shape mismatches, style, some nulls | Wrong handler, broken flow, hallucinated logic | No |
| Unit tests | Logic the author chose to test | Untested paths, integration, real UI | No |
| Diff-based AI review | Smells, obvious bugs, security patterns in the text | Runtime behavior, "does the button work" | No |
| Manual QA | Almost everything — if you have the time | Every PR, at agent volume (you don't) | Yes |
| screencli (browser PR verification) | Plausible-but-broken UI, missing states, flows that 500 — on every PR | Deep logic with no user-visible symptom | Yes |
The pattern is clear: the layers that scale don't run the app, and the layer that runs the app (manual QA) doesn't scale. Browser-based verification is the missing row.
Why browser-based PR verification is the missing layer
screencli is an AI reviewer that opens your preview deployment in a real browser on every pull request, reads the diff to decide what to test, clicks through the change like a human, and posts a pass/fail verdict with a recording — before your review starts. No test files to write; the AI decides what to exercise based on what changed.
That's the layer diff-based tools can't provide: it's the difference between reading the code the agent wrote and watching the feature actually work. For teams shipping Claude Code, Cursor, and Copilot output at volume, it's how you keep the quality bar without turning your senior engineers into a manual QA queue.
Install the screencli GitHub App, point it at your repos, and open your next PR — you'll get back a verdict and a recording before you take your first sip of coffee. Prefer to stay in your terminal? Run npx screencli verify from inside any AI agent to check the work before the PR even opens.
A checklist for verifying Claude Code / Cursor output before you merge
Use this as a fast gate on any agent-generated PR:
- Did the app actually run? If nothing rendered the change in a browser, you haven't verified it — you've read it.
- Was the happy path clicked end-to-end? Not asserted in a unit test — clicked, on the preview URL.
- Were the error and empty states triggered? Bad input, no results, network failure.
- Do the imports and dependencies exist? Scan for hallucinated packages and internal APIs; treat any new dependency as suspect.
- Does the recording match the ticket? The behavior on screen should match what the change claims to do.
- Is there evidence attached to the PR? A verdict and a recording, so review starts from proof, not a diff.
If every box is checked automatically on every PR, agent velocity stops being a review liability.
Frequently asked questions
Is reviewing the diff enough to trust AI-generated code? No. The diff shows intent, not runtime behavior. Agents produce well-formed code that compiles and still ships a broken button or a missing error state. You need to run the app to confirm the change works.
Do unit tests written by the agent count as verification? Only partially. Agents often write tests that assert their own implementation, so a passing test can encode the same wrong assumption as the code. Tests are valuable, but they don't replace exercising the real UI on a preview deployment.
What are the most common ways Claude Code or Cursor output breaks? Plausible-but-broken UI (handlers wired wrong, states that never resolve), missing edge and error cases, hallucinated APIs and packages (~19.7% of AI-recommended packages don't exist, per USENIX Security 2025), and confident-but-wrong logic.
How do I verify agent code without manually testing every PR? Automate the browser step. Tools like screencli open your preview deployment on every PR, drive the changed flows in a real browser, and post a pass/fail verdict with a recording — so verification scales with agent output instead of bottlenecking on human QA.
Can I verify the code before I even open the PR?
Yes. Run npx screencli verify <preview-url> -p "…" from inside Claude Code, Cursor, or any agent that can run shell commands, and let the agent fix failures before a human ever sees the PR.