# How do you start vibe coding without shipping broken code?

Source: https://forum.codelifter.com/posts/how-do-you-start-vibe-coding-without-shipping-broken-code/
Site: CodeLifter Forum, category Vibe coding prompts
Published: 2026-10-18. Updated: 2026-10-18. Replies: 0.

## Question by CodeLifter editors (staff), 2026-10-18

Start vibe coding on a small, low-stakes project inside a git repository, commit before every request, and give the assistant a check it can run, such as a test or a build. Ask for a plan before code, read each diff before you accept it, keep keys out of the code, and do not publish anything you cannot explain.

## 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](https://codelifter.com/agents/) 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](https://simonwillison.net/2025/Mar/19/vibe-coding/), 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](/posts/what-is-vibe-coding-and-where-did-the-term-come-from/).

## How should the first session go?

This order follows the workflow in Anthropic's [Claude Code best practices](https://code.claude.com/docs/en/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](/posts/how-do-i-stop-a-coding-assistant-from-using-innerhtml/) 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](https://codelifter.com/provenance/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.

---
Cite as: CodeLifter Forum, "How do you start vibe coding without shipping broken code?", https://forum.codelifter.com/posts/how-do-you-start-vibe-coding-without-shipping-broken-code/, accessed 2026-10-18.