Efficient Workflows: Five Disciplines for vibe coding
💡 Goal: In about 1 hour (five lessons of 10–12 minutes each), establish the five disciplines—be able to say what pitfall each one guards against; next time you start work, write your idea into a requirements list before letting the AI act; and for anything others will use, pass acceptance checks before going live.
Once you know how to use the tools, the gap shifts to the vibe coding workflow. This stop covers no new features of any tool; it does exactly one thing: establish five cross-tool disciplines.
Why do you need disciplines? Look at the original approach in Karpathy's widely shared tweet: the effective part—"when you hit an error, just copy-paste it back in, and it usually gets fixed"; the dangerous part—"I always hit Accept All and no longer look at the diff." He drew the line himself: this approach works fine for one-off weekend side projects.
It doesn't work for things built for others. CodeRabbit's 2025-12 analysis of 470 open-source PRs on GitHub showed that code written with generative AI's involvement had roughly 1.7 times more "major" issues than human-written code, and 2.74 times more security vulnerabilities (for data and real cases, see 1.2 Is vibe coding reliable).
So these five disciplines are compiled from three sources: Claude Code official best practices, engineer Simon Willison's security checklist, and the parts of the original approach that have been proven effective. They apply to Claude Code, Codex, OpenCode, and WorkBuddy—switch tools without relearning.
🎯 Stage Goals
- Be able to say what pitfall each of the five disciplines guards against: planning prevents rework, prompts prevent wrong guesses, the error loop prevents getting stuck, acceptance checks prevent shipping broken code, and cost-and-security prevents wallet and key incidents
- Next time you start work, change your approach: turn a one-sentence idea into a requirements list first, then let the AI touch the code, instead of guessing as you go
- Set yourself a hard rule: for anything others will use, go through an acceptance checklist before going live; for anything involving keys or spending, set up guardrails first
⏳ Estimated Time
- The five lessons total about 52 minutes (10–12 minutes each); with buffer time, about 35–70 minutes
- Each lesson stands alone and is ready to use after reading; if your current project is stuck on a particular discipline, jump straight to that lesson and fix it there
🚀 Before You Start
- Completed the previous stopDaily Use: installed and used at least one tool to run a full round of conversational development
- Have a real small project or small requirement on hand as practice material (a personal webpage or small script both work)—disciplines only stick when applied to real projects
- Know how your tool charges (subscription / pay-as-you-go API / credits); if you forget, go back to 2.5 Price Comparison
- A cup of water ☕—this stop barely requires typing commands; it's mostly about changing how you think
📚 Lessons in This Stage
| Lesson | Content | Duration |
|---|---|---|
| 3.1 Plan Before You Build | Turn a one-sentence idea into a requirements list: have the AI interview you first, spell out what "done" looks like, then start | 10 minutes |
| 3.2 Prompt Writing | Give full context: name the files, describe the symptoms, define what "fixed" means, and aim to get it right the first time | 12 minutes |
| 3.3 The Error Loop | Feed errors back verbatim; if two rounds of fixes don't work, interrupt and change approach—don't loop forever | 10 minutes |
| 3.4 Acceptance Checks | How to review AI-written code before shipping: run pass/fail checks and be able to explain what it does | 10 minutes |
| 3.5 Cost and Security | Three lines of defense: keys, bills, and sandboxes—"Accept All" is only for low-risk projects | 10 minutes |
💡 Five Disciplines at a Glance (details in each lesson)
| # | Discipline | One-Line Practice | What Pitfall It Prevents |
|---|---|---|---|
| One | Plan before you build | Finish the requirements list before letting the AI touch code | The AI guesses the wrong direction, and you only find out after it's done that it's not what you wanted |
| Two | Give prompts full context | Name the files, describe the symptoms, define what "fixed" means | One-liner prompts like "fix the login bug" lead to round after round of rework |
| Three | Feed errors back verbatim | Paste the full error; if two rounds of fixes fail, interrupt and rewrite the prompt | Infinite loops on the same error, burning time and tokens |
| Four | Run acceptance checks before going live | Run pass/fail checks and be able to explain what the code does | Shipping with vulnerabilities—AI-involved code has 2.74 times more security vulnerabilities than human-written code |
| Five | Set up cost and security guardrails | Keep keys under watch, cap billing, use a sandbox when you can | Leaked API keys; APIs without billing caps racking up bills of thousands of dollars |
The first four disciplines govern "getting it built"; the fifth governs "don't take yourself down with it." Each discipline is broken out into its own lesson; reading them in order flows best, but you can also jump to whichever one you're stuck on.
🎒 What You'll Gain
- A complete process from idea to launch: planning → prompts → errors → acceptance → cost and security, with a checklist to follow at every step
- Five disciplines that stay the same even when you switch tools: Claude Code, Codex, OpenCode, WorkBuddy are all applicable
- A clear-eyed comparison: what can be kept from the original workflow (pasting errors back) and what must change (accepting everything without looking at the diff)
- Your ticket to scenario practice: with discipline in place, pick any of the three routes — website, mini program, or plugin
Ready? Start with the first lesson: plan before you act → — if your current project is stuck on an error, you can also jump straight to 3.3 the error loop for a quick fix.