Vibe coding best practices: 12 habits that keep a project alive

What are the best practices for vibe coding?

Most vibe-coded projects do not fail on day one. They fail around day four, when the app has twenty features, nothing is saved anywhere safe, and every new request breaks an old one. The habits below are aimed at that moment. They cost a few minutes each and they are what separates a project you can keep building from one you have to abandon.

If you need the definition first, see what is vibe coding. If you want the step-by-step walkthrough, see how to vibe code. This page is about the habits you repeat inside every session.

How do you write the spec and keep prompts small?

Habits 1 to 3 are one idea: decide what you want before the tool starts typing. A spec does not need to be formal. It needs to be specific enough that two different people would build roughly the same thing from it. The longer treatment is in the guide to spec-driven development; the short version is below.

Project: [name]

User: [one specific person and the moment they use this]

One workflow: [what they enter] -> [what they get back]

Screens: [list, maximum three]

Not included in version one: [accounts, payments, admin panel, anything else you are tempted to add]

Done means: [two or three things I can click or run to confirm it works]

Stack: [leave blank to let the tool choose, or name it]

Rules: build this in small steps. After each step, tell me how to run it and what to check. Do not change files unrelated to the step.

Then keep every later request the same size. A good change request names one thing, says where it lives, and says how you will check it.

Change: add a “Mark as done” button to each row on the task list page.

Behavior: clicking it moves the task to the Done section and keeps it after a page reload.

Do not change: the add-task form, the styles, or any other page.

When finished, tell me which files you changed and give me one way to check it works.

The last line matters. Asking for the list of changed files gives you a cheap review: if a request for one button touched eleven files, you have learned something before you ran anything.

How should you save your work while you vibe code?

Use Git, and commit every time the app is in a state you would be sad to lose. This is the single habit that people who have lost a project say they wish they had. You do not need to learn Git deeply. Most tools will run the commands if you ask: “commit everything with a message describing what works now.”

1. Start a repository on day one. One request: “Initialize a git repository and add a sensible .gitignore, including .env files.”
2. Commit when something works. Not when you are tired, not at the end of the day. After a feature works, commit.
3. Write messages you can read later. “Task list shows done items under a separate heading” beats “update”.
4. Put the repository somewhere that is not your laptop. A free account on a hosting service for repositories is enough, as long as the repository is private until you have checked it for secrets.
5. Try risky changes on a branch. Ask for “a new branch called experiment-search” and switch back if it goes badly.

Some tools also keep their own undo history. Claude Code documents a rewind menu, opened with /rewind or by pressing Esc twice on an empty prompt, that rolls the code, the conversation or both back to an earlier prompt (Claude Code best practices). The same documentation notes that checkpoints cover files edited through its own file tools, so a file changed only by a shell command may not be restored. Treat such features as a convenience and Git as the real safety net.

What goes in a rules file?

Most AI coding tools read a plain text file at the start of every session. Claude Code reads CLAUDE.md, and Cursor has its own rules (see the Cursor docs). The name differs; the job is the same: tell the model things it cannot guess. Claude Code's own guidance is to keep that file short (best practices). A long file gets skimmed, by people and models alike.

Put in facts that would otherwise cost you a correction each session: how to run the app, how to run the checks, and what never to touch.

# Project rules

## What this is
A [one-line description]. Built for [user].

## Commands
- Run the app: [command]
- Run the tests: [command]
- Check types and lint: [command]

## Conventions
- Keep changes small. One feature or fix per task.
- Do not add a new dependency without asking me first and saying why.
- Do not edit files under /migrations or /config unless I ask.

## Never
- Never write a secret, key or password into a file. Read it from environment variables.
- Never delete data or run destructive commands without asking.
- Never mark a task finished without running the tests and telling me the result.

## When you finish
List the files you changed and how I can check the result.

Edit it whenever you notice yourself repeating a correction. A rules file that grows from real annoyances beats one written in advance. For a deeper look at what a model sees on every turn, read context engineering.

What should you do when the AI keeps getting it wrong?

Every vibe coder meets the loop: you report a bug, the tool fixes it, a new bug appears, you report that, and the first bug returns. Each round adds failed attempts to the conversation, and the model reads all of them on every turn. More attempts do not help. Claude Code's documentation gives a rule worth copying for any tool: watch the first minute, press Esc the moment the tool drifts, and after two failed corrections run /clear and write a better prompt instead of a third correction (Claude Code best practices).

A reset only works if you carry over what you learned. Write the new prompt with everything the failed attempts taught you.

I am starting this task again with a clean slate.

Goal: [what should happen]

What happens instead: [exact behavior, plus the error message pasted in full]

Where it happens: [page, file or function if you know]

What I already tried that did not work:
- [attempt 1]
- [attempt 2]

First, explain in two or three sentences what you think is causing it. Do not change any code yet. Then propose the smallest fix and wait for my approval.

The instruction to explain before editing is the useful part. A wrong diagnosis is cheap to correct in words and expensive to correct after twelve files changed. Most tools have a plan or read-only mode for this; in Claude Code, plan mode makes it research and propose changes without editing your source (permission modes).

When should you read the code the AI wrote?

Pure vibe coding means you do not read it. Nobody can read everything, and reading all of it removes the speed advantage. The practical rule is to read in proportion to harm. Skip the parts where a mistake is cosmetic. Slow down where a mistake loses money, leaks data or locks users out.

If you cannot read code at all, you can still ask the tool to explain what it wrote, to list every place the app stores data, or to list every page a logged-out visitor can open. A second session with a fresh prompt asking it to review the first one’s work catches some problems, and the guide to AI code review covers that. It is not a guarantee, which is why the table puts payments with a human.

What does a well-run first session look like?

Here is an example session for a small tool: a page where you paste a list of meeting attendees and an hourly cost, and it shows what the meeting costs as the clock runs. The numbers are illustrative; the shape is what matters.

1. Minute 0 to 10: spec. Fill in the half-page spec. Done means: type three names and a rate, press Start, and see a number that rises each second.
2. Minute 10: setup. Ask for a repository, a .gitignore and the rules file. Commit: “project skeleton”.
3. Minute 15: plan. Ask for a plan with no edits. Approve it after removing a suggested login system, since the spec says no accounts.
4. Minute 25: first build. One prompt for the page with the form. Run it. Commit: “form accepts names and rate”.
5. Minute 40: the ticking cost. One prompt for the timer. It works but resets on refresh. That is a new request, not a patch to the old one.
6. Minute 55: edge cases. Try zero people, a very large rate, a blank name. One fix prompt for each failure, each followed by a commit.
7. Minute 70: stop. Version one does the one workflow. Write the next three ideas in a notes file and leave them there.

That session produced five commits, no unrelated changes and a clear stopping point. The same tool without these habits would also have produced a working demo at minute 25. The difference shows up on day four.

A tool like this already sits on the board as Meeting cost ticker.

What are the most common vibe coding mistakes?

If you do not have an idea yet, pick something small from the board of app ideas. Every idea there has a generated build prompt you can adapt as your spec. And if you build something and do not want to maintain it, post it so someone else can take it over.