Archive / Other Writing
Spec-Driven Vibe Coding vs. Claude Code Plan Mode
Two AI coding workflows that look similar but optimize for different things — iteration speed under constraints vs. reliability under complexity.
Published: Reading time: 3 min readEN
Two distinct AI coding workflows are emerging:
- Spec-driven vibe coding
- Claude Code's Plan Mode
They look similar. They optimize for different things.
Originally published on LinkedIn. Part 2 of a series — see also design-driven AI development.
Spec-driven vibe coding
This approach starts with a structured spec:
- Clear requirements
- Explicit constraints
- Defined interfaces
- Non-goals
- Success criteria
Not a long PRD. Not a loose prompt. A focused contract.
Once the invariants are defined, AI generates implementation within those boundaries. You iterate quickly, refine assumptions, and evolve the architecture as clarity improves.
When it works best
- Building new systems from scratch
- Exploring solution space where requirements are fuzzy
- Speed matters more than perfection
- The cost of mistakes is manageable (feature flags, small blast radius)
You're guiding at the level of principles, not micromanaging execution.
Example spec skeleton
## Goal
Add usage budget caps per workspace.
## Invariants
- Existing invoices unchanged
- Budget check before rating, not after
- Admin API only for cap changes
## Non-goals
- UI dashboard (API only this sprint)
- Multi-currency conversion
## Success
- Integration test: over-cap request rejected with 402
The spec is the guardrail. Vibe coding is the iteration inside the guardrail.
Claude Code Plan Mode
Plan Mode changes the order.
Before writing code, it decomposes the task, surfaces assumptions, and proposes a structured execution plan. Only after alignment does implementation begin.
This adds predictability and reduces risk.
When it works best
- Refactoring large codebases
- Performing migrations (schema, API version, pricing model)
- Making cross-module changes
- Operating in high-cost environments (production billing, payments, auth)
It optimizes for correctness before momentum.
What a good plan includes
- Files to touch, in dependency order
- Rollback strategy
- Test checkpoints between steps
- Explicit assumptions flagged for human review
You treat the plan like a design doc that happens to be executable.
The real difference
| Spec-driven vibe coding | Plan Mode | |
|---|---|---|
| Optimizes for | Iteration speed under constraints | Reliability under complexity |
| Primary risk | Scope creep inside "fast" loops | Analysis paralysis |
| Best question | "What are the invariants?" | "What breaks if we're wrong?" |
| Failure mode | Architecture evolves accidentally | Slow start, safer finish |
One reduces stagnation. The other reduces unintended consequences.
How to choose
Ask:
- Can I afford a wrong merge? If no → Plan Mode first
- Do I know the shape of the solution? If no → spec-driven exploration
- How many modules does this touch? One → vibe may suffice; many → plan
- Is this greenfield or legacy? Legacy almost always wants Plan Mode
The key isn't choosing one permanently. It's knowing which cognitive mode your problem requires.
Combining both
They're not mutually exclusive:
- Write a tight spec (invariants + non-goals)
- Run Plan Mode against real files
- Iterate implementation inside the spec
- Re-plan when you hit a cross-module surprise
AI-assisted development is no longer just about generating code. It's about structuring reasoning.
That choice increasingly defines engineering leverage.