Vibe testing is testing at the same level of abstraction as vibe coding: you describe what your app should do in plain English, and an AI agent opens a real browser, performs the flow like a user would, and verifies the behavior. No test scripts, no selectors, no assertion syntax. The term grew as the natural counterpart to vibe coding, Andrej Karpathy's name for building software by describing it to an AI, and it answers the question that vibe coding creates: if nobody wrote the code line by line, who writes the tests?
That is the definition. The rest of this post is what it looks like in practice, why it exists, and where its limits are.
A vibe test, concretely
A vibe test is a sentence or a short list of sentences about behavior:
- "A user can sign up with an email and password, then see their dashboard"
- "Adding an item to the cart updates the total price"
- "The payment form rejects expired credit cards"
- "Logged-out users get redirected to login when they open /settings"
An AI testing agent takes each description, drives a real browser through the flow, and reports pass or fail with evidence: screenshots, step logs, and what it saw when something broke. The description is the test. When the button moves or the markup changes, there is no selector to update, because there never was one; the agent finds "the payment form" the way a human tester would, by reading the page.
Compare that to the traditional version of the same test: a Playwright or Cypress spec with locators, waits, and assertions, written by someone who knows the framework and updated by that same someone every time the UI shifts.
Why the term exists at all
Vibe coding created a testing gap with numbers attached. We went through them in Vibe Coding Needs Vibe Testing: 41% of code is now AI-generated, a large share of the people shipping it are not career developers, and nearly half of AI-generated code carries security flaws. The people building this way cannot write Playwright specs, and the AI that generated the code writes tests that flatter its own assumptions.
Vibe testing closes the loop with the same interface that opened it. You described what to build in English; you describe what should work in English. The abstraction level matches on both sides, which is the whole idea.
Vibe testing vs adjacent things it gets confused with
- It is not AI-generated test scripts. Tools that generate Playwright code from a prompt still leave you owning code: reviewing it, maintaining it, fixing its selectors. Vibe testing has no script artifact at all; the plain-English plan is the maintained object. (Script generation has its place, and we ship it too, because scripts execute faster and cost less per run.)
- It is not record-and-replay. Recorders capture how you clicked once and replay it. A vibe test never encodes the how, only the what, so it survives UI changes that break recordings.
- It is not "the AI looked at it and it seems fine." A vibe test is still a test: defined expectations, a real browser execution, a pass-fail result, and evidence. The vibe is in the authoring, not in the rigor.
Where vibe testing is the right tool
- Vibe-coded and fast-moving apps, where the UI changes weekly and selector maintenance would eat the time the AI saved you.
- Founders, PMs, and support teams who know exactly what the app should do and have no intention of learning a test framework.
- Coverage breadth: when writing a test costs one sentence, you write twenty of them, and the long tail of flows actually gets covered.
- Acceptance-level confidence: "the signup journey works end to end" is exactly the altitude plain English describes well.
Where it is not
Honesty section. Agent-executed tests read the page at every step, so a run takes minutes, not the seconds a compiled script takes; at hundreds of runs per commit the economics favor scripts for the stable core flows. Pixel-exact visual regression and load testing are different disciplines. And a plain-English plan is only as good as its descriptions: "check the dashboard works" is a vibe, not a vibe test. Specific expectations ("shows the user's name and at least one chart") is what turns description into verification.
The mature setup we see: vibe tests for breadth and fast-changing surfaces, generated scripts for the stable high-frequency core, both from the same plain-English source. That is the create-once, run-both model our platform is built around.
How to try it in five minutes
Write three sentences about the three flows that would embarrass you if they broke tomorrow. Point an AI testing agent at your staging URL with those sentences. Read the report.
On Test-Lab that is the entire onboarding: describe the flows in the test plan editor, run them, and get screenshots and step-by-step evidence back in minutes. If the vibes were wrong about something, you will know exactly where.
Frequently asked questions
What does vibe testing mean?
Describing expected app behavior in plain English and having an AI agent verify it in a real browser, instead of writing test scripts. The term mirrors vibe coding: same natural-language interface, applied to verification instead of construction.
Is vibe testing reliable enough to replace real tests?
Vibe tests are real tests: defined expectations, real browser execution, evidence on failure. They replace hand-written E2E scripts for most behavioral coverage. Teams with high-frequency CI gates typically keep compiled scripts for the stable core because they run faster and cheaper per execution.
Do I need to know how to code to vibe test?
No. If you can describe what the app should do, you can write the test. That is the point.
Describe your first test in plain English and watch an agent run it. Try Test-Lab free.
Related reading:
- Vibe Coding Needs Vibe Testing - the argument, with the uncomfortable statistics
- Create your tests using your favorite AI agent - wiring vibe tests into Claude Code, Cursor, and friends
- No-code test automation - the wider category and how the approaches differ