5 Best Practices
The gap between doing vibe coding well and doing it poorly is large, and most of that gap can be learned. This chapter organizes the practices practitioners have built up since 2025 around principles that will outlast any particular tool: loop size, planning, context, verification, recovery, and knowing when to stop.
5.1 Start Small and Check Often
Pre-draft. Check ownership and status in TOPICS.md at the repository root.
Brief. The most frequently repeated advice among vibe coding practitioners is not to ask for too much at once. The rule of thumb is that the smaller the unit of each request and the more often the result is checked, the higher the quality of the final output. This section covers why this principle holds, what size is appropriate, and how this principle coexists with the original definition of vibe coding as “leaving it to the AI and just looking at the result.” It is the first principle of Chapter 5 (Best Practices) and serves as the premise for the following §5.2 and §5.4.
Seed Questions
- Are there practitioners or tool documentation that quantitatively specify an appropriate size for a “small step”? (e.g., number of files, lines changed, time spent)
- What is the trade-off between keeping the iteration loop short and delegating a long task wholesale to an agent and waiting (handing the agent a long task in one piece)?
- What specifically does “checking the result often” mean? Is reading the code a different principle from just looking at the execution result?
- When this principle fails, under what conditions do cases arise where quality still deteriorates even after breaking work into small steps?
- Record, as a case study, your own experience comparing vibe coding sessions where you took large steps versus small steps.
Research Pointers
- Recommended workflow descriptions from official documentation of tools such as Claude Code and Cursor
- Collect descriptions related to iteration loop size from practitioner blog posts of the “how to code with AI” genre
- If students have their own session logs, directly compare the relationship between step size and result quality
5.2 Plan First: Starting with Spec and Plan Documents
Pre-draft. Check the repository root’s TOPICS.md for owner and status.
Brief. The original meaning of the word vibe leans toward going by feel without a plan, but the practice that has settled in the field moved in the opposite direction. Before writing code, you have the AI write a plan document or spec first, and only after a human reviews it does the work move to the execution stage. This section covers how this plan-first workflow came to be established, what tool-level mechanisms like plan mode were trying to solve, and how this practice differs from or overlaps with the spec-driven development covered in §3.3.
Seed questions
- When and in which tools did tool features that explicitly support plan-first workflows (plan mode, plan approval steps, etc.) first appear?
- What is the appropriate level of detail for a plan document? What is lost if it is too detailed, and what goes wrong if it is too sparse?
- How do practitioners report their experiences of intervening to change direction at the plan stage?
- Are the spec-driven development in §3.3 and the plan-first practice in this section the same thing, or do they differ in degree of formality?
- Record as a case study your own experience comparing having a plan document written first against having code written directly.
Research pointers
- Official documentation for Claude Code plan mode and other tools’ planning and approval features
- Plan document templates or prompt examples published by practitioners
- Comparing outcome differences with and without a plan document in students’ own projects
5.3 The Art of Context Management
Pre-draft. Check ownership and status in TOPICS.md at the repository root.
Brief. The recognition that what the agent knows and doesn’t know at the start of a task heavily determines the outcome is the practical counterpart of the context engineering concept covered in §3.2. This section covers the practical techniques of project instruction files like CLAUDE.md and AGENTS.md, how to allocate the context window’s budget, and what to show and what to deliberately hide. It serves as a bridge between theory (§3.2) and practice (Chapter 5).
Seed questions
- What content do project instruction files like CLAUDE.md and AGENTS.md reportedly need to contain to be effective in practice?
- As context windows grow larger (e.g., high-capacity token models), does the need for context management techniques themselves diminish, or does it persist in a different form?
- What concrete advice do practitioners give on “what to hide”? (e.g., excluding unnecessary files, summarizing old conversations)
- How are cases reported where context management failures led to actual task failures?
- Record, as a case study, your own experience writing and improving a project instruction file (CLAUDE.md-type). What did you add that made the results better?
Research pointers
- Official documentation for project instruction files in Claude Code, Cursor, GitHub Copilot, etc.
- Practical guides on context engineering (cross-reference with §3.2 research findings)
- Analyze this repository’s (vibecoding) own CLAUDE.md as a case study
5.4 Creating Verifiable Units
Pre-draft. Check TOPICS.md in the repository root for owner and status.
Brief. The phrase “it works” is a looser standard than it seems. It might mean that running it once produced no errors, or it might mean that all tests passed. This section covers the techniques used in vibe coding practice to narrow this loose standard: writing tests, directly checking execution results, and the practice of triangulation, cross-verifying the same result through multiple methods. It is the practical counterpart to the concept of verification asymmetry covered in §8.3, and shows what techniques actually implement the theory that code is easy to verify.
Seed questions
- Is the practice of having AI write tests directly during a vibe coding session reliable? How is the risk of the tests themselves being poorly written addressed?
- “Confirming by running it” and “passing tests” are two standards with different verification strength. What combination do practitioners recommend?
- What are concrete examples of triangulation (reconfirming the same result through a different method) actually being used?
- How is the cost of splitting verification units too finely (slowdowns, excessive test code) discussed?
- Record the verification methods used in your own project in detail. What did you test, what did you only check visually, and why did you make those choices?
Research pointers
- Practical discussions on combining TDD with AI agents (can cross-reference §10.4)
- Official documentation on automatic test generation and execution features by tool
- Compile students’ own project verification procedures as case studies
Translated file written to en/sections/05-5-reversibility.qmd, matching the machine-translation marker format (source-sha256, model, date) used by tools/translate and the sibling en/sections/05-2-plan-first.qmd.
5.5 When to Stop and Read the Code Yourself
Pre-draft. Check ownership and status in TOPICS.md at the repository root.
Brief. The difference between people who are good at vibe coding and those who are not mostly comes down to a sense of when to trust the AI and when to step in directly. This section works to turn that sense into as explicit a list of signals as possible. It covers the situations in which practitioners actually stop and read the code themselves, and what cases where that judgment was delayed and the problem grew larger show us. As the final section of Chapter 5, it closes out the practical principles carried through since §5.1 with the question of when these principles break down.
Seed Questions
- What signals do practitioners commonly cite as requiring direct intervention? (security-related code, data deletion, payment logic, etc.)
- What patterns appear in real cases (post-mortems) where missing this signal caused a problem to grow larger?
- Does the standard for when to stop change depending on experience or domain knowledge? What is the difference in standards between beginners and experts?
- At the team level, are there attempts to replace this judgment with a process (review, gates) rather than leaving it to the individual?
- Record, as a case, a moment when you yourself actually stopped and read the code directly during vibe coding. What made you stop?
Research Pointers
- Post-mortem articles on vibe coding failure cases, security incident reports
- Team-level AI coding governance policy documents (cross-referenceable with §9.5)
- Have students record their own moments of intervention to derive common signals