Vibe Coding went from Andrej Karpathy’s framing to a developer-wide meme in under a year. Many still treat it as “chat with AI and get code.” Anyone who has shipped with it knows: vibe coding is not one style — it is a continuum.
Project stage, team maturity, and risk tolerance imply different collaboration modes. A crude binary of “pure AI coding” vs “line-by-line human review” is neither scientific nor useful.
This note maps Vibe Coding on two dimensions so you can pick a tempo that fits.
1. Input control: four levels from “rough idea” to precision guidance
How tightly you control AI input sets both creative room and controllability. Behind this sits Spec-Driven Development (SDD): the spec is the source of truth; code is an executable projection of the spec. In the AI era, input clarity largely decides output quality.
Level comparison
| Level | Input | AI room | Fits | Example prompt |
|---|---|---|---|---|
| L1 Inspiration fuzzy need | Direction only; AI invents details | Max | Prototypes, weekend apps, exploration | “Build a to-do app that looks nice.” |
| L2 Requirements | Features, stories, acceptance — not how | Medium | Small/medium features | “Phone + OTP signup; then land on home.” |
| L3 Framework | Requirements + stack, layers, APIs | Smaller | Production features in existing systems | “Spring Boot + MySQL user module, Controller/Service/Repository, REST.” |
| L4 Precision | Full design, data, algorithms, exception policy | Minimal | Core paths, high-risk, performance-sensitive | “Implement payment callback per this API doc; HMAC-SHA256; three exception classes…” |
Why more precision is not always better
- L1 is fastest, rework is highest — great for seeing something quickly.
- L4 is steadiest, upfront cost is highest — you trade coding time for specification time.
- L2/L3 are the sweet spot for most projects — keep AI leverage while containing core risk.
SDD insight: as the marginal cost of AI coding nears zero, clearly saying what you want becomes the scarce skill. Fuzzy specs yield “looks right, is wrong” code.
2. Output review: black / gray / white box
After AI emits code, how much must you see before merge?
1. Black-box
- Trust results: tests, acceptance, integration.
- Fastest; debt, security, and performance can accumulate unseen.
- Fits internal tools, prototypes, one-off scripts, low-value UI.
2. Gray-box
- Own architecture and boundaries; skip deep function bodies.
- Balance speed and rot-prevention.
- Fits most business features and mature-system iteration.
3. White-box
- Read the full diff; own every line.
- Highest quality; slowest; can erase the AI speed win.
- Fits payments, auth, infrastructure, shared libraries.
Review focus comparison
| Dimension | Black | Gray | White |
|---|---|---|---|
| Functional correctness | ✅ tests | ✅ tests | ✅ tests |
| Architecture | ❌ | ✅ focus | ✅ |
| API contracts | ❌ | ✅ focus | ✅ |
| Logic detail | ❌ | ❌ shallow | ✅ line-by-line |
| Edges / exceptions | ❌ via tests | ⚠️ spot-check | ✅ full |
| Security | ❌ scanners | ⚠️ deps & entries | ✅ audit |
| Style / norms | ❌ | ❌ | ✅ strict |
3. Two-dimensional map of Vibe Coding modes
| Input → / Review ↓ | L1 Inspiration | L2 Requirements | L3 Framework | L4 Precision |
|---|---|---|---|---|
| Black-box | Wild vibe (toys/prototypes) |
Test-driven black-box (internal tools) |
Contract black-box (peripheral systems) |
— |
| Gray-box | — | Standard vibe (general business) |
Mainstream engineered vibe (production) |
Precision collab (core modules) |
| White-box | — | Assistive coding (speed tool) |
Architect + AI (complex systems) |
SDD (high-assurance) |
Cells marked “—” are rare in practice — bad ROI, e.g. L4 input with black-box review, or L1 input with white-box review.
Wild vibe (L1 + black) — classic “vibe”: rough idea, generate, ship if it runs. Fine for personal experiments; never production.
Mainstream engineered vibe (L3 + gray) — humans set needs, architecture, APIs; AI fills; humans check boundaries; tests cover internals. Most production AI coding lands here.
SDD (L4 + white) — structured specs, AI code+tests, human line review. Highest certainty, slowest. Finance, payments, medical, etc.
4. Lifeline: test-driven convergence
Whatever mode you pick: without a solid test system, Vibe Coding is skydiving without a chute.
In traditional work, authors hold mental models; with AI edits you cannot fully predict blast radius. Tests are the safety net.
- First write happy-path tests.
- Every bug becomes a lasting test.
- Add tests before AI refactors a module.
- Let AI write tests; you review case quality — SDD’s spec → test → implement path.
Healthy projects show bug convergence: noisy early, fewer mid, stabilized late under the test net. Rising bugs usually mean L1 inputs aiming at production, or black-box without enough tests.
5. How to choose
| Stage | Suggested mode | Why |
|---|---|---|
| 0→1 prototype | L1 + black | Speed to validate ideas |
| MVP | L2 + gray | Quality rising, still iterate fast |
| Launch | L3 + gray | Architecture set; tests + boundary review |
| Steady ops | L3/L4 + gray/white | Core goes white; non-core stays gray |
- High risk (pay, login, auth): L3/L4 + white.
- Medium risk: L3 + gray.
- Low risk: L2 + black/gray.
Team tips: pilot L2+gray on low-risk modules first; standardize requirement templates even at L2; harden CI/CD so black-box quality sinks into automation rather than “no quality.”
6. Closing
Vibe Coding is a redefinition of human–AI division of labor — humans upstream on intent, architecture, judgment, acceptance; AI downstream on implementation and repetition.
- Input: how much will you spend making intent clear?
- Output: how much will you spend owning quality?
There is no universal right answer — only a fit for the scene. Keep one constant: testing is the floor of Vibe Coding. Iteration can be fast and style can be wild; the net must hold.
The vibe can be light; delivery cannot be casual.