How to vibe code better: 12 habits that stop AI from breaking your project

The people who get good results from AI coding tools aren’t better at prompting. They’re better at checking. They work in small steps, save a version before every request, and read what the AI changed before accepting it. These twelve habits are the ones I rely on, roughly in the order I’d teach them.

If the term is new to you, start with what vibe coding is.

Before you ask

1. Save a version before every prompt

This is the habit that makes all the others safe. Before you ask the AI for anything, commit your work to Git. If the change goes badly, you go back in ten seconds. Without a commit, a bad change can cost your whole evening.

If Git is new to you, it’s worth an hour of your time. No other tool gives you a real undo button for AI.

2. Ask for one thing at a time

“Add a logout button” is a good request. “Add logout, fix the layout and clean up the code” is three requests wearing a coat. When something breaks, you won’t know which one did it.

3. Say what must not change

AI assistants are eager. Tell them the boundaries: “Only touch the navbar file. Don’t change how login works.” It feels fussy. It saves hours.

4. Write the rules down once

If you keep repeating the same instructions, put them in a file the AI reads at the start of every session, usually called CLAUDE.md or AGENTS.md. Mine say things like “ask me before changing the architecture” and “never claim it works without running it”. I wrote a full guide to writing a CLAUDE.md.

After the AI answers

5. Read the file list first

Before you read a single line of code, look at which files changed. If you asked for a button and fourteen files changed, something happened that you didn’t ask for. A one-button change should touch one or two files.

6. Ask “what did you change that I didn’t ask for?”

This is my favourite question. The AI will usually tell you honestly: it rewrote a function, renamed some settings, removed a check. It just never volunteers it. AI rarely breaks an app by writing bad code. It breaks it by writing extra code.

7. Run it yourself

“All done, everything works” is a sentence, not a test. Open the app. Click the thing. Try the wrong password, the empty form, the back button.

8. Make the AI check its own work

Ask it to run the project, open it in a browser, and look at the console for errors before it reports back. In my own projects this is a written rule. A handoff note on one of my games says, in plain words, to never claim something works without running it in the browser first.

As the project grows

9. Work in phases with a stop at the end

For anything bigger than an afternoon, split the work into phases. At the end of each one: run it, take screenshots, summarise in a few lines, and stop. I built TARA, a 3D driving game, this way. Each phase ended with the AI waiting for my “go”. That pause is where I catch things.

10. Keep a handoff file

AI sessions forget. A short file that records what exists, what was decided and what comes next lets a fresh session pick up where the last one stopped. Update it at the end of every phase. It’s also the best documentation you’ll ever have, because it gets written while the decisions are fresh.

11. Add automated checks early

You don’t need a big test suite. One check that the app starts and the main screen loads with no errors will catch a surprising share of breakages. Ask the AI to write it, then ask it to run that check after every change.

12. Know what not to vibe

Some things deserve a slower, more careful approach or a second opinion from an experienced engineer:

• logins, passwords and permissions
• payments and anything with real money
• other people’s personal data
• anything you can’t easily undo, like deleting data or sending emails

The checklist version

Before you accept any change from an AI:

1. Did I commit first?
2. Does the file list match what I asked for?
3. Did I ask what else it changed?
4. Did I run it myself?

A bad change with a commit behind it costs you ten seconds. Without one, it costs your weekend.

Why this matters more than the model

A better prompt and a bigger model both help a little. A smarter model still does more than you asked, just more convincingly. Checking is the part that stays useful no matter which tool you use, and it’s a skill that transfers: the same four questions work in Claude Code, Cursor, Copilot or whatever comes next.

If you want to see these habits applied to a real pipeline, read how I ship projects solo with AI.