메뉴
Use when rapidly prototyping AI products — going from idea to working demo in 4-8 hours using AI-assisted development tools (Cursor, Bolt, v0, Lovable), knowing when to vibe vs spec, and transitioning prototypes to production.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | vibe-coding |
| description | Use when rapidly prototyping AI products — going from idea to working demo in 4-8 hours using AI-assisted development tools (Cursor, Bolt, v0, Lovable), knowing when to vibe vs spec, and transitioning prototypes to production. |
| Situation | Use Vibe Coding | Use Spec-Driven |
|---|---|---|
| New idea, unvalidated | ✅ — test in hours | ❌ — too slow |
| Validated idea, building for real | ❌ — too fragile | ✅ — solid foundation |
| Throwaway prototype | ✅ | ❌ |
| Production feature | ❌ | ✅ |
| UI exploration (which layout?) | ✅ | ❌ |
| Complex backend logic | ❌ | ✅ |
| Time pressure, low stakes | ✅ | ❌ |
| High stakes (payments, security) | ❌ | ✅ |
Rule of thumb: Vibe for validation, spec for production. The switch happens when users start paying.
Tools that let one person ship a working demo in an afternoon:
Frontend (30 min):
v0.dev → describe UI in natural language → copy Next.js components
OR Bolt.new → describe full app → working app with auth + DB
AI integration (30 min):
Cursor → "Add Claude API call to this component"
Provide: system prompt + user input → streaming response
Auth + Database (0 min with Supabase):
Bolt.new includes Supabase by default
OR: use Clerk (auth) + Supabase (DB) — 2 env vars, done
Deployment (5 min):
Vercel → connect GitHub → auto-deploy
Custom domain: $12/year on Namecheap
Total time to "share this link with users": 2-4 hours
How to get 10x better results from Bolt/v0/Cursor:
For Bolt.new (full app generation):
Describe in ONE paragraph:
"Build a [type] app for [ICP] that lets them [core action].
Use Next.js, Supabase for auth + DB, Tailwind for styling.
The main page shows [key feature]. Include [specific functionality].
Keep it simple — no admin panel, no complex settings."
Include:
✅ The primary user action (what they do most)
✅ The data model (what gets stored)
✅ The tech stack (prevents mismatch)
❌ Don't include: edge cases, nice-to-haves, complex flows
For v0.dev (UI generation):
"Design a [component name] for a [product type].
Style: clean, professional, [color scheme]
Shows: [key information]
Actions user can take: [list 2-3 max]
Similar to: [reference product] but for [your niche]"
Iterate with: "Make the [element] more prominent" / "Add [feature] to this"
For Cursor (feature addition to existing code):
@file.tsx "Add a [feature] to this component.
When user [trigger], it should [action].
Use [existing pattern from codebase] as reference.
Keep it minimal — only what's needed for this use case."
Know when to throw away the vibe prototype and rebuild properly:
Stop vibing when:
100 users/day (reliability becomes real)
Rewrite signals:
Prototype is ready to throw away when:
✅ Problem is validated (people pay)
✅ Core UX flow is understood (user testing done)
✅ Data model is stable (won't change much)
✅ Performance issues can't be fixed by tweaking prompt
Rewrite with:
- Spec-driven development skill (write spec first)
- TDD (now reliability matters)
- Proper architecture (not Bolt-generated spaghetti)
Getting the most out of AI-assisted development as a solo builder:
Daily workflow:
Morning (2 hours):
- Cursor: implement yesterday's validated ideas
- Commit working state before starting new feature
Afternoon (2 hours):
- User calls / testing with real people
- Note what to build next based on what broke
Evening (30 min):
- Bolt/v0: prototype tomorrow's new feature idea
- Don't build it for real yet — just see if it's feasible
Avoiding vibe coding traps:
mvp-rapid-development for transitioning prototype to real productspec-driven-development when rewriting vibe prototype properlyai-product-validation — vibe a landing page in 2 hours to test demand@solo-ai-builder decides vibe vs spec based on validation stageUse when conducting quality audits — reviewing process compliance, identifying gaps between defined process and actual practice, conducting structured inspections (code review audits, test quality reviews), and producing audit reports with remediation plans.
Use when managing quality risk — identifying quality risks in a product or release, applying risk-based testing prioritization, creating risk mitigation plans, and communicating quality risk to stakeholders for go/no-go decisions.
Use when designing or implementing test automation — choosing the right automation framework (Playwright, pytest, JUnit), Page Object Model, selector strategies, test isolation, managing flaky tests, and CI integration.
Use when managing defects — writing effective bug reports, applying severity/priority matrix, tracking defect lifecycle, conducting root cause analysis, and measuring defect metrics for process improvement.
Use when measuring and reporting QA quality — defect escape rate, test coverage analysis, flaky test rate, mean time to detect, shift-left metrics, and building quality dashboards for stakeholders.
Use when managing test data — designing test data strategies, using factories and builders, creating fixtures, generating synthetic data, masking PII for testing, and managing test database state.