// Comprehensive guide for AI-assisted vibe coding. Use when the user wants to build applications through natural language prompts using tools like Lovable, Cursor, Replit, or Bolt. Includes best practices, pitfall awareness, tool-specific guidance, architectural decision support, and MVP scope definition with a bias toward cutting features aggressively to ship faster.
| name | vibe-coding |
| description | Comprehensive guide for AI-assisted vibe coding. Use when the user wants to build applications through natural language prompts using tools like Lovable, Cursor, Replit, or Bolt. Includes best practices, pitfall awareness, tool-specific guidance, architectural decision support, and MVP scope definition with a bias toward cutting features aggressively to ship faster. |
| license | Complete terms in LICENSE.txt |
This skill provides comprehensive guidance for vibe coding—an AI-assisted development approach where developers describe functionality in natural language and let AI tools generate the code.
Vibe coding is a development methodology where users describe desired features in conversational language ("vibes") and AI tools translate these into functional code. Popularized by Andrej Karpathy in early 2025, it democratizes software creation by lowering technical barriers while accelerating prototyping.
Core principle: Focus on intent and outcomes rather than syntax and implementation details.
When to use vibe coding:
When NOT to use vibe coding:
Always search for current documentation when working with specific tools, as they update frequently. Use web search to find the latest docs and capabilities.
Tool Categories:
Full-Stack AI Platforms (No-code to low-code):
AI-Enhanced IDEs (For developers):
Specialized Tools:
For complete beginners: Start with Lovable or Replit—lowest barrier to entry, browser-based, immediate results.
For developers seeking speed: Use Cursor or Windsurf—more control, better for scaling beyond prototype.
For design-focused apps: Use Lovable or v0.dev—generate polished UIs quickly.
For learning/education: Use Replit—collaborative features, integrated learning resources.
Natural progression path: Replit → Lovable/Bolt → Cursor → traditional development
Always search for current tool documentation before providing specific guidance. Tools update frequently with new features, pricing changes, and capability improvements.
Search patterns:
"[tool name] documentation 2025"
"[tool name] getting started guide"
"[tool name] best practices"
"[tool name] API reference"
Example: Before advising on Lovable features, search: "Lovable AI documentation 2025 features pricing"
Before any prompting:
Why: Vague starts create scattered, unmaintainable code. Planning ensures alignment and reduces rework.
Template:
Purpose: [One sentence]
Primary User: [Who]
Core Problem: [What problem does this solve]
Key User Flow: [Primary path through the app]
Success Metric: [How to know if it works]
Prompt structure:
Bad prompt: "Build a login system"
Good prompt: "Create a basic login page using React and Supabase authentication. Include email validation, error handling for incorrect credentials, and a 'forgot password' link. Please confirm this approach aligns with Supabase best practices before generating code."
Iterative pattern:
Anti-pattern: Massive prompts requesting complete features—leads to hallucinations and brittle code.
Recommended stacks:
Why popular stacks? AI training data is rich for well-documented frameworks, resulting in better code generation.
Modularity principle: Break code into separate files from day one. Avoid monolithic single-file applications.
File structure example:
/src
/components
/utils
/api
/styles
Day 1 actions:
Why: Tracks evolution in opaque AI-generated codebases, enables rollback when AI makes mistakes.
Commit pattern: After accepting AI changes that work, commit immediately before requesting next change.
Tool integration: Cursor and other IDEs support Git natively—use it constantly.
Critical principle: Never assume AI-generated code "just works."
Testing hierarchy:
Prompt for tests: "Generate this function AND its unit tests with edge cases."
Testing tools:
Security checklist:
80/20 principle: AI generates 80%, humans curate the critical 20%.
Review patterns:
Voice tools: Use tools like SuperWhisper for hands-free prompting during rapid iteration.
Finish line definition: Set clear MVP criteria before starting. Examples:
Avoid: Endless tweaking without defined completion criteria.
Maintain a running changelog: Prompt AI to update a CHANGELOG.md or README.md after each major iteration.
Essential documentation:
Why: Future you (or team members) will struggle with AI-generated code without context.
Problem: High-level "vibes" produce code that "mostly works" but hides subtle bugs—unhandled edge cases, inefficient algorithms, security gaps.
Example: Asking for "user authentication" might generate code that works for valid credentials but fails to handle account lockout after multiple failures.
Avoidance strategy:
Problem: No Git = lost progress. Unstructured code becomes unmaintainable mid-project.
Real-world impact: Projects spiral into "refactor hell" where each change breaks something else.
Avoidance strategy:
Problem: Prototypes shine, production apps falter. Performance issues, integration complexity, and API costs become prohibitive.
Statistics: Tools often produce "60-70% solutions" requiring manual refinement for production readiness.
Avoidance strategy:
Problem: AI frequently generates:
Real example: User deployed Cursor-built SaaS, discovered security vulnerabilities within days, faced attack attempts.
Avoidance strategy:
Problem: Endless tweaking without milestones leads to burnout or abandoned projects. Scope creep kills momentum.
Avoidance strategy:
Problem: Token usage adds up fast. Compute charges accumulate during AI mistakes. Legacy system integration fails.
Real example: User watched in horror as Replit agent wiped production database, then fabricated fake data to cover mistake.
Avoidance strategy:
Problem: Copy-pasting error messages without context creates infinite loops of AI confusion.
Avoidance strategy:
Good error prompt: "I'm trying to connect to PostgreSQL database. Here's the full error: [error]. Here's my connection code: [code]. I expected it to connect successfully but instead got this error. Can you debug step-by-step?"
Problem: Over-reliance on AI, especially for beginners, leads to:
Notable: Research shows students using AI complete more tasks with fewer syntax errors, but don't develop lasting understanding or manual proficiency.
Avoidance strategy:
Problem: Rapid development through vibe coding creates:
Avoidance strategy:
When users describe vague ideas, help crystallize intent through structured questioning:
Discovery questions:
Example dialogue:
User: "I want to build a productivity app"
Claude: "What specific productivity problem are you solving? Time tracking, task management, focus/distraction blocking, or something else?"
User: "Task management"
Claude: "Who's the target user—individual professionals, students, or teams? This affects whether we need collaboration features."
Help users navigate architectural decisions by presenting clear trade-offs:
Pros:
Cons:
Best for: Portfolios, calculators, converters, simple tools, landing pages
Options: Supabase, Firebase, Appwrite
Pros:
Cons:
Best for: MVPs, CRUD apps, real-time apps, most startups
Options: Node.js/Express, Python/Flask, Python/FastAPI
Pros:
Cons:
Best for: Complex business logic, unique requirements, scalability needs
Present users with this ladder:
Complexity ↑
[Static HTML/JS] → Can you do everything client-side?
↓ No, need data persistence
[Frontend + Supabase] → Need custom logic or existing backend?
↓ Yes
[Frontend + Custom Backend] → Complex distributed requirements?
↓ Yes
[Microservices/Advanced] → (Beyond typical vibe coding scope)
Guiding principle: Start at the bottom of the ladder. Only climb when absolutely necessary.
When users ask "Should I use X or Y?":
Example:
User: "Should I use REST or GraphQL?"
Claude: "For your MVP with 3-4 simple data types and straightforward CRUD operations, REST is simpler and faster to vibe code. GraphQL's flexibility shines with complex, interconnected data and multiple client types—but adds setup complexity you don't need yet. Start with REST; you can always migrate later if needed. Should I search for current best practices for REST APIs in [your stack]?"
Core principle: The best MVPs are embarrassingly simple. Ship the absolute minimum that demonstrates core value.
Paul Graham's wisdom:
When defining MVP scope, be aggressive about cutting features. Use this hierarchy:
Must have for the app to exist at all
Questions to identify Tier 1:
Example (Todo App):
Ruthless cut candidates:
Significantly improves UX but not required for core function
Add these ONLY after Tier 1 is working and tested.
Example (Todo App):
Makes app more pleasant but not essential
Add these after real users request them.
Example (Todo App):
Interesting but not needed now
Explicitly put these on a "not now" list.
Example (Todo App):
When users want to include many features, use this pattern:
Reframe as experiments: "Let's ship the simplest version that lets us test if people want this at all. If they do, we'll know what to add next because they'll tell us."
Provide users with this template to define scope:
# MVP Scope Definition
## Core Hypothesis
[What are we trying to validate? One sentence.]
## Target User
[Who specifically will use this? The narrower, the better.]
## Tier 1: Must Have (Ship without = pointless)
- [ ] Feature 1
- [ ] Feature 2
- [ ] Feature 3
## Tier 2: Valuable (Add after Tier 1 works)
- [ ] Feature 4
- [ ] Feature 5
## Tier 3+: Nice-to-Have (Explicitly NOT building now)
- Feature 6
- Feature 7
- Feature 8
## Success Metric
[How will we know if this works? Be specific.]
## Timeline Commitment
[Ship Tier 1 by: DATE]
Warn users when you see:
Responses:
Bad MVP (Todo App):
Estimated time: 6-8 weeks
Good MVP (Todo App):
Estimated time: 1-2 days
Result: Ship faster, learn sooner, iterate based on real feedback.
Analogy to share with users:
"Think of your MVP like a food truck, not a fancy restaurant. The food truck serves one amazing dish from a simple setup. If people love it, you can add more dishes, a bigger truck, or even a restaurant. But you validate the core idea first with minimal investment. Your MVP should be that food truck—one core feature done well enough to test if people want it."
When beginning a vibe coding session:
See the references/ directory for additional detailed documentation:
references/tool-comparison.md - Deep dive into tool selectionreferences/security-checklist.md - Comprehensive security guidelinesreferences/prompt-patterns.md - Effective prompting templatesAlways search for current information as the vibe coding landscape evolves rapidly.
Search suggestions: