The vibe-coding field manual

Vibe coding is a prompt loop, not a shortcut around engineering judgment - the loop just moves fast enough that bad judgment compounds in minutes instead of sprints. This manual covers the whole discipline in one place: the mindset, the planning that happens before the first prompt, the per-feature session loop with a worked example, ten practices ranked by blast radius, and the playbooks - git, prompting, debugging, testing, security - that most overviews skip. A tool-selection table and the recovery commands close it out.

Definition

Vibe coding - prompting an agent casually and accepting output on a “does it seem to work?” check, appropriate for prototypes and throwaway exploration. See vibe coding vs. agentic engineering for the full split between this mode and its production-grade counterpart - this piece assumes that definition and covers the practices that keep the casual mode from turning into expensive rework.

The mindset

The working analogy: a junior developer at the next desk, fast and tireless, with no memory of yesterday. You don’t hand a junior a one-line ticket and walk away - you have a conversation. Context in, output reviewed, corrections given, direction held. Vibe coding is that conversation at high speed.

Two consequences follow. First, your role shifts from writing code to directing it: you set the vision, review what comes back, and keep the project pointed the right way. Second, the floor doesn’t disappear - you still need programming basics to review output and catch nonsense. What you no longer need is syntax memorized or every small detail worked out by hand.

That floor has a shape worth naming. At minimum, invest in: Git - branches, commits, reverting, the muscle every recovery command below assumes you already have. How to host a finished project - Vercel, Netlify, a VPS - so shipped means live for someone else, not just running on your machine. Basic CLI commands - navigating directories, running a script, reading an error in a terminal instead of panicking at it. What SSH is and does - the secure remote shell that gets you onto a server that isn’t your laptop. What frameworks actually do and how they differ - React versus a backend framework versus a meta-framework - so a stack choice is a judgment call, not a guess. What an API is - a contract two programs talk over, which is most of what an agent is wiring together when it “adds a feature.” And the basics of networking - what a port, a domain, and HTTPS actually are. None of it needs mastery, just enough to read what the agent hands back instead of trusting it on faith.

Before you prompt: plan the build

The cheapest fixes happen before the first prompt. Five decisions up front:

Define the MVP, phase the rest. Start with the simplest version that works - for a habit tracker, that’s add a habit, check in, see a streak, nothing else. Accounts are phase two, reminders phase three. You always have something working, and the agent performs measurably better on small focused asks than on “build the whole app.”

Pick a popular stack. React, Next.js, Tailwind, Supabase, Python - the agent has seen enormous amounts of code in these, so output quality is higher and error rates lower. A niche or brand-new framework means the agent improvises more, and you spend the savings fixing its guesses. Popular stacks also mean more tutorials and community answers when you get stuck. Boring is a feature here. Once you’ve picked one, prefer its official generator over agent-written boilerplate - npm create vite@latest, npx create-next-app, npm create astro@latest, rails new, django-admin startproject - and let the agent build on top of the scaffold it creates. The generator tracks the framework’s current conventions; an agent’s training data is a snapshot that’s already stale the day a major version ships.

Generate the design system before the first component, if there’s a UI. Run a dedicated design tool ahead of the coding agent, not after. Stitch (Google Labs, free) turns a natural-language brief into UI variations on a canvas and exports a DESIGN.md - Google’s own description calls it an agent-friendly markdown file - that a coding agent can read directly. Claude Design (Anthropic Labs, research preview, bundled with Claude Pro/Max/Team/Enterprise) works the other direction: point it at an existing codebase and design files, and it builds a matching design system, then hands the result to Claude Code as a single instruction. Either way, the artifact that matters is a file the agent loads before writing a line of UI code, not a screenshot you describe to it - the same reasoning behind the spec and the config file below, applied to visual decisions instead of functional ones.

Write a short spec. One document: the features, the user flows, the data shapes, and any rules that must hold. Hand it to the agent at the start of each session so it always has the full picture instead of reconstructing your intent from fragments. This is spec-driven development in miniature - the spec is the durable artifact; the sessions are disposable.

Keep the always-on config lean. The spec is per-session context; the config file (CLAUDE.md or equivalent) loads on every turn, so it gets the opposite treatment - roughly 60 lines, only what the agent can’t infer. npx leanharness scaffolds that file, plus the deny rules (permission blocks) and skills that back it, in one command instead of writing the shape from scratch - see how to set up a minimal Claude Code harness. More on this in the ten rules below.

For the fuller method behind that MVP-and-phase call - measurable goals over adjectives, risk-first task order, and a checkpoint that catches sunk cost before it wastes another session - see how to plan and scope a build with an LLM.

The session loop: your first run, step by step

The shape of a good session is the same regardless of which tool you pick - the steps below use Claude Code’s commands as the concrete example, since it’s the terminal agent most of this guide’s practices were sourced against.

1. Pick a tool for the job. An experienced developer extending an existing codebase wants a terminal agent or AI-assisted editor; someone validating a brand-new idea wants a full-stack app builder. The tool table below breaks this down with current pricing.

2. Initialize the project. git init before the agent touches anything - every accepted change should be a commit you can inspect or revert, not an untracked mutation. If the stack has an official scaffolding CLI, run it right here, before the first prompt.

3. Write a lean config file. Run npx leanharness (or /init, or the equivalent for your tool) and keep only what the agent can’t infer from the repo itself - commands, non-default conventions, one-line architecture notes. The full argument for why short beats thorough here is in why agents ignore your CLAUDE.md.

4. Open Plan Mode before writing a line. Let the agent lay out its approach and the files it intends to touch, and read that plan before any code changes.

5. Write your first prompt as a scope, not a wish. One goal, an explicit list of what to touch and what not to, and a condition that tells you when it’s done:

   Goal: <one feature, one sentence>
   Touch only: <files or directories>
   Do not touch: src/auth/**, src/billing/**, migrations/**
   Done when: <tests and typecheck pass, or a specific behavior is observable>

   That last line matters beyond this one prompt - an agent given a fuzzy goal reports success on a fuzzy basis. Tying “done” to something it can check itself is the same discipline a verifiable completion condition demands of any autonomous loop.

6. Review the diff before you accept it. Specifically scan for file deletions, changed API signatures, new dependencies, and schema edits - the four changes most likely to be silently wrong.

7. Run tests, typecheck, and lint immediately - then commit. Not at the end of the session. A failure traced to the last diff takes seconds to fix; one traced to an hour of accepted changes takes an investigation. A green result followed by a commit locks in a checkpoint the next feature can’t destroy.

8. Clear context before the next feature. /clear (or your tool’s equivalent) before you move on - carryover from a finished feature becomes a false assumption on the next one.

9. Know the recovery commands before you need them - covered in full below, but the short version is esc to interrupt, /rewind to undo.

10. Deploy only once it’s actually done, not once it compiles. A working build and a done feature aren’t the same claim.

Repeat steps 4 through 9 per feature. That loop - plan, scope, review, verify, commit, clear - is the whole discipline; everything below just explains why each step earns its place.

Worked example: five prompts, one small tool

Concrete beats abstract. Here’s the loop applied to a habit tracker - a CLI that logs a daily check-in per habit and reports a streak. Same shape works for any small tool.

Prompt 1 - scaffold, nothing else. “Scaffold a Node.js/TypeScript CLI habit tracker. Create package.json, tsconfig.json, and index.ts that parses process.argv and routes to command handlers: add, check, streak. Storage is a local habits.json. Route the commands, but don’t implement the handlers yet.” Scoping out the handlers on the first prompt keeps the diff small enough to actually read. A one-off CLI like this has no official generator to defer to, which is why this prompt exists at all - a Next.js or Astro project would skip it and run npx create-next-app or npm create astro@latest instead.

Prompt 2 - one handler. “Implement add <habit-name> in habits.ts. Append a new habit to habits.json with name, createdAt, and an empty checkins array. Create the file with an empty array first if it doesn’t exist.” Test it immediately: npx ts-node index.ts add "read".

Prompt 3 - the next handler, same shape. “Implement check <habit-name>, which appends today’s ISO date to that habit’s checkins array if it isn’t already there today.” Test: npx ts-node index.ts check "read".

Prompt 4 - the payoff feature. “Implement streak <habit-name>, which counts consecutive days ending today with a check-in, and prints the count. If the habit doesn’t exist, print a helpful error instead of throwing.”

Prompt 5 - the edge cases a demo always skips. “Add input validation: add and check without a name print correct usage instead of crashing; an unknown command prints a list of the three valid ones.” This is the prompt most vibe-coding sessions skip because the happy path already “worked” - it’s also the one guardrail 3 (run tests after every accepted change) exists to force.

Four prompts to working, a fifth to not embarrassing. That ratio holds for most small tools built this way.

The ten rules to remember

Guardrails: protect what hurts to get wrong

These cost nothing to set up and remove the failure modes with the widest blast radius.

1. Declare off-limits zones explicitly. Name the directories an agent may never touch without an explicit prompt - auth, billing, migrations - in the config file, and repeat the same list in any prompt that touches adjacent code.
2. Review every diff before accepting, per step 6 above.
3. Run tests, typecheck, and lint after every accepted change, per step 7 above - the habit matters enough to repeat: catching a bad change one diff late is routine, catching it five diffs late is archaeology.
4. Require a written migration plan before any schema change ships - forward SQL, a rollback path, and a verification step. Schema changes are the one category of edit a git revert doesn’t cleanly undo once data has landed on the new shape.

Context hygiene: what loads every turn should earn its keep

5. Keep the context config file lean - roughly 60 lines, only what the agent can’t infer. Claude Code’s system prompt already carries roughly 50 directives before CLAUDE.md loads, and instruction-following reliability drops off past roughly 150-200 directives total (each directive being one discrete rule the model has to track); a bloated file gets discounted wholesale, including the parts that mattered. Full sourcing in why agents ignore your CLAUDE.md; npx leanharness builds that lean shape in one command instead of by hand, per the config step above. Lean is not the same as frozen: when you make a decision that will still matter next month - a storage choice, a naming convention - append it, and prune what stopped being true.
6. Reset context between features, per step 8 above.
7. Open Plan Mode before every new feature, per step 4 above - reviewing the proposed approach before a line changes catches a misread requirement while it’s a one-line correction, not a diff to unwind.

Reuse: build the pattern once, invoke it every time

8. Save the scoped prompt as a snippet, not a memory. The goal/touch/done-when shape from step 5 works because it’s explicit every time - keep it as a paste-in block instead of retyping it from memory, where details quietly drop.
9. Hand over an example file instead of describing your style. “Match this file” resolves in one shot what a paragraph of stylistic adjectives won’t; a reference file is unambiguous where prose is a suggestion.
10. Codify recurring prompts into reusable skills - test generation, security review, safe refactors, and migrations, each written once and invoked consistently instead of re-explained per session. Check the ecosystem before writing your own: skills are an open standard with a growing library, and an existing one usually beats a first draft. On composing them, see skill composition.

Git is the safety net

Version control does more work in a vibe-coding loop than in hand-written code, because the agent can change a lot of files very fast - sometimes wrongly. Four habits:

• Start every feature from a clean slate. Commit (or stash) everything before the agent starts something new. If the feature goes sideways, you discard the working tree and lose nothing you cared about.
• Commit after every task that lands green. Small commits are the checkpoint system that makes the whole loop safe - the next task can fail freely because the last good state is one command away.
• Revert with git, not the tool’s undo. AI-native rewind features are convenient mid-turn, but across a multi-file change git is the only rollback that returns you to an exact, known state with no surprises. /rewind for the last accepted edit; git revert when it’s bigger than that.
• Let the agent do the git chores. Commit messages, branch creation, push mechanics - all delegable. The decisions about what to revert and when to commit stay yours.

Prompt patterns that work

How you phrase requests determines most of what you get back. Six patterns, all cheap:

• One task per prompt. Stack five requests into one message and errors pile up across all five at once - and you can’t tell which instruction caused which failure. Ask, review, then ask the next.
• Be specific. Layout, behavior, content, constraints. Vague prompts produce vague results, and the correction round costs more than the specificity would have.
• Show, don’t describe. Paste existing files, attach mockups or screenshots, link references. Material the agent can look at beats prose it has to interpret.
• State the outcome, not the mistake. Keep a running list of the agent’s repeat offenses and turn each into a positive instruction - “use the real API response for every field,” not “don’t add placeholder data.” A model satisfies a negative instruction by avoiding the named failure, which can still miss the actual goal; naming the outcome you want closes that gap.
• Use “act as” framing when you want a stance. “Act as a security reviewer” or “act as a UX researcher” shifts the kind of scrutiny you get back from generic to role-specific.
• Ask it to think before it codes. On tricky problems, request options and reasoning first, code second. One sentence - “think through approaches before writing anything” - measurably improves complex-task output.

When it breaks: the debugging playbook

Escalate in order; each step is cheaper than the one after it.

1. Paste the full error message verbatim, plus one line on what you were doing. Most of the time this is the whole fix - resist the urge to summarize the error; the stack trace is the context.
2. Still failing? Ask the agent to add logs around the suspect path, rerun, and paste the output. Logs replace the agent’s guesses about runtime state with facts.
3. Bug keeps returning after “fixes”? Demand a list of every possible cause before it writes another patch. This forces diagnosis over symptom-patching and usually surfaces the real root cause on the first pass.
4. Once the bug is understood, write the breaking test first - a test that fails because of the bug - then fix until it passes. The fix is now proven, and the bug can’t return silently.
5. Three failed prompts on the same problem? Stop. Start a fresh session and rephrase the request from scratch. A conversation that has gone wrong keeps contaminating further attempts - the model anchors on its own earlier mistakes. A clean slate beats a rescue almost every time.
6. Give the agent real eyes where possible. An MCP (Model Context Protocol) tool like Playwright - a plug-in that hands the agent a new capability, here a real browser - lets it drive your app directly and observe its behavior instead of inferring it from source. Direct observation shortens every debugging loop that involves a UI.

Testing and refactoring

• Ask for tests as each feature is built, not at the end. End-to-end tests earn the most: they simulate a real user path and catch the breakage users would actually hit.
• Consider test-first for anything non-trivial. Ask the agent to write the test that describes the expected behavior, then the code that passes it. TDD forces the clarity that a casual prompt skips.
• Once tests exist, refactor on a schedule. Every few sessions, pause feature work and ask the agent to review and clean up the codebase. Generated code accumulates mess faster than handwritten code; the test suite makes the cleanup safe.
• Tell it to keep modules small. Left alone, an agent piles code into one file. Small, focused files are easier for you to review and easier for the next session’s agent to work with - future context is a resource you’re either saving or spending now.

The security floor

Non-negotiable even for a prototype, because prototypes ship more often than anyone admits:

• Secrets live in environment variables. API keys, passwords, tokens - in a .env file, with .env in .gitignore. Never in code, never in a commit. A leaked key in a public repo gets found by scanners in minutes, not days.
• Run an explicit security audit before anything goes public. One prompt: check for unprotected routes, missing input validation, and exposed data. Treat it as a mandatory launch step, not an optional one - this is exactly the recurring high-stakes task worth codifying as a skill (rule 10).
• Off-limits zones (rule 1) are a security control, not just a hygiene habit - auth and billing code changed casually is how a prototype becomes an incident.

Scaling up: subagents, big context, and shared skills

Once the basics are habit, three moves raise the ceiling:

• Use subagents for separable work. A subagent runs a task in its own isolated context and returns only the result - the verbose middle stays out of your main session. Focus goes up, token spend goes down; the mechanics are in subagent context isolation.
• Front-load context on complex tasks. For a change that spans many files, give the agent everything relevant at the start - files, notes, constraints - rather than dripping it in over ten turns. This doesn’t contradict the lean-config rule: the always-on file stays minimal because it loads every turn; the per-task context should be as complete as the task demands. One is rent, the other is a one-time purchase - see context engineering beats a bigger window for where the line sits.
• Borrow before you build. The skills ecosystem is an open standard with a growing library of prebuilt capabilities. Check whether someone already packaged the workflow you’re about to write a prompt for.

Matching the tool to the job

The tool matters less than the practices above, but the wrong tool for your skill level and project stage burns through the time and context those practices are meant to save. 2026 entry pricing, snapshot at publish - verify before you commit to a plan:

Ten tools, one line each on what actually differentiates them, 2026 entry pricing:

• Claude Code - full agent loop (gather context, edit files, run tests) plus Plan Mode; splits work across a stronger model for hard problems and a faster one for routine edits. $20/mo Pro.
• Gemini CLI - 1M-token context window and agent skills, with MCP server support built in. Free tier covers 1,000 requests/day; Pro is $19.99/mo.
• OpenAI Codex - a three-mode autonomy dial per task, local code review, and subagents that run pieces of a job in parallel instead of serially. Bundled with ChatGPT Plus, $20+/mo - no standalone plan.
• GitHub Copilot - a coding agent and multi-file edits available inside most existing IDEs rather than a new one. Free tier exists; paid runs $10-$39/mo individual or $19-$39/user for teams.
• Cursor - multi-file agent edits backed by a custom codebase-indexing model, plus parallel subagents. Free hobby tier, $20/mo with a shared credit pool, $40/user for teams.
• Windsurf - Cascade tracks a multi-step change across the whole codebase as it happens, with inline Tab-completion prediction. Free tier, $20/mo Pro, $40/user teams.
• Lovable - takes an idea to a live app in one session, with Supabase wired in for auth and data out of the box. Free tier (5 credits/day), $25/mo for 100/day.
• Bolt - runs a full Node.js environment inside the browser via WebContainers, so the full stack comes up from a single prompt with no local setup. Free tier (1M tokens/mo, 300k daily cap), ~$25/mo Pro.
• v0 (Vercel) - generates production-ready React and Tailwind components with a visual design mode and one-click deploy. Free ($5 credits/mo), $20/mo, $30/user teams.
• Replit - editor, agent, terminal, hosting, and database in one environment, with real-time multi-user collaboration. Free starter, $20/mo Core, $100/mo Pro.

One caveat on the does-everything-in-one-shot builders in that table: they’re the fastest way to validate an idea, but past the prototype stage they trade away the exact discipline this guide is built around. Once that idea needs to survive real users, reach for a terminal agent run the way this guide describes instead - a plan written before any code exists, a harness holding the guardrails, features built and verified one at a time through the session loop above. That combination compounds every feature; an A-to-Z generator just re-rolls the whole app on the next prompt, with no equivalent checkpoint.

Recovery: four commands, in order of how bad it’s gotten

Past these four, the escalation is the debugging playbook above - and past that, the three-failed-prompts rule: abandon the session, keep the git checkpoint, start clean. The full command inventory lives in the Claude Code commands cheatsheet.

When to graduate

Every practice here reduces the cost of staying in vibe-coding mode - it doesn’t turn vibe coding into agentic engineering. That’s a different line: formal specs, automated evals, and CI/CD gates around the same agent, covered in vibe coding vs. agentic engineering. Reach for that when the code needs to survive past the prototype that vibe coding was always meant to produce.

Bottom line

Plan the MVP, pick a boring stack, write the spec, keep the config lean. Run the loop - plan, scope, review, verify, commit, clear - and hold the ten rules, which aren’t equally urgent: skip the guardrails and a session can damage something real; skip context hygiene and it degrades turn over turn; skip the reuse practices and you’re redoing saved work. When it breaks, escalate in order and quit a poisoned session at three failed prompts - the git checkpoint means quitting costs nothing. Pick the tool for the job, not the job for the tool. The session that ships is the one that stopped and corrected course early, not the one that never went wrong.