Tests for vibe coders

Nine prompts that put protection against breakage into your project while you work with an AI agent. They cover all six levels of checks — from the linter to server-side checks. You don't write a single line of code: copy a prompt, the agent does the work, you look at the result.

---

Why you need this

While a project is small, you can hold it all in your head: add a feature, check it, move on. But along with the new feature the agent touches old code too — and it sees the project in fragments, finding some connections and missing others. The more files and dependencies you have, the higher the chance a fresh edit breaks something that already worked.

The real risk of vibe coding isn't even that the model makes mistakes. It's that you have no way of knowing whether it did. You're not going to read the code — there's a lot of it and it isn't yours. You're not going to click through the whole app after every small change either. What usually gets checked is whatever was just added: your own account, a couple of screens, one scenario.

Which is why breakage like this gets found late, and not by you. A different user, different data, the screen next door — and the bug lives there for weeks until someone writes in about it.

Automated tests close exactly that gap. They remember what is supposed to work and check it for you after every change — as many times as needed, with you doing nothing.

---

What a test actually is

A test is a recorded check that runs itself. You lock it in once — "given this input, the result must be that" — and from then on you just run one command after every change. Something broke, and you get pointed at the exact spot.

There are three upsides, and the third matters more than the first two:

• No clicking through the whole app by hand after every edit.
• A calm release — green tests mean what you locked in still works.
• Feedback for the agent itself. Without tests it works blind: writes something, says "done", and you're the one who finds the errors. With tests it runs the checks itself and fixes the red before it reports back.

Tests earn their place. The measure isn't "how many can I generate", it's "how many am I willing to maintain".

---

What you can test: six levels

Level	What it checks	Cost
1. One command for everything	linter and types: formatting and the dumbest errors. Doesn't touch logic	instant, the cheapest check there is
2. Single-function test	one function in isolation — feed it data, look at the output	seconds
3. App responses	whole requests: is the user authorized, did we hand out someone else's data, what ended up in the list	most value for the least time
4. With a test database	spin up a separate database and see what actually gets written and returned	medium
5. Browser test (E2E)	the test opens the app and clicks for you	slowest, but closest to a real user
6. Server-side checks	GitHub runs everything after each push. Red tests — the branch doesn't get merged	set up once

The levels catch different things, and that's the whole point. A broken owner filter gets caught by level three — even though the response code stays perfectly normal and the server answers as if nothing happened. A broken rendering, on the other hand, is only caught by a browser test: there the server is completely healthy, the human just doesn't see the result.

---

How to use the pack

Don't open all nine files in order and try to guess which one is yours.

00. Diagnosis          → the agent inspects the project and hands you your route
01. One command        → folds the fast checks into one, installs a linter if missing
02. Rules for the agent → a task isn't done without the command output
03. Database fuse      → tests can never reach the production database
04. Logic tests        → 3–5 tests for wherever something gets calculated
05. App responses      → permissions, access, response contents ← most value
06. Browser test       → one test that clicks instead of you
07. Browser for agent  → the agent can see the page, further tests get cheap
08. Server-side checks → a run after every push

Start with one file only

Open 00-диагностика.md, copy the whole prompt and hand it to the agent inside your project. It does three things:

1. inspects the project — the stack, whether there's a database, payments, background jobs;
2. finds the places where things can break silently — with files and line numbers;
3. tells you which of the next eight steps you actually need, and in what order.

After that you only open the files it named.

The тесты/ folder — don't delete it

You'll get a short summary in the chat; everything else goes into two files:

File	What's inside
тесты/контекст.md	stack, commands, database, key actions, what must not break, your route
тесты/риски.md	the full list of places where things can break silently

You don't need to attach them to prompts by hand — every following prompt starts with the line "read тесты/контекст.md".

---

If your project has something heavier

The дополнительно/ folder covers special cases that didn't fit into the main route:

• payments — the key point: a payment is not a button, it's a notification to your server
• telegram bot — events straight into the handler, no network and no token
• background jobs — queues and anything that doesn't happen immediately
• AI responses — if a model talks to your users
• external services — email, storage, third-party APIs
• tests with a database — when you can't verify it without a real one
• screenshot tests — you probably don't need these yet

You don't have to pick from this list yourself: the diagnosis tells you outright what's yours and what isn't.

---

The playground — so you can see red

There's a separate file, демо-приложение.md. A master prompt builds a small app plus a script that breaks it in two modes — one on the server, one in the interface.

It exists for exactly one reason: to let you watch a check go red. On your own project you'll set up tests and see green — and you'll never learn whether they catch anything at all. And you're not going to break your own app on purpose, and rightly so.

---

These prompts were validated on a live app

Not just written: a project was built from scratch with the master prompt and taken through every prompt in the pack.

When the owner filter was broken — the exact failure the video opens with — the tests from prompt five went red. The response-code check missed it entirely: the server kept answering as usual. That single case is why the whole pack exists.

Prompts 07 and 08 couldn't be validated on the bench — they need connected agent tools and a real repository.

---

Key principles

• A test is a commitment, not an asset. Writing one is nearly free; you'll be fixing it every time it goes red.
• A bad test suite isn't a big one — it's a slow, lying one. Have hundreds of fast checks if you like; the count only matters for browser tests.
• Green tests don't mean a good product. They mean what you locked in still works. But that's exactly what vibe coding usually lacks.
• No tool names before step six — on purpose. Everyone's stack is different; the agent picks its own.

Grab the prompts and watch the video — the whole route is shown there on a live app.