You ask Cursor or Claude to add one small feature to your vibe-coded app. It works. You ship it. Three days later a user emails you: login is broken. It has probably been broken since that prompt, because you stopped checking login four prompts ago. Testing a vibe-coded app is mostly about catching that before the user does.

To test a vibe-coded app, identify the user journeys that must keep working, define the expected result of each one as assertions, automate those browser flows with a test recorder, and rerun them after every meaningful AI-generated change. Start with authentication, payments, and the product's core action, then expand to the flows teams usually skip.

This is for small to mid-sized SaaS and web teams — including product managers and other non-technical contributors — who need a practical way to automate web test flows without writing code. We'll cover how to choose critical journeys, do a manual baseline run, record end-to-end tests, add assertions, keep tests running continuously after AI changes, and plug them into CI/CD so regressions show up early instead of in customer emails.

That's the short version. Here's how to set it up.

What Does Testing a Vibe-Coded App Actually Mean?

Nothing new, technically. Testing a vibe coding project is still functional testing, end-to-end testing, smoke testing, regression testing and security testing. There's no separate discipline called "AI app QA." What changed is the workflow and the speed of change.

When a person writes a feature, the blast radius is predictable - they touched three files and know which three. When you prompt for one, the model may also refactor a shared component, rename a state variable or simplify a validation rule you needed. You asked for a discount field. You got edits across six files you never opened.

So the question shifts. Not "did my new feature get built correctly?" but "did anything that already worked stop working?" The job is to decide which behaviors the next iteration isn't allowed to break, then check them automatically.

Why Vibe-Coded Apps Need a Regression Safety Net

This isn't an "AI writes bad code" argument. AI-generated code is frequently fine. The problem is arithmetic: change velocity outruns the capacity of one person clicking through the app after each prompt.

Keep this example in mind for the rest of the article.

The prompt: "Add a discount code field to checkout."

You test it. Valid code, total drops, order goes through. Ship it. What you didn't test:

• checkout without a discount code
• a declined or failed payment
• annual billing vs monthly
• logging out and logging back in
• an existing customer upgrading their plan

Any of those can break from a checkout refactor. None are the thing you just built, so none get clicked.

Large-scale analysis of AI-authored commits suggests AI-generated changes can still introduce bugs, code-quality issues and security problems that survive later revisions; GitClear's review of 211 million changed lines found code duplication rising and refactoring falling through 2024. Be precise about what that proves. It's a codebase-drift signal, not a measure of how often user flows break. It can't tell you whether your checkout still works. Only a test that exercises checkout can.

This lands hardest on small teams. Across BugBug's customer base, 61% have zero to three dedicated QA people and 77% run engineering teams of five to forty - the shape of most vibe-coded products too: plenty of shipping capacity, almost no checking capacity. Hence the value of learning to automate regression testing without developers instead of routing every check through the one person who can read the diff.

What Should You Test First in a Vibe-Coded App?

Don't start with a coverage percentage. Start with consequence. If this flow breaks, do you lose a user, lose money, or lose access to the product?

Everything in P0 belongs in your smoke testing suite — the checks you run after every meaningful change, not just before releases. Three to five tests is a legitimate start; ten well-chosen ones catch more real regressions than sixty written to hit a number.

That ordering isn't theoretical: end-to-end regression, critical-path monitoring and smoke tests are the three primary use cases across BugBug's account base (ICP analysis, 2026). Teams converge on the same short list because that's where the consequences are.

How to Test a Vibe-Coded App Step by Step

1. Write Down the Critical User Journeys

Not technical test cases. Use plain language to describe the happy path for the core task so a non-technical person can follow it:

• New user signs up → confirms email → logs in → creates their first project.
• Existing customer logs in → upgrades plan → sees the upgraded account.
• User uploads a file → runs the core action → sees the result.

For each journey, also note the main failure modes and any important data boundaries, using a boundary-first testing approach rather than only naming screens or UI elements.

Write three to five. Any more and you'll never finish step one. The structured version is here: how to create a test plan.

These journeys are your contract. Everything below makes them enforceable.

2. Define What Success Looks Like

This is where most first attempts fall apart. "Click Create Account" is an action — it proves a button was clickable, not that an account exists.

A test needs an outcome that covers the happy path and what happens when key inputs are missing or invalid:

Click Create Account → user reaches /dashboard → the account name is visible in the header → a confirmation email arrives.

Actions are what you do. Assertions are what must be true afterwards. Every critical journey needs at least one, and it should be something a broken build would actually fail: a URL, a piece of text, a status change, a record that now exists. Define checks around user input and server side outcomes too, not just visible UI changes.

If you can't write down the expected result, you don't have a test. You have a script that clicks.

3. Run One Manual Pass First

Open a fresh browser profile and walk the flow as a brand-new user for basic manual verification. Don't debug code. Just observe what happens and what state you expect, because this first pass often catches usability issues and gaps between the product and the user's mental model before you automate the flow. You'll usually find something already broken — a confirmation email that never sends, a redirect to the wrong page. Fix that first, because automating a broken flow gives you a red test you'll learn to ignore.

You do this pass once. Everything below exists so you never repeat it by hand.

4. Record the Critical Flow as an E2E Test

Now make the journey repeatable. Write it in Playwright or Cypress as test scripts, or record it. If you're not planning to own a framework, record it. With an AI-assisted test recorder:

1. Open your app in Chrome.
2. Start the BugBug recorder.
3. Perform the user journey as a real user would.
4. Stop recording.
5. Review the captured steps and delete anything accidental.

No WebDriver setup, no Selenium grid, no Docker, no runner config. The recorder handles the work behind selectors and timing — adaptive locators so a renamed CSS class doesn't kill the test, smart waiting so it doesn't fail because a spinner ran 200ms long. If you do keep tests in the repo, version control matters because they should evolve with the app.

The division of labor matters: AI assists with creating and maintaining the test. You decide which behavior is worth protecting. Nothing reads your repo and works out what your product is for. Claude Code is one example of an ai tool that can help generate or refine tests, while you still choose what to protect. If it's your first time, here's how to record your first automated test.

5. Add Assertions, Not Just Clicks

A recorded flow with no assertions only proves a browser executed some steps. It passes on a badly broken app as long as the buttons exist. Go back through and add checks:

• the URL changed to /dashboard
• a confirmation message appears
• the correct user name is visible
• the subscription status now reads "Pro"

Weak test: Click Submit.

Useful test: Click Submit → verify the dashboard is displayed → verify the account name appears → verify the plan badge shows the new tier.

The second fails when the app is broken. The first fails only when it's very broken. One assertion per meaningful state change. This is also where manual checks on a single line of logic or one branch of generated code can save you from a passing but shallow browser test.

6. Include the Flows Vibe-Coded MVPs Often Skip

Some flows get implemented once and never verified again, because they're tedious to check by hand.

Email flows are the biggest. Signup → confirmation email → confirmation link → login is a critical path almost nobody automates, because it means a fresh inbox every run. A built-in testing inbox handles that: the test creates a unique address, the app sends to it, and the test opens the message and clicks the link in the same run. Same for password reset.

Also worth covering: popups and second tabs (OAuth, payment providers), and test accounts in different states driven by variables rather than hardcoded credentials, so you avoid hardcoded secrets. Use environment variables and the env file for api keys, passwords, and other encryption keys, not recorded steps or source code; sensitive files should be ignored in version control and must not be publicly accessible in the deployed app. Integrations with third party services like OAuth or payment providers need extra checks because they often expose edge cases outside the main flow.

7. Rerun the Tests After the Next AI Change

Back to the discount code.

You prompt for the field. The model makes its edits. Instead of clicking only the discount box, you run the test suite: login, checkout with and without a discount, the core action, the upgrade flow, with existing integration tests running alongside the browser checks when you have them.

All green means the change didn't break what you'd already decided was critical. If checkout-without-discount goes red, you found it in ninety seconds instead of from a support email on Saturday.

That's the loop:

Prompt → Build → Run tests → Ship

The test run is the only part that doesn't depend on you remembering what to check. That's exactly the step most vibe coders skip.

8. Run Critical Tests Automatically Once the App Matters

While it's a prototype with no users, running tests locally when you remember is fine. That changes when real users have accounts, money moves through the app, or you deploy on a cadence. Move the smoke suite off your laptop: schedule cloud runs against production, add a quick startup check before deploy by rerunning the suite and confirming environment-specific configuration, and run E2E tests in CI/CD so a failing checkout blocks the deploy instead of reaching users.

This step separates teams who get value from automated testing from teams who abandon it. In BugBug's analysis of its best-retained accounts, the clearest signal wasn't how many tests a team had — it was whether they'd wired the suite into the release pipeline through CI, webhooks or Slack and treated it as a gate rather than a check someone runs when they remember. Production code still needs manual checks outside browser flows, including verifying lockfiles for reproducible builds and reviewing dependency risk, since 85-95% of applications rely on open-source libraries and projects. A suite nobody looks at produces false confidence. For a public web app, deployment hardening can also include a web application firewall to reduce attack exposure once the app is live.

Manual Testing, a Coded Framework or a Recorder?

There's no universally correct answer, only one for your team's shape.

If your engineers want tests in the repo, reviewed in pull requests, versioned with the application — go Playwright. Test-as-code gives you control no recorder matches, and those tests also benefit from standard code review alongside app changes. The cost is that someone owns that framework permanently. Worth stating plainly, since BugBug publishes this article: when BugBug asked its users in a February 2026 survey what they'd switch to if BugBug disappeared, Playwright was the most common answer by a wide margin, Cypress second.

The recorder case is different. If the person who knows the critical flows best is a founder, a PM or a support lead, they can protect the flow themselves instead of filing a ticket and waiting a sprint — roughly one in five BugBug accounts. That also makes sense when vibe coding tools or ai coding assistants help a team move faster, but important flows still need manual verification. It's the practical route to QA automation without a dedicated QA team, and why codeless testing tools exist as a category. For the discipline underneath all three, start with end-to-end testing.

One thing that isn't a trade-off: doing nothing.

What Automated Browser Tests Will Not Catch: Security Vulnerabilities

Worth being blunt, because this market oversells.

Browser E2E tests don't replace:

• Security review and penetration testing. Authorization logic, common security vulnerabilities, and other security vulnerabilities such as sql injection, cross site scripting, and exposed secrets may be missed by a passing user flow. If user input is not validated and sanitized on the server side, XSS can expose the user's data and other sensitive information.
• Unit tests. Business logic and edge-case branches are cheaper to verify at that level.
• API-level testing. Contract changes and integrations behind the UI.
• Performance and load testing. Performance testing measures application speed and resource usage under different workloads; your test passes at one user, but it says nothing about a thousand.
• Accessibility review. Keyboard navigation, screen readers, contrast.
• Native mobile testing. Browser automation covers browsers.
• Human UX judgment. A flow can pass every assertion and still be confusing.

A separate security checklist should verify security headers, publicly accessible routes, sensitive files, api keys, environment variables, hardcoded secrets, and other exposed secrets before a deployed app goes live.

Say it plainly: a passing E2E test does not prove that a vibe-coded app is secure. It proves a specific user journey still behaves as expected. Anything handling payments, personal data or authentication needs its own security review, however green your suite is. For higher-risk ai built applications, get a security team review when one is available.

A Minimal Vibe-Coded App Testing Checklist

Run this before you let people in, and again before each meaningful release:

☐ Signup works with a fresh account

☐ Existing users can log in

☐ The app's core action completes end to end

☐ Payment flow produces the correct account or order state

☐ Password reset or email confirmation works

☐ Critical pages reject unauthorized access appropriately

☐ Every critical automated flow contains assertions, not just clicks

☐ Smoke tests pass after the latest AI-generated change

☐ Run any existing integration tests or test suite checks before release

☐ Failed tests have an owner rather than being ignored

☐ Security-sensitive features received a separate security review

☐ Confirm no sensitive files, env file values, API keys, or other hardcoded secrets are publicly accessible

☐ If the latest AI-generated change touched them, do manual verification of the login flow, the core task, and one important failure case

If you can't tick all ten, you know what to fix next.

The Goal Is Not More Tests. It Is a Stable Contract.

Vibe coding made implementation disposable. Any file can be regenerated in thirty seconds, and often is. Your users' requirements aren't disposable — login still has to work, checkout still has to work, after this prompt and the next forty.

So here's the decision. Vibe coded applications don't need a new testing philosophy. They need the old one run more often, because ai coding tools rewrite more of the app per change than a person would, and the blast radius lands somewhere you weren't looking. Pick the three to five journeys that decide whether your app works, define the expected outcome of each, record them once, and rerun them every time an ai assistant touches the codebase. That suite is a contract between the next change and the behavior nobody agreed to change. Keep its scope honest: it protects behavior, not safety. Nothing here makes your app bulletproof.

Your next eight moves:

• Start with the auth flow. Signup, login, session persistence and password reset gate everything else. If they break, nothing downstream matters.
• Write the outcome, not the click. An ai agent can produce a hundred plausible steps. Only you can say which end state proves the app works.
• Record instead of scripting if nobody wants to own a framework. The recommended tool is whichever one the person who knows the flows will actually maintain — a founder, a PM, a support lead.
• Rerun the whole smoke suite after every meaningful change ai produces, not just the feature you asked for. Green on the new thing tells you nothing about the old things.
• Move execution into CI once you have production apps. GitHub Actions on every merge, scheduled cloud runs against production, failures posted where someone will see them.
• Keep security in a separate lane. E2E tests can't tell you whether you write secure code. When ai optimizes a database call into string concatenation instead of parameterized queries, or logs sensitive data to the console, your suite still goes green. Security issues need code review, dependency scanning and a real security review — browser tests will not surface them.
• Don't delegate the decision of what to protect. Describing a flow to a model in natural language is fine. Letting it decide which flows matter is not — that judgment is the part of the job AI can't take from you.
• Give every failing test an owner. An ignored red test is worse than no test, because it teaches the team that red means nothing.

Let AI change the implementation. Make it prove that the behavior still works.

Shipping faster with AI means running regression checks more often. With BugBug, you can record the browser flows your product depends on and rerun them after every meaningful change, without maintaining a separate testing framework. In its February 2026 user survey, the most-cited benefit was time saved (28.1%), followed by not having to write code (18.8%); it holds 4.8/5 on G2. It runs on Chromium only.

FAQ

How do you test a vibe-coded app?

List the critical user journeys, define the expected outcome of each one, run a single manual pass to establish a baseline, then automate those flows as repeatable browser tests. Rerun them after every meaningful AI-generated change. Start with authentication, the core product action and any revenue-critical path, covering the core task and happy path first, then a key failure mode.

Can you test a vibe-coded app without coding?

Yes. Functional browser flows can be verified manually or captured with a test recorder, which handles selectors and waiting for you. More technical layers still benefit from engineering expertise: unit tests, API-level testing and security review generally require someone who can read and write code.

What should I test first in a vibe-coded app?

Authentication first, because everything else sits behind it. Then the core product action — the single reason someone uses your app. Then any revenue-critical flow such as checkout, upgrade or billing. Password reset and permission checks come next, since both fail silently and are rarely clicked manually.

How often should you test a vibe-coded app?

After every meaningful change and before every release. While it's a prototype, running the suite locally when you deploy is enough. Once real users depend on it, schedule smoke tests in the cloud or run them in CI/CD so failures block the deploy rather than reaching customers.

Does automated testing make a vibe-coded app production-ready?

No. It reduces functional regression risk, which is a large part of the problem but not all of it. Production readiness can additionally require production code checks such as security headers, dependency review, and secret handling, plus performance testing, monitoring and alerting, backups, accessibility checks and infrastructure hardening. A green suite means behavior held, not that the app is safe.

Happy (automated) testing!