Vibe Coding: 9 Rules That Get You Exactly What You Asked For

Last night I gave a talk to our local user group on vibe coding — building software by describing what you want in plain English and letting an AI write the code. The room was a mix: some people had never opened a terminal, some do this every day. Everyone left with the same nine rules. Here they are.

What vibe coding actually is

You describe what you want. The AI writes the code. You check the result. Then you describe the next change, and the next. The term comes from Andrej Karpathy — one of the people who built ChatGPT — back in February 2025.

You never have to read the code. But you do have to check that what came out is what you asked for. And that’s the whole game, because of one shift:

Writing code used to be the slow part. Now the writing is nearly free — and checking it is the part that takes time.

Every rule below does one of two things: helps the AI guess less less guessing or makes the result easier to check easier checking. That’s the spine.

First, which kind of project?

There are two ways to vibe code, and they have different rules:

• Toss it — a weekend project, a prototype, a quick tool for yourself. Don’t read the code; just look at whether it works. Being wrong costs nothing.
• Keep it — something real. Customers, coworkers, money, data. You still describe and let it build, but you own the result.

Same tools, different discipline. Nearly every AI-coding horror story you’ve read is Toss it habits applied to a Keep it project. The nine rules are what make Keep it safe.

The nine rules

Every conversation otherwise starts from zero, and you re-explain what the project is, how to run it, and what not to touch. Instead, write one short file in your project folder — CLAUDE.md, AGENTS.md, or .cursorrules, whichever your tool reads:

(you re-explain the whole project, every single chat)

## What this is
A booking site for my dog-grooming business.
## How to run it
npm run dev · npm test
## Rules
Never change the /payments folder.
Don't add packages without asking me.

Twenty minutes, once. It pays back in every conversation forever. This isn’t “prompt engineering” — it’s a README the AI happens to read.

Ask it to “fix the login problem” and it may fix login — then also rewrite three other pages it thought looked messy. Draw the fence first:

fix the login problem

Fix the login problem.
Only change files in the login folder.
Don't touch payments, or anything else.
Show me the change before you make it.

If you don’t say where the edges are, it decides for you.

Say “add a booking calendar” and a wall of code appears — and you learn what it thought you meant by reading all of it. Ask for the plan instead:

add a booking calendar

Before you build anything:
1. What are we making, in one sentence?
2. Which parts of the project are involved?
3. How will we know it worked?
Wait for my OK.

Most bad results are a misunderstanding, not a mistake. Catch it while it’s still a sentence — you fix a paragraph instead of a pile of code.

If you dictate every step, you did all the thinking and it just typed — you gained nothing. Say what good looks like and let it figure out how:

make a function called sortCustomers,
use a loop, put it in the helpers file

Show customers with the most recent
activity first.
Rules:
- Don't install anything new
- Everything that works today still works
You decide how.

If you’re dictating every step, it’s slower than doing it yourself.

“Build the whole checkout” gives you hundreds of changes at once — and when something’s broken, you can’t tell where. Go in small steps:

build the whole checkout

We'll do this in 4 steps. Step 1 only:
the shopping cart. Stop there and
show me.

A saved copy is a save point — like in a video game. When it goes sideways (and it will), you lose ten minutes, not a day. In a terminal that’s a git commit; browser tools have version history and checkpoints.

“It’s not working, why?” makes the AI guess — confidently, and often wrong. It can’t see your screen. Paste the real error:

it's not working, why?

Here's the exact error I'm seeing:
Error: Cannot read ’total’ —
cart is empty (checkout.js:14)
Start from this. Don’t guess.

The exact message — or a screenshot, or letting the tool run the thing itself — is worth more than your best description of it.

“No, that’s wrong.” → “Still wrong.” → “Now it’s worse.” Every wrong turn stays in the conversation, and the AI keeps building on them. Three strikes, new conversation:

No, that's wrong.
Still wrong.
Now it's worse. (round five...)

[new chat]
What I want: 
What I tried:  — failed
because 
Rules: <...>

A fresh start with what you learned beats a tenth correction.

“Looks fine → Accept → discover the problem when a customer does” is the trap. Generated code is very good at looking fine. Ask four questions, every single time:

glance at it, looks fine, Accept

1. Did it change anything I
   didn't ask for?
2. Does it handle bad input,
   or only the happy path?
3. Did it add anything new?
4. Do I understand what it did?

“Looks fine” is the whole problem.

If you’ve typed the same three-paragraph instruction six times this week, save it once and reuse it with one word — a snippet, a saved command, a file in the project:

(retyping the same instruction, again)

# .claude/commands/check.md
Look at what just changed. For each:
- Does it follow CLAUDE.md?
- Does it handle bad input?
- Did it add anything new?
Then just type:  /check

A skill is the same idea one step up: a folder with the instructions and the files the task needs, loaded on its own when it’s relevant.

The prompt that gets you exactly what you asked for

Rules 2, 3, 4, and 8 fold into one fill-in-the-blank you can use today:

GOAL
  <what we're making, one sentence>

DONE LOOKS LIKE
  - <check 1>   - <check 2>   - <check 3>

RULES
  - <what not to touch>   - <nothing new to install>
  - <keep it to one file / one page>

PLAN FIRST
  Tell me your plan and how you'll test it. Wait for my OK.

When to close the laptop

Good fit: new projects, quick tools, first drafts, boilerplate, tests, “explain what this does,” “make this page nicer.”

Bad fit: the delicate core of something you know cold; anything where you can’t tell if the answer is right; money, passwords, personal data; and “I’ll understand it later.”

If you can’t check it, you can’t ship it. That’s not an AI rule. That’s just the rule.

Three things for Monday morning

1. Write the memory file. Twenty minutes. Today’s version, not the perfect one.
2. Add “plan first, wait for my OK” to your next real request. One line.
3. Save a copy before you ask for anything big. So you always have a save point.

Those three change the most for the least effort.

A quick note on where I’m coming from: I build Webend Creator, a browser-based platform where you describe what you want and get working software — so these rules aren’t theory for me, they’re how I work every day. If you want to try the “describe and see” lane without installing anything, that’s a fine place to start.

Got a prompt that disappointed you? Run it through the four-part template above — Goal, Done looks like, Rules, Plan first — and watch what changes.