Vibe coding: decide what needs to be tested

Last checked and updated: September 8, 2026. Editorial and source review; exercises below are authored practice, not reported benchmark runs.

A screen that looks finished can still lose data, calculate the wrong total, or fail on an empty input. Before asking an agent to build, decide what you want to learn from the prototype and what must work before someone uses it.

Your deliverable here is a one-page brief. No installation is needed yet.

Pick one job, one input, one result

Use this practice project through the next two lessons: a local page that turns a small list of sample expenses into a total by category. Use fictional amounts. Leave accounts, payments, uploads, and public deployment out of the first version.

The useful question is: “Can I see where these sample expenses went?” That is specific enough to build and check.

If you already have a project, choose one equally narrow flow. “Build a finance platform” is too broad for a first task. “Group these four sample expenses by category” is small enough to inspect.

Decide how much checking the work needs

Situation	Useful check
Exploring two layouts with fixed sample text	Open both layouts at phone and desktop widths and compare whether the information is easy to find.
Calculating totals from sample data	Recalculate the expected values independently and check the program against them.
Renaming a folder of real files	Preview the exact renames and try them on copies before changing the originals.
Building something people will rely on	Check the full user flow, failure cases, data handling, and recovery appropriate to that use.

How long the code lives is only one factor. A one-off script can destroy files in seconds. A throwaway prototype should still have limits appropriate to what it can touch.

Write the brief before adding features

Save this as SPEC.md, a plain text file written in Markdown:

Purpose: Show totals by category for a small set of fictional expenses.
User: Me, inspecting a local prototype.
Input: Four fixed sample rows, each with category and amount.
Output: A visible total for each category and a grand total.
Scope: One local page. No login, payment, upload, network calls, or deployment.
Checks:
- food 12.50 + food 7.50 gives food 20.00.
- travel 5.00 gives travel 5.00.
- supplies 10.00 gives supplies 10.00.
- Grand total is 35.00.
- Empty input shows a useful empty state and total 0.00.
- A non-numeric amount shows an error; it is not silently counted as zero.

These are acceptance checks: observable conditions for deciding whether the result is ready for its intended use. You can give an agent this file and compare its work against it.

Keep exploration separate from release decisions

It is reasonable to ask an agent for several visual options before you know what you want. Use fixed sample data and keep that experiment local. Once you choose an option, bring the checks back into the build.

A passing test is evidence about what the test covers. It is not a promise that every untested case works. For the expense example, inspect the page as well as the calculation: can a person find the grand total, read it on a phone, and understand an error?

Anthropic’s Claude Code guidance recommends giving the agent an executable check and reviewing the resulting evidence. The principle also applies when you use another coding tool.

Your brief is ready when…

Someone else can read it and tell you the expected result without asking the AI. For this project, that means they can name the category totals, the grand total, and the required behavior for missing or invalid input.

If the brief still says “handle errors gracefully,” replace that phrase with an example of the error and what the person should see.

Next, set up a coding-agent session. Then build the expense summary and check it. You do not need to pick multiple models, install a team of agents, or buy hosting to complete the project.