Do Vibe coders actually test things?

by

If the agent writes the code… who’s actually testing it?

Do you still go through edge cases and user scenarios manually, or are you also delegating “please break my app” to another agent now?

Has testing become more systematic and automated in your workflow, or you just moving faster with fewer guardrails (and let users break things) ?

Also, do you test any of your endpoints?

Preparing for a launch soon and looking to connect with people that love breaking APIs and automate flows.

you can follow to stay in touch with the launch. Also looking to connect with folks that launch cool stuff in the dev productivity space, AI and tolling overall. With my team we often do reviews of our favorite new products (from product hunt and from other places) internally so happy to check out yours!

Linkedin:

Nikolas

284 views

Add a comment

Replies

Best

most dont, and the ones who do usually only check the happy path. the agent writes code that runs, you watch it run, and you quietly treat "runs" as "correct". theyre not the same thing.

what works for me is deciding the edge cases before i prompt, then checking the output against that list. if you let the same agent write the code and decide what to test, youre asking it to grade its own homework. the spec has to come from you - or from a second agent thats given the requirements but never sees the code.

From my experience, letting a few real users join the Beta is the best test out there. They will break everything that is breakable... and a few things you thought were mathematically impossible to break! The less "tech-savvy" your beta users are, the faster you will see exactly where they get stuck in your interface. 

As a solo full-stack engineer, I try to balance automated guardrails with real-world chaos. I’m currently building Trackly (a B2B compliance SaaS) and honestly, my favorite "vibe test" was generating a unique QR code for my dog Shaman’s collar to track his vaccinations schedule. If a furry office supervisor can't break the flow, there's hope for the enterprise clients! 🐶

I built a feature where users type /ai, describe a tool, and AI writes a component that runs inside their document. So I had to think hard about testing AI output. My approach: I don't trust the agent's output directly, the sandbox does. iframe with no same-origin, strict CSP, connect-src none. If the code misbehaves, it misbehaves in isolation. Testing AI output is more about containing failure than preventing it.

Testing has become a serious part of my role as solo founder and developer. We still have a ways to go before I can delegate to a Claude Code testing agent for user ui testing.

If anyone has any harnesses that could help with this, it is the final frontier for Claude Code development.

I probably test more now than before.

The AI can write code incredibly fast, which also means it can introduce bugs incredibly fast 😅

I usually let it generate tests, but I still go through the key user flows myself. The biggest issues I’ve seen aren’t in individual functions—they’re in how everything works together once real users start clicking around.

If the agent writes the code, the honest answer is usually nobody is testing it, which is exactly the gap. I still go through edge cases by hand, because asking a second agent to break it tends to share the same blind spots as the first. The cheapest insurance is making the agent show you what it changed instead of just saying done.

The best vibe-coding workflow I’ve seen is agent builds, human verifies, tests lock it in. You can absolutely ask another agent to break the app, but you still need real user paths and edge cases. Otherwise you’re just generating confidence, not quality.

I have my first vibe coded app technically finished, but I am still testing. I have a background as a developer, and I had the agents build using a Test Driven Development approach, so in theory I have unit tests for a lot of my functionality. I then have done multiple rounds of my happy path and a few variations on my own. Trust but verify.

We've started using agents to test agents, which sounds recursive but works well for unit and integration tests. The limiting factor isn't the test-writing — it's when tests need to hit real services.

An agent writing tests against a live API needs credentials. An agent testing an email flow needs a real inbox. An agent end-to-end testing anything with a login wall needs to handle 2FA. These are all solvable, but each one requires figuring out how to hand off secrets safely — which most people are still doing awkwardly (env vars, hardcoded test accounts, etc.).

For pure API endpoints we've gone basically fully automated. For anything requiring real-world identity, we're still more manual than we'd like.

Have you found a clean way to give test agents safe access to external services, or are you keeping those tests scoped to mocks?

I'm not quite sure what defines a vibe coder now and if could I be considered one, since I've been a professional developer long before AI, but currently I almost never even look at the code, some maybe? As for testing, I try to test everything and guide agents to create test tools that both I and an agent can use. Sometimes I ask agent to create integration tests before implementing an actual feature, so that it won't write tests retroactively based on hacks it might have added during development.