In the Vibe Coding era, AI often lacks understanding of overall project context, architectural constraints, and long-term goals, leading to inconsistent outputs, frequent context loss, and potential architectural drift. To address these challenges, methodologies like Spec-Driven Development (SDD) and Context-Driven Development (CDD) have emerged, advocating for "writing specifications first, then letting AI generate code according to specs." This article introduces the SDD and CDD methodologies, their implementation in tools like Spec-Kit, OpenSpec, and Gemini Conductor, and finally presents a Gemini Conductor workflow setup tool create-conductor-flow.
Background: From Vibe Coding to Structured AI Programming
In February 2025, Andrej Karpathy coined the term "Vibe Coding," advocating to "forget that code exists." The concept quickly went viral but also brought massive technical debt—what the industry calls "Vibe Coding Hangover."
In response, two methodologies emerged in the second half of 2025:
- Spec Driven Development (SDD): Represented by GitHub Spec-Kit, AWS Kiro, and Tessl
- Context Driven Development (CDD): Represented by Google Conductor
Both attempt to introduce structure and discipline to AI coding, but from different angles.
SDD (Spec Driven Development)
An AI-assisted programming paradigm that writes structured requirement specifications before coding, making specs the single source of truth for both humans and AI. Based on the lifecycle and authority of specifications, it's divided into three progressive levels.
"Specs don't serve code; code serves specs"
Core Principles:
- Intent First: Define "what" and "why" before "how"
- Spec as Truth: Specifications are the anchor point for development
- Behavior-Oriented: Specs describe system behavior, constraints, interface contracts, and success criteria
- AI Execution: AI generates, validates, and regenerates code based on specs
- Traceability: Full chain traceability from intent to requirements to design to tasks to code
CDD (Context Driven Development)
An AI-assisted programming framework that enables AI to understand complete project context through systematic management of three context layers (project-level, task-level, history-level). The core proposition is that humans maintain understanding and control of the code.
"AI analyzes the entire project, not just single lines of code"
Core Principles:
- Context Persistence: Transform context from ephemeral chat to persistent Markdown files
- Intent Before Implementation: Formalize requirement specs and execution plans before coding
- Continuous Feedback Loop: Borrowing from DevOps continuous integration concepts
- Human Control: Developers make architectural decisions; AI is an advisor, not a replacement
- Context as Code (CaC): Code and documentation serve both humans and AI
- Full-Stack Context Awareness: Understanding the codebase as a whole, not individual files
Simple Analogy
| Method | Analogy |
|---|---|
| Vibe Coding | Telling a contractor "just make it look nice" |
| SDD | Drawing complete construction blueprints first, workers follow strictly |
| CDD | Taking the contractor on a tour of your home to understand your style preferences before starting |
CDD is more like adding contextual constraints to Vibe Coding, while SDD uses specification documents as constraints. Both aim to solve the chaos of Vibe Coding but take different paths.
1 | The opposite of Vibe Coding |
Two Dimensions
1 | Strong Context (Context Depth) CDD |
| Dimension | CDD | SDD |
|---|---|---|
| Focus | Input: How much AI knows about existing project | Output: How to constrain AI generation |
| Core Question | "Does AI understand my codebase?" | "Does AI generate according to specs?" |
| Emphasis | Understanding what you already have | Defining what you want to build |
Combined Usage
Four Possible Combinations:
| Combination | Description | Effect |
|---|---|---|
| Low CDD + Low SDD | Vibe Coding | Chaos |
| High CDD + Low SDD | Pure context assist | AI understands project but freestyles |
| Low CDD + High SDD | Pure spec-driven | Has specs but doesn't understand existing code |
| High CDD + High SDD | Both combined | AI both understands project and follows specs |
Google Conductor claims CDD, but it's actually SDD with context engineering. In the words of the Google Conductor team: "Rather than jumping straight into implementation, you first formalize your intent. CDD unlocks context-driven development by moving project context from the chat window to the codebase itself."
Three Levels of SDD (Bockeler/Fowler Framework)
Birgitta Bockeler (Distinguished Engineer at Thoughtworks) proposed the three-level SDD framework on Martin Fowler's website:
Level One: Spec-First
Write specifications before AI coding as guidance for the current task. After task completion, specs are typically discarded.
- Specs are temporary tools
- Subsequent changes require creating new specs
- Humans still directly maintain code
- Representative tools: Kiro, Spec-Kit, Antigravity
Level Two: Spec-Anchored
Specs persist after feature creation, continuously edited during maintenance and evolution phases. Humans and AI jointly modify specs and code.
- Specs become long-term documentation for features
- Specs and code maintained in parallel
- Both are editable artifacts
- Representative tools: Conductor (archive retention mode), Tessl (claimed goal)
Level Three: Spec-as-Source
Specs become the primary editable artifact; humans only maintain specs and never directly touch code.
- Code marked with
// GENERATED FROM SPEC - DO NOT EDIT - Human interaction with code only through specs indirectly
- The most radical form of SDD
- Representative tools: Tessl (exploring)
| Level | Spec Lifetime | Code Status | Human Edits |
|---|---|---|---|
| Spec-First | Temporary | Primary artifact | Spec + Code |
| Spec-Anchored | Persistent | Parallel artifact | Spec + Code |
| Spec-as-Source | Permanent | Derived product | Spec only |
SDD Tool Comparison
All four tools implement Spec-Driven Development (SDD), but with different design philosophies and strictness levels:
| Tool | Publisher | SDD Level | Core Philosophy |
|---|---|---|---|
| Kiro | Amazon | Spec-First | EARS syntax + Steering guardrails |
| Conductor | Spec-First | Project-level context enhancement, TDD built-in | |
| Spec Kit | GitHub | Spec-First | Constitution-driven strict specs, TDD built-in |
| OpenSpec | Fission AI | Spec-Anchored | Delta Specs incremental iteration |
Tool Positioning Map
| Tool | Project-Level Rules | Feature Spec |
|---|---|---|
| Spec Kit | Anchored (Constitution) | First (branch lifecycle) |
| Kiro | Anchored (Steering) | First (task lifecycle) |
| Conductor | Anchored (product.md, tech-stack.md) | First (track lifecycle) |
| OpenSpec | None | Anchored (system source of truth) |
1 | Pure CDD Pure SDD |
Progressive Relationship:
1 | No Spec → Spec-First → Spec-Anchored → Spec-as-Source |
How to Choose
| SDD Level | Context Loaded Per Task | Token Consumption |
|---|---|---|
| Spec-First | Current task's spec + project rules | Lower |
| Spec-Anchored | Current task's spec + all related existing specs / specs index + project rules | Higher |
| Spec-as-Source | Complete specs (code derived from spec, requires full understanding) | Highest |
The larger the system, the more extensive the specs/ directory becomes, and the higher the context cost per change—even hierarchical loading cannot fully address this. This is a trade-off.
Therefore, Spec-First is currently the most cost-effective level. Spec-Anchored is suitable for scenarios that require extremely high consistency and are willing to bear the token cost. The specific additional cost needs to be evaluated through actual testing.
How to Use Conductor
Gemini CLI
1 | gemini extensions install https://github.com/gemini-cli-extensions/conductor --auto-update |
Other Coding Agents
1 | npm create conductor-flow |
Or if you prefer the shorthand alias:
1 | npx conductor-init |