To test a vibe coded app, pick the handful of flows that would hurt most if they broke, such as sign-up, login, payment and saving data, and write one end-to-end (E2E) test for each as steps a person would follow. Run those tests against every preview deployment before you merge. Then add a test each time a bug reaches users.
Vibe coding moves the risk into code nobody read
Vibe coding means building an app mostly by prompting an AI model and accepting what it produces, with little reading of the code. It is a fast way to get something working. It also means nobody on the team holds a full picture of how the code behaves.
Many of the people building this way are new to software. GitHub reports that 80% of new developers on GitHub use Copilot in their first week [GitHub]. That is a lot of people shipping code they did not write line by line.
The practical risk is regression. You ask for a new feature, and the model quietly changes something that already worked. The login page still renders, but the session is no longer saved. The checkout button still appears, but the order is never written. You find out from a user.
List the flows that must never break
Do not try to test everything. Start with a list. Write down the flows where a failure would cost you money, lose user data or break trust. For most apps that list is short:
- Sign up and log in
- The main action your app exists for, such as creating a project or booking a slot
- Payment, if you take money
- Saving and loading user data
- Anything that sends email or notifications to users
Each item becomes one test. That is your first suite. It is small on purpose. A small suite that runs on every change is worth more than a large one that nobody runs. The post on how many E2E tests you need explains why to count flows, not tests.
Write each flow as steps a person would follow
Describe each test the way you would explain the flow to a new teammate. What they click, what they type, what they should see at the end. This style has a real advantage for a vibe coded app: you can read and check it without reading the code.
1name: New user signs up and sees the dashboard2url: https://staging.example.com3tags: [auth, smoke]4env:5 EMAIL: ${TEST_EMAIL}6 PASSWORD: ${TEST_PASSWORD}7steps:8 - Click "Sign up"9 - Enter EMAIL in the email field10 - Enter PASSWORD in the password field11 - Click "Create account"12 - assert: The dashboard shows a welcome messageEnd each test with an assertion about the outcome, not about the page layout. "The dashboard shows a welcome message" survives a redesign. "The third div has a green border" does not.
Run the tests on every preview deployment
Many hosting platforms build a copy of your app for each branch. By default, Vercel creates a preview deployment when you push a commit to a branch that is not your production branch, or create a pull request on GitHub, GitLab, Bitbucket, or Origin [Vercel]. That preview is the right place to run your tests: it is the exact code you are about to ship, and it does not touch production data.
Run the suite in continuous integration (CI) on each pull request and do not merge while it is red. See E2E tests on Vercel preview deployments for the wiring.
Expect the interface to keep changing
A vibe coded app changes shape often, because each prompt can regenerate parts of the page. Tests that find elements by their position or by generated class names will break every week. Tests that find elements the way a user does, by label, role or visible text, break far less.
If you write tests in code, use your framework's user-facing locators. In Playwright, locators are the central piece of Playwright's auto-waiting and retry-ability [Microsoft (Playwright)], so they are worth learning well. If you write tests as plain steps, the same principle applies: describe what the user sees.
Know what these tests will not catch
A passing suite shows that the flows you wrote still work. It does not show that the app is secure, accessible or free of bugs. Vibe coded apps often need a separate look at authentication, data access rules and secrets in the code. Plan for exploratory testing and a security review before you handle real user data. Our limits page is explicit about what automated tests leave out.
How AI Testing Platform fits
AI Testing Platform runs tests written as plain-English steps in YAML (plain-text configuration) files, so you can check a flow without reading the app's code. One command runs the suite in CI on hosted browsers and reports a check on the pull request. Start with how it works or the CLI docs.