How do you start vibe coding without shipping broken code?

What do you need before your first session?

Four things, none of them expensive:

1. A coding assistant. Either a chat assistant you paste code from, or a coding agent: a tool that reads your files, runs commands and edits code itself, such as Claude Code, Codex, GitHub Copilot or Cursor. The CodeLifter coding agents directory lists what each one reads and supports, from each vendor's documentation.
2. Git. A version control system that records snapshots of your project. Run git init in an empty folder before the first prompt.
3. A way to run the code. A browser for a static page, or Node.js or Python for anything with a server.
4. A project that cannot hurt anyone. Simon Willison's test for beginners, in his post on what vibe coding is, is to ask how much harm the code could cause if it has bugs or security holes. A personal tool, a toy game or a page that only you use passes. Anything that takes payments, stores other people's data or calls a paid API by usage does not, yet.

The definitions behind this are in what vibe coding is and where the term came from.

How should the first session go?

This order follows the workflow in Anthropic's Claude Code best practices (read on 16 October 2026), which recommends four phases: explore, plan, implement, commit. The steps work with any assistant.

1. Write what you want in one paragraph. Say what the app does, who uses it, and what "done" looks like. A vague request gets a vague app.
2. Ask for a plan, not code. In Claude Code you can press Shift+Tab until the status bar shows plan mode, or start with claude --permission-mode plan; the assistant then reads files and answers without making changes. In a chat assistant, just say "Plan this first. List the files and steps. Do not write code yet."
3. Commit, then let it build one step. Run git add -A && git commit -m "before step 1" so you can go back. Ask for one step of the plan, not all of it.
4. Make it prove the step works. The same Anthropic page says to give the assistant "a check it can run: tests, a build, a screenshot to compare". Its example prompt names test cases and ends with "run the tests after implementing". Without a check, the only signal is that the work looks done.
5. Read the diff. Run git diff and read every changed line. You will not understand all of it at first; ask the assistant to explain the lines you do not. This is the step that separates careful AI-assisted coding from the original, unreviewed meaning of vibe coding.
6. Commit or undo. If it works, commit. If it does not, undo and try a clearer prompt rather than stacking fixes on top.

Repeat for each step. The Anthropic guide also warns that once you have corrected the assistant more than twice on the same issue, the conversation is cluttered with failed approaches, and a fresh session with a better prompt usually does better.

Which checks catch what?

Check	Command or setting	What it catches	What it misses
Run it yourself	open the page, click everything	Obvious breakage	Edge cases, security
Tests	npm test, pytest	Logic you wrote a test for	Anything untested
Linter	npx eslint .	Risky patterns, such as innerHTML with a security plugin	Wrong behaviour
Secret scan	gitleaks git -v	Keys and tokens in the history	Keys you never committed
Your own diff read	git diff	Anything you notice	Anything you skim

A linter is a tool that reads code for risky or broken patterns without running it. The innerHTML thread shows how to make one fail the build on unsafe HTML, which assistants write often.

Put your rules in a file the assistant reads

Typing the same instructions every session is the first thing beginners stop doing. Most agents read a standing rules file from the repository root, usually AGENTS.md, or CLAUDE.md for Claude Code. Start it with three lines:

- Run `npm test` after every change and show me the output.
- Never put API keys or passwords in code; read them from environment variables.
- Do not add a package without telling me its name and why.

The last line matters because models sometimes import packages that do not exist, and an attacker can register such a name. For what else belongs in the file, see what should go in an AGENTS.md.

Before you share it with anyone

The CodeLifter desk article on vibe coding security collects the research and a ten-minute routine. The short checklist:

1. Search the code for keys: grep -rnE "sk_|api_key|secret|password" . and move any you find to environment variables.
2. Run a secret scanner over the whole history, not just the current files.
3. Ask a fresh session to review the diff for security problems. Anthropic's guide notes that a fresh context reviews better "since Claude won't be biased toward code it just wrote."
4. Willison's suggestion: before you share something other people will use, ask a more experienced developer for a check.

If you cannot explain what a file does, you are not ready to publish it.

Short version

• Pick a project where a bug harms nobody, and start in a git repository.
• Ask for a plan first, then build one step at a time.
• Give the assistant a test or build it must run, and make it show the output.
• Read every diff, commit what works, undo what does not.
• Keep keys out of code and scan before you share anything.