Do Vibe coders actually test things?
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: https://www.linkedin.com/in/nikolasdimitroulakis/
Nikolas
Replies
I let AI write the code, but I still don't trust it enough to test itself 😄
Real users are still the best QA team on the planet.
I vibe coded cepho, and i can promiss you, i have never in my life, tested anything more then cepho has been tested.
I am building this from the opposite direction with Project Telos: not another generator, but the receipt layer after an agent run. The test I care about is whether a reviewer can replay the important facts later: original task, files inspected, side effects proposed, approvals granted, commands run, diffs created, tests/evals run, and claims the agent could not verify.
For vibe-coded work, the missing primitive feels less like "another test agent" and more like a durable verdict: what passed, what failed, what changed since the last run, and what still needs a human to check.
Yes certainly. Test and test aggressively! vibe-coded apps are not perfect. They have a lot of bugs, UX issues, security and functional gaps. You should also put yourself in the user's shoes and I am sure you will find a lot of things to fix. While Claude, for example, offers audits for security checks, there are gaps and you need a good pair of eyes to find and fix them, especially race conditions that open up security holes in your app.
most of the replies here are about ui and flows, but you slipped in the real one at the end: endpoints. clicking through the ui only tests the paths the ui offers, while the api will take a request the ui would never send, someone else's id in the params or a field the form doesn't expose. the agent writes the route so the happy path works and stubs the auth check to match. what caught the most for me was hitting my own endpoints with a second account's token and seeing what came back.
i do delegate the breaking, and today was the clearest case ive had of it paying. i had two plans i was reasonably confident in, so i handed both to a separate agent whose only instruction was to kill them and to default to rejecting. it killed both, and one of the reasons it gave was something id have found in a week, or never. the thing that makes it work is that the attacker cant be the author. same context and it just agrees with itself in a slightly different voice. it needs a separate run, a brief that says default to refuting, and no access to why i liked the idea in the first place. on endpoints im less disciplined than i should be. what i actually do is keep a small set of calls with known answers and rerun those, so a wrong response is visible rather than merely plausible. its not real coverage, its a canary, but it has caught more than the tests i wrote and then never ran.
Yes, and the agent writes them.
Playwright, one spec file per feature. When I add something, the agent writes the cases for it. The task manager is at 131 spec files and 275 tests now. Writing them takes seconds, and they come out more exact than anything I'd type by hand: no typos, nothing quietly skipped because it was boring to write.
What still needs me is deciding which scenarios go in. The agent will test what the feature does all day. It doesn't know which failures are expensive.