What "vibe testing" actually means
Vibe testing is what happens when you describe a testing goal the way you'd describe it to a teammate, not the way you'd write a test script, and an agent takes it from there. "Make sure a new user can sign up, verify their email, and land on a working dashboard" is a vibe test. So is "check that the pricing page still works after this deploy." No selectors, no step-by-step script, no test plan written in advance. You say what should be true. The agent goes and finds out.
We've used this phrase since our earliest days
Vibe coding gave AI-assisted development a name: describe what you want, let a model write the code. We applied the same idea to testing early on, back in our first Show HN posts, and "vibe testing" is the name that stuck with us. We don't lead with it when describing Donobu today, mostly because the phrase undersells the part that actually matters to a team shipping production software: reliable, performant tests that utilize AI agents for resiliency and triaging, not just when they're first being written. But the search traffic for the term never left, so here's the real, complete answer.
What starts as a vibe becomes a regression suite you own
The plain-language goal is only the starting point. Here's what happens next:
Watch as closely as you want.
Run AUTONOMOUS and let the agent complete the goal on its own, or run SUPERVISED and approve each action before it executes. You can switch between the two mid-run.
Get a real test, not a transcript.
Once the agent completes the goal, Donobu exports a deterministic, self-healing Playwright test in TypeScript, built on the Donobu Playwright Extension. Your engineers review it the same way they'd review a test written by hand.
Replay it without the vibe.
From then on, DETERMINISTIC mode replays that test without further AI inference. Your CI pipeline runs a fixed, reviewed test, not a fresh AI decision every time.
Review it like any other code.
The exported test lands in your repo. Your engineers read it, diff it, and decide whether it's good enough to merge: the same review a hand-written test would get.
That's the bridge. A vibe is how the test starts. A Playwright file your team reviewed and owns is what it becomes.
Enterprise teams ask the obvious question
If your test suite starts as a plain-language guess, is it safe to run before you'd trust a release to it? Fair question, and two things make the answer yes. First, nothing runs unreviewed: the exported test is Playwright TypeScript, checked into your repo like any other code, so it goes through the same review your team already runs on everything else. Second, once it's reviewed, it's deterministic: DETERMINISTIC replay doesn't call a model again, so the test that passed review is the exact test that runs in CI, every time. If you'd rather have Donobu's own engineers own that review instead of doing it yourself, that's also available: forward-deployed engineers in test (FDETs) author suites and SDETs review every result as a managed service, the same model Donobu uses for localization and content QA.