What should be on a vibe coding QA checklist?

Seven groups of black-box checks: access and authorization on every new route, persistence after a hard reload, form and input handling including double-clicks, empty and error states on a brand-new account, money and irreversible actions, secrets that leaked into the client bundle, and real-device and cross-browser conditions. All of them can be run without reading the source code.

Can I run a vibe coding QA checklist if I am not technical?

Yes. Every check in this list is executed from the outside — through the browser, a second test account and the devtools network tab. You do not need to read the generated code, which is also why the checks stay valid the next time the AI rewrites that code.

Which checks should I run first if I have very little time?

Authorization first: log out and visit every new URL, then create a second account and try to reach the first account's records. Then hard-reload after a write to confirm data actually persisted. Then search the client bundle and network payloads for API keys. These three produce incidents rather than merely a bad experience.

How often should I run the checklist on a vibe-coded app?

After every meaningful AI edit, not just before a launch. AI tools rewrite adjacent code while implementing an unrelated request, so a feature that passed last week can regress without anyone touching it directly. Automating the mechanical groups is what makes that cadence realistic.

Why does the AI tool's preview pane hide these bugs?

Preview panes typically run with a single logged-in session, permissive settings and seeded data. That configuration conceals exactly the failures this checklist targets: missing authorization, unpersisted writes and unbuilt empty states. Run the checklist against a real build in a real browser.

Vibe Coding QA Checklist: 24 Checks Before You Ship

A vibe coding QA checklist is a short, repeatable list of checks you run on an AI-generated app before you ship it — ordered by blast radius, not by code structure. It exists because tools like Cursor, Bolt, Lovable, v0 and Replit produce code that compiles and renders correctly while quietly skipping the things nobody prompted for: authorization on a new endpoint, persistence after a reload, the empty state, the second click on a submit button. The checklist below is 24 checks in seven groups. You do not need to read the code to run any of them.

What is a vibe coding QA checklist, and why does AI-generated code need its own?

A traditional QA checklist assumes a developer wrote the code with the whole app in their head, so it focuses on regressions at the margins. AI-generated code inverts that assumption: the model sees your prompt and a slice of context — not the auth model you established four features ago, not the fact that your other forms all disable the submit button while in flight.

The result is a specific failure shape: the feature works when you demo it the way you described it, and breaks at the seams. So a vibe coding QA checklist is not a longer checklist — it is one pointed at seams, where generated code meets your existing app, your database, your auth, and a real user doing something you never typed into a prompt.

What is on the vibe coding QA checklist?

Run these on a real build in a real browser, not in the AI tool's preview pane. Preview panes often run with permissive settings and a single logged-in session, which hides exactly the failures below.

1. Access and authorization (4 checks)

Log out and visit every new URL. A page that should require a login and renders anyway is the single highest-severity bug an AI generator produces.
Create a second account and request the first account's data directly. Take an ID out of a URL or a network request while logged in as user A, then paste it while logged in as user B. Generated endpoints frequently check that you are logged in and not who you are.
Check the write path, not just the read path. Can user B edit or delete user A's record, even if they cannot see it in a list?
Try the admin route as a normal user. If a screen is hidden by conditional rendering only, it is not protected.

2. Persistence (3 checks)

Hard-reload after every write. AI-generated features often update local state and skip the server call, so the app looks correct until the page refreshes.
Open the same record in a second tab. This catches changes that only ever lived in one component's memory.
Verify the delete actually deleted. Reload and confirm the item is gone rather than just removed from the list on screen.

3. Forms and input (4 checks)

Submit the form empty. Then submit it with only whitespace.
Double-click every submit button. Duplicate records and double charges come from missing in-flight state, which prompts almost never mention.
Paste something long and something strange — a 5,000-character string, an emoji, an apostrophe in a name, a leading zero in a phone number.
Check what happens on a validation failure. Does the user's input survive, or does the form clear and make them start over?

4. Empty, loading and error states (4 checks)

Sign up as a brand-new user and walk every screen with zero data. Generated UIs are built against seeded or imagined data, so first-run screens are the most reliably broken part of a vibe-coded app.
Throttle your connection in devtools and watch for missing loading states, layout jumps and buttons that can be clicked twice while a request is pending.
Force a failure. Go offline mid-action, or block the request in devtools. An error that silently does nothing is worse than an error message.
Look for the spinner that never ends. A failed request with no error branch usually leaves one behind.

5. Money and irreversible actions (3 checks)

Confirm the amount is calculated on the server. If a price, total or quantity is computed in the browser and posted up, it can be edited.
Test the cancel and failure paths of any payment flow, not only the success path a prompt describes.
Confirm every destructive action is confirmed and scoped. A "delete" that removes more than the thing you clicked is a generated-code classic.

6. Secrets and what ships to the browser (3 checks)

Search your client bundle and network payloads for keys. Open devtools, look through Sources and the response bodies for key, secret, token, sk-. AI tools happily put an API key in front-end code when the prompt did not say where it should live.
Check that server-only environment variables are not prefixed for client exposure (the PUBLIC- or NEXT_PUBLIC-style prefixes in most frameworks).
Read the network tab on one page load. Any response returning whole user records, password hashes or internal fields is a leak even if the UI never shows them.

7. Real-world conditions (3 checks)

Open it on an actual phone. Not a resized desktop window — a phone, where the keyboard covers inputs and tap targets are smaller.
Check one browser you did not develop in, most usefully Safari.
Watch one person who has never seen the app use it without narration. This finds the class of bug no checklist can enumerate.

Which vibe coding QA checklist items matter most if you only have 30 minutes?

Do group 1, then the reload check from group 2, then the secrets scan from group 6. In that order. The logic is severity, not effort: an authorization hole exposes other people's data and cannot be walked back once it is live, a persistence bug destroys work your users did, and a leaked key can be exploited by anyone who views source. Everything else in the list produces a bad experience. Those three produce an incident.

With ten more minutes, add the double-click check and the fresh-account empty-state walk — the two cheapest checks with the highest hit rate on AI-generated code.

How is this different from a normal website QA checklist?

Area	Traditional QA checklist	Vibe coding QA checklist
Assumption	The author understood the whole system	The author saw a prompt and a slice of context
Auth	Spot-checked; the pattern is established	Re-verified on every new route and every new query
Focus	Regressions in existing features	Seams where generated code meets the existing app
Empty states	Usually already handled	Assume they were never built
Cadence	Per release	Per AI edit, because generators rewrite adjacent code
Who runs it	A QA person or the developer	Often a non-technical founder, from the outside

That last row is the real constraint. Most people shipping vibe-coded apps have no QA function, so a checklist only survives if every item runs without reading the source. Every check above is black-box for that reason — which also means it stays valid the next time the AI rewrites the implementation underneath it.

How do you run this checklist every time without it becoming a chore?

A manual checklist decays. You will run all 24 checks before your first launch, a handful before the second, and none by the fourth week. Three things keep it alive:

Write the checks down as your app's checks, not generic ones. Replace "check authorization" with the actual URLs and the two test accounts you use. Specific instructions get followed; abstract ones get skipped.
Automate the repeatable middle. The checks in groups 1 through 4 are mechanical and identical every time — exactly what an automated pass is for. AutoSim turns these flows into end-to-end tests that repair their own selectors when the AI renames a button, so a regenerated UI does not leave you with a wall of red tests to triage.
Get the unenumerable class from real behavior. Sims runs AI personas through your app the way real users would — the impatient one, the one with a long name, the one who clicks back mid-checkout — which finds the bugs no list predicts. When a user does hit something, Snap captures it as a right-click report with console, network and reproduction steps attached, so you are not debugging from "it's broken on my phone."

For the wider picture of how automated and human checks fit together, see our complete guide to AI QA. If you want the process rather than the list, how to QA a vibe-coded app walks through the workflow, and testing AI-generated code covers building durable tests around code you did not write.

Run your next pre-ship check in minutes

Start with the 24 checks above on your current build — the first group alone usually finds something. Then automate the mechanical parts so the checklist still happens in week four, not just week one.

Try Klavity free — point it at your vibe-coded app and see what the checklist would have caught.