How do you test something you vibe coded if you don't know how to code?

You test it the same way a QA engineer would before they ever look at a line of code: you use the thing on purpose, trying to break it, not just to admire it. That means running the happy path first, then deliberately doing the wrong things (empty fields, huge inputs, back button mid-flow, refreshing at the worst moment), then asking the AI to write and explain automated tests so the same checks run every time you change something, then putting it in front of a few real people and watching what they actually do. None of that requires reading a stack trace. It requires curiosity and a habit of trying to break your own work before a stranger does it for you, in public, on a Tuesday.

I'm Mahmoud Zalt, an independent senior AI systems architect. I've been building and shipping production software since 2010, which is 16 years now, and I founded Sista AI (sistava.com), where autonomous AI agents run in live production, not in a sandbox demo. Testing is the unglamorous half of my job and it's the part almost every vibe coding tutorial skips, because it doesn't produce a satisfying screen recording. This article is the version I wish existed when I started: no jargon, no assumption you can read code, just a concrete method for finding out what's broken before your users do.

Why testing is the part vibe coding quietly skips

When you describe a feature to an AI and it hands you working code in thirty seconds, it feels finished. It compiles, it runs, the button does the thing. That feeling is doing you a disservice. Working once, on your machine, with you clicking gently, is not the same as working reliably for a stranger who fat-fingers a field, loses their connection halfway through checkout, or opens your app on a five-year-old phone with a cracked screen.

There's real data behind that gap. Independent research into AI-generated code has repeatedly found security and correctness flaws in a large share of what these tools produce, with one widely cited 2025 industry study putting the figure at roughly 45 percent of AI-generated code containing some kind of security flaw. You don't need to memorize that number. You need to internalize what it implies: the AI optimizes for code that looks right and runs once, not code tried against the messy reality of real usage. Closing that gap is testing's entire job, and you can do it without writing a single line of code.

This is also exactly where "vibe coding with confidence" stops being a slogan and starts being a checklist. Confidence isn't a feeling you get from a clean demo. It's the result of having actually tried to break the thing and having a way to find out when it breaks anyway.

The manual exploratory testing checklist anyone can run

Exploratory testing has a real name in the QA world precisely because it doesn't need a script. You interact with the product, notice what happens, and let what you just saw decide what you try next. No coding, no tools, just deliberate curiosity. Here's the order that catches the most, fastest.

1. Walk the happy path first

Do the thing exactly as intended, start to finish, the way your best-case user would. Sign up, fill in the form correctly, submit, see the expected result. If this doesn't work cleanly, nothing past this point matters yet.

2. Then go looking for trouble

• Empty inputs. Submit forms with nothing in them, or with just spaces. Does it fail loudly and clearly, or silently do the wrong thing?
• Huge inputs. Paste a massive block of text into a field meant for a name. Upload a file far bigger than expected. Does the app cope, or does it just hang or crash?
• Wrong inputs. Letters in a phone number field, emojis in an email field, a negative number where a quantity is expected. Real users do this constantly, not maliciously, just carelessly.
• Going back and forward. Use the browser's back button mid-flow, then forward again. Does the app get confused about what step it's on, or double-submit something?
• Refreshing mid-action. Hit refresh in the middle of filling a form, or right after clicking submit, before the confirmation shows. Does it lose your data silently, or double-charge, or recover gracefully?
• Using it on mobile. Actually open it on your phone, not just a resized browser window. Tap targets, keyboard behavior, and layout break in ways desktop testing never reveals.

Keep this list next to you every time you ship a change, even a small one. It takes fifteen minutes and it catches the failures that make people quietly leave and never come back, the ones you'd never hear about otherwise.

Asking the AI to write tests for you, and to explain them

Manual testing catches what you remember to try. Automated tests catch what you'd forget to re-check the fifth time you change something. You don't have to write these yourself. You ask the AI to write them, the same way you asked it to write the feature.

Be specific in the request. "Write tests for this" gets you a handful of happy-path checks and nothing else, because that mirrors the same assumptions the AI made when it wrote the feature in the first place. Instead, ask something like: "Write tests for this signup form, including cases for an empty submission, an already-used email, a password that's too short, and the network request failing." Naming the failure cases yourself is what actually gets them covered.

Then do the one step almost nobody does: ask the AI to explain, in plain language, what each test actually checks and why it would fail. You're not trying to become a programmer. You're trying to understand what safety net you now have, and just as importantly, what it doesn't cover. A test suite that only checks the happy path will pass confidently right up until the moment a real user breaks something it never considered.

One honest caveat worth knowing: when the same AI that wrote your feature also writes the tests for it, both come from the same understanding of the problem, including the same blind spots. If the AI misunderstood what "valid" means for a field, its tests will happily confirm the wrong behavior. That's exactly why the manual exploratory pass above still matters even after you have automated tests. The two catch different mistakes.

The single best question for finding edge cases

Professional testers have a whole vocabulary for this (edge cases, boundary conditions, negative testing) but the version that actually works for a non-technical founder is one blunt question, asked out loud, about every screen and every button: what's the dumbest, laziest, most confused thing a real person could possibly do here?

Not a hypothetical power user doing something clever. A tired person on their phone in a moving car, half paying attention. They will:

• Click submit twice because the button didn't visibly respond the first time.
• Close the tab mid-payment and come back an hour later wondering if it went through.
• Type their email into the password field, then wonder why nothing works.
• Ignore every instruction and every placeholder text you carefully wrote.
• Use the app on a spotty train wifi connection that drops for three seconds at the worst moment.

Go through your product screen by screen and ask that question honestly for each one. Write down every answer, even the ones that feel unlikely. Then check, by hand, whether your app handles each one gracefully or falls over. This single habit finds more real bugs per minute than almost anything else on this list, because it forces you out of the mindset of the person who built the thing (who always uses it correctly) and into the mindset of the person who's actually going to use it.

Recruit a few real people, and watch them, don't just ask them

There's a well-known finding in usability research, first published by Jakob Nielsen in the 1990s, that testing with around five real users tends to surface roughly 85 percent of a product's usability problems. The exact number moves depending on which five people you get, but the underlying point holds up: you don't need a large study to find your biggest problems. You need a handful of real people and your full attention.

The critical detail is watch, don't just ask. If you hand someone your app and ask "does this make sense?", they'll usually say yes to be polite, then quietly struggle through it without telling you. Instead:

• Sit next to them (or screen-share) and ask them to complete a specific real task, like "sign up and book a slot for next Tuesday," while thinking out loud.
• Say nothing while they're stuck. The urge to jump in and explain is strong. Resist it, because their confusion is the data.
• Notice where they hesitate, re-read something twice, or click the wrong thing, even if they eventually recover. That hesitation is a real problem, even if they never mention it.
• Ask what they were expecting to happen right after something confused them, while it's still fresh, not in a survey a week later.

Five people recruited from your actual target audience, not five friends who already understand what you were going for, will show you more real problems in an hour than another week of testing it alone ever will.

Set up error tracking so you find out before your users complain

Manual testing and beta users catch a lot, but they can't watch your app forever. Once real people are using it day to day, you need something that's always watching and tells you the moment something breaks, ideally before someone emails you angry about it.

This is called error tracking, and it's simpler to set up than it sounds. You don't configure it by hand: you ask the AI to add it for you. A tool like Sentry has a free tier (roughly 5,000 errors a month on one account as of this writing) that's more than enough for a new product, and the setup is usually a single prompt: "add Sentry error tracking to this app and alert me by email when something fails." Lighter, self-hosted options exist too if you want to avoid another account entirely.

Once it's running, you get a dashboard, or better, an email or Slack alert, the moment a real user hits an error, showing you what broke and roughly where. That turns "a customer emailed saying the app is broken" (vague, already lost their trust) into "I got an alert ten minutes ago and already pushed a fix" (the difference between looking amateur and looking like you have your act together). For a solo builder, this one setup step does more for peace of mind than almost anything else on this list, because it means you stop finding out about problems from angry users and start finding out from your own system.

Putting the toolkit together before you ship

None of these five things replace each other. They catch different kinds of failure, and skipping one leaves a specific hole.

A reasonable rhythm: run the manual checklist and the automated tests before every meaningful change, run the edge-case pass and a round of real users before any public launch, and leave error tracking running permanently in the background. That's the whole system. None of it requires you to read code, and all of it is what separates a demo from something you can actually put your name on.

Frequently Asked Questions

Do I really need automated tests if I already test manually?

Yes, because manual testing only checks what you remember to try, and you won't remember to re-check everything every time you change something. Automated tests run the same checks in seconds, every time, so you catch it when a new feature quietly breaks an old one. Manual testing and automated tests catch different mistakes; you want both, not one instead of the other.

How much testing is actually enough before I launch?

Enough that you've walked the full happy path, deliberately tried to break every input on every screen, asked the AI for automated tests covering the failure cases you can think of, and watched at least three to five real people use it without your help. That's not exhaustive, nothing is, but it catches the overwhelming majority of what would otherwise become a support email or a lost customer.

Can I trust the AI's own explanation of what its tests check?

Mostly, but verify it against what you actually watched happen in manual testing. If the AI says a test checks that "invalid emails are rejected" but you just typed an invalid email into the live app and it went through anyway, trust what you saw, not what the explanation claims. Use the explanation to understand coverage, use your own hands to verify it's true.

What if I don't have any real users yet to test with?

Recruit five people who resemble your intended audience, even if they've never used your product: friends of friends, a relevant online community, people you find through a quick paid callout on social media. They don't need to be paying customers yet. What matters is that they're unfamiliar with how you intended the product to work, so their confusion is honest, not polite.

Is error tracking overkill for a small side project?

No, and it's the cheapest peace of mind here. A free-tier tool takes one prompt to set up, then runs silently until something breaks. The alternative is hearing about bugs from a frustrated user, or worse, never hearing about them because they just left.

What's the single highest-leverage thing on this list if I only have time for one?

The "dumbest thing a user could do" pass, done honestly, screen by screen. It costs almost nothing, requires no tools, and directly targets the exact gap between a demo that works for you and a product that survives contact with strangers.

The honest bottom line

Testing what you vibe coded doesn't require becoming a programmer. It requires a habit: try to break it before someone else does, ask the AI to explain what it's actually checking, and get real people in front of it before you trust your own read on it. None of it is glamorous, and it won't produce a satisfying demo clip. It's also the entire difference between a project that quietly breaks the first week and one you can keep building on. That's what vibe coding with confidence actually looks like in practice, not a feeling, a checklist you run before every ship.

This testing toolkit is one piece of a bigger picture. The full handbook walks through planning, setup, and building a vibe-coded product properly, and the first three chapters are free. Read the free handbook ->