Spec-Driven Coding > Vibe Coding
Vibe coding feels fast — until you try to maintain what you shipped. Six months in, features interact in ways nobody anticipated, context is lost, and every AI-generated change risks breaking three things you forgot existed. The hidden cost is not the code itself but the absence of a contract: without a spec, the AI has no ground truth, the developer has no safety net, and the codebase has no memory. Spec-Driven Development (SDD) is the answer: write the behavior first, lock it as a contract, then let the AI execute against it. The spec is the work; the code is the output.
The 7 Principles
A widely-circulated set of principles for AI-assisted coding has sparked useful debate. We agree with most of them. Where we disagree, we say so — and we explain the mechanism behind our position.
1. No vibe coding if you care about what you build. ✓ Agree
Accepting AI output without reading, running, and understanding it is how you accumulate invisible debt. Planu enforces this structurally: create_spec requires acceptance criteria before any code is generated, and validate runs a compliance check against those criteria after implementation. There is no shortcut that lets a spec reach done without the implementation being tested against its own contract. If you skip the spec, Planu refuses to proceed. See the full spec lifecycle.
2. Always understand the code it generates. ✓ Agree
Generated code you do not understand is a liability you cannot audit or debug. Planu's elicit_requirements and clarify_requirements tools force ambiguity to the surface before generation, so the developer is never handed a black box — they approved the spec that produced it. The acceptance criteria in every spec are written so a developer can read the output and immediately verify: does this code do what the criteria said? How criteria are written.
3. Don't generate an entire project from scratch with AI. ↻ Refined
True — without a spec. When an AI generates from scratch without constraints, you get a plausible-looking prototype with no stated behavior and no way to verify correctness. With an approved Planu spec, generating from scratch is exactly what we do, and it is safe precisely because the spec is the contract. The update_status tool blocks any transition from draft → approved until criteria are detailed enough to validate against. Once approved, the spec is the ground truth — generating from it is not reckless, it is the whole point. How unified spec.md works · Status transitions.
4. Keep asking questions until you fully understand the task. ✓ Agree
A model that guesses instead of asks produces confident wrong answers. Planu formalizes this with InteractiveQuestion[]: when a tool needs clarification it returns a structured array of questions that the agent relays to the user before proceeding. Nothing is assumed; every ambiguity becomes an explicit question with typed options. This is not a style preference — it is enforced at the tool layer. Mechanism.
5. Use your token budget wisely — don't dump your entire codebase. ✓ Agree
Token bloat degrades model attention and increases cost without improving output quality. Planu addresses this with a focused MCP surface: the agent sees 27 official SDD tools instead of a giant catalog. Advanced workflows move to skills, CLI commands, and internal role pipelines. Context stays tight; signal stays high. How the focused surface works.
6. Have sufficient knowledge — AI amplifies skills, it doesn't replace them. ✓ Agree
A developer who does not understand the domain cannot evaluate the AI's output, and the AI cannot compensate for that gap. Planu institutionalizes knowledge through skills (reusable rule files the agent loads per task), log_decision for capturing architectural choices, and log_lesson for post-implementation learning. The goal is not to replace expertise but to make it persistent, searchable, and available to the AI as structured context rather than as vibes. Skills & knowledge management.
7. Stop chasing every new AI model that comes out. ⚠ Disagree
We distinguish track from chase. Chasing means panic-updating every time an announcement drops, rewriting prompts for a new model before evaluating whether it actually changes outcomes, and burning team time on model-of-the-month cycles. That is bad advice to follow. But stop chasing can slide into stop tracking, and that is worse: ignoring a generation-level capability jump (better reasoning, lower cost at the same quality tier) because you are tired of announcements. Planu's own model selection rule — enforced in the global rules layer — is: classify the task, use the right model tier, and upgrade a tier only when there is a clear quality or cost gain. That requires staying informed. Track. Evaluate. Upgrade when it pays. Do not chase, but do not go dark either. Model selection rationale.
Ready to stop vibe-coding?
Put specs between you and the AI — and let the code be an output, not the plan.