The Problem with Prompt-and-Pray Most developers use AI coding agents like autocomplete on steroids: type a prompt, get code, fix what’s wrong, repeat. This works for simple tasks. For anything complex, it falls apart. Typical AI-Assisted Development Iterations:
- Round 1: “Add a notification system.”
- AI builds toast notifications. Not what you meant.
- Round 2: “No, backend notifications for orders.”
- AI creates a basic email service. Missing pieces.
- Round 3: “Also SMS, and user preferences.”
- AI bolts on features to code that wasn’t designed for them.
Why Specifications Work SDD is a methodology where you define the complete requirements and technical specifications upfront—then let the agent execute against that specification. A specification answers key questions before coding starts:
- Who needs this and why?
- What does success look like (quantifiable)?
- What’s in scope—and what’s explicitly out?
- How should this integrate with existing systems?
- What constraints must be respected?
- Without a spec: The AI guesses based on training data patterns. Every missing piece of context is a potential wrong assumption.
- With a spec: The AI knows exactly what to build, which services to use, what constraints to respect, and what success means. No guessing.
How ZenFlow Implements SDD (The Full SDD Workflow) ZenFlow formalizes SDD into a four-stage process, producing three key artifacts:
| Artifact | Description |
|---|---|
| requirements.md | Product Requirements Document (PRD). Captures user stories, success criteria, and explicit out-of-scope items. |
| spec.md | Technical specification. Details architecture, database schemas, and API contracts. |
| plan.md | Implementation plan. Breaks the work into ordered, verifiable steps. |
- Stage 1: Requirements Gathering
- The agent prompts you with questions (e.g., “What’s explicitly out of scope?”).
- Your responses are compiled into requirements.md. You review and edit this file before approval.
- Stage 2: Technical Specification
- The agent analyzes your codebase and produces spec.md.
- This is the cheapest place to catch design mistakes—review the proposed database changes and architecture before any code is written.
- Stage 3: Implementation Planning
- The agent breaks the spec into plan.md with ordered, dependent steps (e.g., database migrations before API endpoints).
- You can reorder, add, or remove steps before implementation begins.
- Stage 4: Implementation with Verification
- The agent implements each step in order.
- After each step, an AI verifier reviews the code diff against the spec, flagging issues before proceeding.
- You can intervene, approve, or request changes at any point.
- The feature touches 5+ files or multiple services.
- You need stakeholder review before implementation.
- There are compliance or audit requirements.
- Work spans multiple days.
- Breaking changes require migration planning.
- The task fits in one sentence with no ambiguity.
- Expected implementation time is under 10 minutes.
- No architectural decisions are needed.
- Model selection (e.g., Claude, GPT-4, Gemini)
- Custom prompt overrides for each stage