VLearnVibium

How to Verify an AI-Built App with Vibium

Verify an AI-built app with Vibium by letting the agent open the running app in a real browser, check the UI, and confirm flows end to end before you ship.

By Pramod Dutta··4 min read·Verified with Vibium 26.2
▶ Animated overview · made with Remotion

You verify an AI-built app with Vibium by letting the agent open the running app in a real browser and confirm the flows actually work. When an AI assistant writes code, it normally cannot tell whether the result runs — it only knows what it intended. Vibium closes that loop: it ships a built-in MCP server, so an assistant like Claude can launch a real Chrome for Testing browser over WebDriver BiDi, navigate to the running app, click through the key paths, read the rendered UI, and take screenshots. That turns "I think this works" into "I opened it and watched it work." Because Vibium auto-waits for elements to become actionable, the agent does not battle timing on dynamic, freshly generated pages. The same checks map to Vibium's Python and JS APIs, so you can also script a repeatable smoke test. The result is verification grounded in real behavior, not in a passing build or a hopeful code diff.

Why isn't a passing build enough?

A successful build only proves the code compiled — not that the app behaves. AI-generated apps routinely build cleanly yet fail at runtime: an undefined variable in an event handler, a broken API call, a button wired to nothing, a layout that collapses on load. Static review of the diff cannot catch these, because the bug only appears when the code actually runs in a browser.

Vibium gives the agent eyes on the real thing. By opening the running app and exercising it, the assistant observes the rendered result and surfaces failures that no amount of re-reading the source would reveal.

How do you connect Vibium for verification?

Add Vibium's MCP server to your AI assistant, then point it at your running app. In Claude Code:

claude mcp add vibium -- npx -y vibium mcp

Start a new session so tool discovery picks it up, then confirm it is registered:

claude mcp list

Chrome for Testing downloads automatically on first launch. The Vibium MCP in Claude Code guide covers headless mode and screenshot directories if you want the verification run to be silent or to save artifacts.

What does a verification pass look like?

Once connected, you describe the flow you want checked and the agent drives the browser to confirm it. Start your dev server, then prompt:

"Open http://localhost:3000, sign up with a test account, confirm you land on the dashboard, then screenshot it. Tell me if anything errored."

The agent chains Vibium's tools — navigate, find, type, click, screenshot — and reports back what it saw. If the signup button does nothing or the dashboard throws, the agent observes it directly rather than assuming success.

How do you script a repeatable smoke test?

For verification you want to run on every change, script it with Vibium's Python sync API. This mirrors exactly what the agent does through MCP, so it makes a clean post-build smoke test:

from vibium import browser_sync as browser
 
vibe = browser.launch()
vibe.go("http://localhost:3000")
 
# Exercise the critical path the AI just built
vibe.find(label="Email").type("verify@example.com")
vibe.find(label="Password").type("test-pass-123")
vibe.find(role="button", text="Sign up").click()
 
# Confirm the app actually advanced to the dashboard
heading = vibe.find("h1").text()
assert "Dashboard" in heading, f"Expected dashboard, got: {heading}"
 
# Capture visual proof
png = vibe.screenshot()
with open("verify-dashboard.png", "wb") as f:
    f.write(png)
 
vibe.quit()
print("Verified: signup flow reaches the dashboard")

Vibium runs actionability checks before each action and auto-waits up to 30 seconds, so the test stays stable even on a slow first render. See how to take a screenshot and find elements for the details.

What should you actually verify?

Effective verification focuses on the paths a user will hit first. Prioritize:

  • The happy path. Can a user complete the core flow the app was built for — sign up, create, save, check out?
  • Visible errors. Did any screen render a blank state, an error boundary, or a broken layout?
  • Data round-trips. Does what you submit actually appear back in the UI?
  • Screenshots as evidence. Capture each key screen so review is visual, not narrative.

Because Vibium is built on the WebDriver BiDi standard, it can also surface real-time signals like console errors as they happen, which makes runtime failures in generated code easier to catch.

Next steps

Frequently asked questions

How do I verify an app that an AI assistant built?

Connect Vibium's MCP server to your AI assistant so it can open the running app in a real Chrome browser, navigate the key flows, and confirm the UI works. The agent closes the loop by checking its own output instead of assuming the code it wrote is correct.

Why is browser verification better than reading the code?

Reading code only confirms intent, not behavior. Vibium lets an agent run the actual app, click through real flows, and observe the rendered result, catching runtime errors, broken layouts, and failed API calls that static review of generated code would miss entirely.

Can Vibium screenshot an AI-built app for review?

Yes. Vibium captures full PNG screenshots of any page, so an agent can grab the rendered UI at each step. You get visual proof that a screen rendered correctly, which is far stronger evidence than a passing build or a code diff alone.

Vibium is created by Jason Huggins. This is an independent tutorial — see the official Vibium site and GitHub repo for canonical docs.

Related guides