Ship fast. Stay in control. Minimal ceremony.
- Active feature development
- MVP and prototype work
- Indie hacking and side projects
- When speed is the priority and you're the only reviewer
- Greenfield code with few existing constraints
Builder Mode is optimized for moving fast without creating debt. It is not optimized for zero risk — it is optimized for acceptable risk with recoverable mistakes.
- Working code over perfect code
- Flat structure over architecture
- Inline logic over abstractions (until the second use case)
- Ship the feature, note the tech debt, keep moving
- Provide full task context upfront — don't drip-feed
- Include the relevant file section (not the whole file)
- State your stack and patterns once per session — don't repeat
- Compress context at every feature boundary
- One feature per session
- Use the Builder Prompt Pattern below
- Ask for complete implementations, not outlines
- Request one file at a time with confirmation gates
- Full function implementations (not diffs)
- Inline comments for non-obvious logic
- No extensive tests unless explicitly requested
- No over-engineering — "will this ship?" is the test
- Maximum 5 new files per feature without stopping to evaluate
- No new dependencies without at least 60 seconds of consideration
- No refactoring of existing code unless directly blocking the feature
- Checkpoint after every completed feature
- Save a Context Snapshot before switching tasks
- New feature = new session (or at least a context compression)
## Feature: [name]
Stack: [language + framework + key dependencies]
Goal: [what it does — one sentence]
Files to touch:
- [path] — [what changes]
- [new path] — [NEW — what it is]
Constraints:
- No new dependencies
- Follow existing patterns in [reference file]
- [any other constraint]
Done when:
- [testable condition]
Build [first file] first. Wait for my confirmation before the next file.
When unsure about an approach, spike first:
"Build the simplest possible version of [feature] — no error handling,
no edge cases. Just prove the core logic works. I'll add robustness after."
For multi-file features, scaffold before implementing:
"Create the file structure and empty function signatures for [feature].
Don't implement anything yet — I want to approve the structure first."
Avoid large unseen diffs:
"Build [component A] only. Stop and show me before touching [component B]."
These will slow you down and create debt:
| Anti-Pattern | Cost |
|---|---|
| "Also add tests and docs" | 2-3x longer session |
| "Make it production-ready" | Undefined scope = scope creep |
| "Use best practices throughout" | AI rewrites things that work |
| Skipping confirmation gates | Large unreviewed diffs |
| Letting sessions run without checkpoints | Context chaos |
Part of Vibe Coding Essentials — All Modes
- Define scope: State exactly what the feature does and what it DOES NOT do.
- Accept tradeoffs: Explicitly give the AI permission to skip abstractions and use duplicated code if it ships faster.
- Review diffs: The AI will write a lot of code quickly. Review the diff to ensure it didn't refactor unrelated systems.
"[BUILDER] We need to add a 'Forgot Password' button to the login screen. It just needs to call the
/api/resetendpoint. I don't care about making a reusable Button component right now, just use a standard<button>with Tailwind classes. Files in scope:Login.tsxandapi.ts."