Specs and change proposals live in the repo; Jira still owns Epics, Stories, and the board. You can do both without maintaining two truths: tie one OpenSpec change folder to one Story, leave tasks.md out of Sub-tasks, and link every ticket to openspec/changes/…. Most organizations will not retire Jira; this split is how you get SDD anyway without […]
Read More →Spec-driven development treats a structured specification—not the codebase—as the system of record. This post maps who does what when you work that way: from turning product intent into an agent-readable spec, through API contracts and UI rules, to validation that implementation still matches what you wrote down. Table of contents Overview Spec-driven development (SDD) is […]
Read More →A practitioner’s guide to knowing which one you actually need. “Spec-driven” is not one practice. It is a ladder—spec-first (write then ship, spec often rots), spec-anchored (spec and code stay checked in CI), and spec-as-truth / spec-as-source (humans edit only the spec; code is generated). This piece maps the three levels (after Birgitta Böckeler on martinfowler.com), their tradeoffs, a cheat sheet, and […]
Read More →OpenSpec is a spec-driven development (SDD) framework designed to align humans and AI coding assistants by creating reviewable specifications before any code is written. It acts as “version control for intent,” helping to prevent “vibe coding” and maintain consistency. 1. Setup & Installation Get started by installing the CLI globally and initializing your project: 2. […]
Read More →Vibe coding broke as fast as it shipped. Spec-Driven Development is the industry’s course correction — putting structured specs, not chat prompts, at the center of AI-assisted engineering. This post compares the leading SDD frameworks, their trade-offs, and when (or whether) to adopt one. Table of Contents Introduction: From Vibe Coding to Verified Intent In […]
Read More →