How to Test a Vibe-Coded App Before You Ship It
AI coding agents changed how fast software gets written. They did not change how software fails. If anything, they made one failure mode more common: an agent finishes a feature, reports success, and quietly breaks something that worked yesterday.
Testing a vibe-coded app is less about writing more unit tests and more about proving, from the outside, that the product still does what users need. Here is a plan that fits the way these apps are built.
Why AI-written code needs outside-in testing
Agents optimise for the task in front of them. They rarely know which other flows depend on the code they just changed, and unit tests they write for their own code tend to confirm their own assumptions. A green unit suite after an agent session tells you very little about whether checkout still works.
End-to-end tests that drive the real app in a browser are the antidote. They do not care how the code is structured; they only check whether a person can still complete the journey.
Step 1: list the five journeys that pay the bills
Write down the flows that would cost you users or money if they broke: usually sign-up, sign-in, the core action, upgrade or payment, and one settings flow. Ignore everything else for now. Five solid journey tests beat fifty shallow ones.
Step 2: run them after every agent session
The risk window is the moment an agent marks work as done. Run the journey suite on every pull request, and treat a failure as a blocker. If you use an agent locally, run the suite before you push, the same way you would run a linter.
Step 3: check the edges agents skip
Agents handle the happy path well and the edges poorly. Add checks for empty states, expired sessions, slow networks, permission boundaries (can user A see user B’s data?) and double submissions. Authorization bugs are the most common serious issue in AI-generated backends, and they are invisible in a demo.
Step 4: keep tests that heal, not tests that rot
Vibe-coded UIs change constantly, so hand-written selectors break weekly. Use role-based locators and self-healing tests so a renamed button does not turn into a red build. Review healed changes rather than accepting them blindly; a test that heals onto the wrong element hides a real bug.
A shortcut
You can generate the journey suite instead of writing it. With QAShift you paste your app URL, get Playwright tests for your main journeys in minutes, and run them free in your CI. When the app starts making real money, a QAShift engineer can take over the suite and the triage.