Spec-Driven Development in the Age of AI: OpenSpec vs. GitHub Spec Kit

Alfonso José García Bañón — Sat, 15 Aug 2026 10:58:40 +0000

Originally published on labitcode.com.

In the early wave of generative AI, the software industry embraced "vibe coding" — prompting an LLM in an open chat window, hitting apply, and tweaking code until the test suite or browser stopped throwing errors.

For weekend prototypes and disposable scripts, vibe coding feels like magic. But when applied to production monoliths, distributed microservices, or long-lived codebases, it quickly degenerates into an unmaintainable tangle:

Context Rot & Compounding Hallucinations: As chat conversations grow beyond 15–20 iterations, the LLM loses track of earlier decisions and starts reverting fixes or introducing regressions.
Lost Architectural Intent: When code is generated directly from conversational prompts, the reasoning vanishes once the chat window closes.
Unreviewable PRs: Reviewing a 1,500-line diff generated across multiple chat sessions is exhausting because the requirements were never codified in Git.

The solution to this chaos is Spec-Driven Development (SDD): the engineering methodology that shifts AI pair programming from conversational guessing to structured, executable contracts.

What is Spec-Driven Development (SDD)?

Instead of asking an AI to immediately write code, SDD breaks the development cycle into distinct, verifiable phases:

Conversational Prompting ("Vibe Coding"):
Vague Prompt ──▶ AI Guesses Architecture ──▶ Generates Code ──▶ Silent Bugs & Drift

Spec-Driven Development (SDD):
Human Intent ──▶ Structured Spec & Rules ──▶ Plan & Task Matrix ──▶ Autonomous AI Execution ──▶ Verification

The 4 Core Pillars of SDD

Constitution / Rules: Global invariant standards (tech stack, security rules, dependency budgets, coding style).
Intent (What & Why): User stories, business constraints, and Given/When/Then acceptance criteria.
Architecture (How): System design, data schemas, API contracts, and component boundaries.
Execution (Tasks): A dependency-ordered checklist of atomic implementation steps.

Open-Source Showdown: OpenSpec vs. GitHub Spec Kit

Two open-source frameworks lead the SDD ecosystem today. Here is how they work and compare:

1. OpenSpec (`Fission-AI/OpenSpec`)

Developed by Fission-AI, OpenSpec is designed specifically for brownfield (existing) repositories and multi-agent development.

Key Innovation: Delta Specifications

Rather than requiring you to document an entire legacy codebase upfront, OpenSpec operates in atomic "changes":

You propose a change targeting a specific feature or bugfix.
You write delta specifications (specs/*.spec.md) describing only what changes relative to the current system.
Once implementation and tests pass, the change is synced to permanent specs and archived.

OpenSpec Slash Commands:

Command	Purpose
`openspec init`	Scaffolds the `.openspec/` configuration in your repo
`/opsx:explore`	Read-only analysis mode to investigate codebase safely
`/opsx:propose`	Generates `proposal.md`, `design.md`, `tasks.md`, and delta specs
`/opsx:apply`	Autonomously executes the checklist in `tasks.md`
`/opsx:sync`	Merges delta specs into the permanent `specs/` directory
`/opsx:archive`	Archives the completed change to preserve Git history

2. GitHub Spec Kit (`github/spec-kit`)

Spec Kit is GitHub's open-source toolkit for Spec-Driven Development, powered by the Python CLI tool specify-cli.

Key Innovation: Constitutional Engineering

GitHub Spec Kit places heavy emphasis on Constitutional Guardrails. Before specifying features, the project establishes a constitution.md file setting inviolable rules for architectural patterns, linting, test coverage, and security boundaries.

Spec Kit Slash Commands:

Command	Phase	Output Artifact
`/speckit.constitution`	Governance	`.specify/memory/constitution.md`
`/speckit.specify`	Requirements	`.specify/specs/<feature>/spec.md`
`/speckit.plan`	Technical Blueprint	`.specify/specs/<feature>/plan.md`
`/speckit.tasks`	Task Decomposition	`.specify/specs/<feature>/tasks.md`
`/speckit.implement`	Autonomous Coding	Code files & passing test suites

Head-to-Head Comparison Matrix

Dimension	OpenSpec (`Fission-AI`)	GitHub Spec Kit (`github`)
Primary Philosophy	Change-driven, delta specifications, brownfield-first	Constitution-driven, blueprint planning, greenfield & enterprise
CLI & Runtime	Node.js (`npm install -g @fission-ai/openspec`)	Python (`uv tool install specify-cli`)
Project State Structure	`openspec/changes/`, `specs/`, `archive/`	`.specify/memory/`, `.specify/specs/`
Legacy Codebase Fit	Outstanding (Delta specs require zero upfront docs)	Good (Requires establishing constitution & scope boundaries)
Governance & Rules	Embedded in individual proposals or repo rules	Dedicated Constitution engine (`constitution.md`)
Spec Merging & Sync	Built-in `/opsx:sync` merges deltas into global specs	Specs remain grouped per feature branch
Agent Ecosystem	Claude Code, Cursor, Copilot, Cline, Aider, Windsurf	GitHub Copilot, Copilot Workspace, Claude Code, Gemini
PR Review Ergonomics	Best in Class: Reviewers review `proposal.md` + `tasks.md` in PR	Excellent: Clean separation between `.specify/` and source code

Why SDD Defeats Context Rot

In traditional conversational prompting, every prompt carries the baggage of all prior interactions. By Prompt #15, the LLM is spending 80% of its attention budget parsing its own previous mistakes.

In Spec-Driven Development, each step in tasks.md executes in a clean, isolated context window:

Traditional Chat Interaction:
[Prompt 1] ──▶ [Response 1] ──▶ [Prompt 2] ──▶ ... ──▶ [Prompt 20] (Severe attention degradation)

Spec-Driven Development:
┌─────────────────────────┐
│     constitution.md     │ (~500 tokens: static project rules)
├─────────────────────────┤
│        spec.md          │ (~800 tokens: feature acceptance criteria)
├─────────────────────────┤
│        plan.md          │ (~1,000 tokens: technical architecture)
├─────────────────────────┤
│  Task #3: Active Scope  │ (~400 tokens: atomic target file)
└─────────────────────────┘
▲ 100% signal, 0% noise. Every task runs with fresh attention.

5 Golden Rules for Writing Bulletproof AI Specs

Specify Non-Functional Constraints Explicitly: Never assume an LLM knows your performance budgets. State constraints like "Bundle size must not exceed 5KB gzipped".
Use Given / When / Then for Acceptance Criteria: Ambiguous sentences cause hallucinations. Use concrete scenarios: "Given an expired token, When accessed, Then return HTTP 401 with code TOKEN_EXPIRED".
Declare Error Enums Upfront: Define exact error codes and response schemas in the spec before implementation.
Decompose Tasks into Atomic Units: Avoid broad tasks like "Implement auth". Break it into single-file or single-function steps.
Human Approval on Spec Before Code: Fixing a mistake in a 30-line Markdown specification takes 30 seconds; fixing an architectural mistake across 20 generated code files takes hours.

The Takeaway

We are leaving the era of "prompt hacking" and entering the era of the Specification Architect.

Human engineers provide the strategy, business context, and architectural boundaries. AI agents act as autonomous compilers that turn structured intent into robust, tested software.

💡 Want the full deep dive with complete code examples, real-world OAuth2 and Rate Limiter walkthroughs?

Read the full guide on our blog:

👉 Spec-Driven Development in the Age of AI: OpenSpec vs. GitHub Spec Kit

What SDD workflows or tools is your team using in production? Let's discuss in the comments below!

DEV Community: Alfonso José García Bañón