The agent tells you the feature works, and it does, right up until a real user does the one thing you never thought to try. You cannot click through every path by hand on every change, and when the agent rewrites something next week, you will not remember what to re-check. This chapter gives you the net that catches a break before a user does.
8.1.1Tests are your safety net
A test is a small piece of code that runs part of your app and checks it did the right thing, without you clicking anything. It matters most precisely because the agent writes the code: a test is how both of you know a new change did not quietly break what already worked.
You cannot re-check everything by hand, and you will not want to. A machine re-checks every path on every change and never gets bored.
This is the one thing you invest in from day one, not something you grow into. You can deploy from your own machine, and you can add continuous integration, automatic test runs on every push, later.
Tests are the deliberate exception, so start on day one, even with a thin near-empty scaffold. Adding a test onto an existing habit is easy, while retrofitting tests into an untested app is brutal. That is the start-small-but-invest-early rule, applied to the one place skipping it hurts most.
8.1.2Cover the critical paths first
Do not try to test everything. Test what would hurt most if it broke. The critical paths are the few flows your app exists for: a user logs in, saves their work, pays.
Cover those first and you have protected the parts that lose customers when they fail. A checkout flow earns a test long before a settings toggle does.
8.1.3Let the agent write and run them
You do not hand-write these. You tell the agent the behavior to protect and it writes the test, then runs it on every change. A quick one for a single function, an end-to-end test (with a tool like Playwright) to drive the whole flow like a user:
test("a user can log in", async ({ page }) => {
await page.goto("/login");
await page.fill("#email", "[email protected]");
await page.fill("#password", "secret");
await page.click("text=Log in");
await expect(page).toHaveURL("/dashboard");
});
For the smaller pieces, a unit test checks one function on its own, run by a tool like Vitest. Add the test run to the checks the agent must pass before it says done.
8.1.4Green before you ship
Once the tests exist, they catch a regression the moment it appears: the suite was green, your last change turned it red, and now you know exactly what broke. That is what lets you keep changing a live app without holding your breath.
Tests are not the whole job. Before you ship, walk the real flow yourself once, on a phone, as a new user would, because some things (a confusing label, a broken layout) only a human notices.
This prompt sets up the safety net for your app:
Ready prompt
Act as a senior engineer adding tests to my app.
Read my spec and my must-have user stories first, and
take the critical paths from them, the flows that would
hurt most if they broke, instead of guessing at what
matters. Follow the conventions in my rules file so the
tests match the rest of the codebase.
Write a test for each: end-to-end for whole flows, unit
tests for tricky logic. Tell me which flows you covered
and why, and name any must-have story left uncovered.
Then add the test run to my rules file as a check that
must pass before you call any task done.
If you need the full reasoning behind this step, read
https://zalt.me/guides/vibe-coding/test/testing-and-qa
The critical flows to test:
Do this now: paste the prompt, let your agent cover your critical paths, and make a green test run part of every change from here on.
