Skip to Content
View all events

Spec-Driven Development Frameworks Compared

Published by O'Reilly Media, Inc.

Intermediate content levelIntermediate

Choosing between Spec Kit, OpenSpec, and BMAD Method

What you’ll learn and how you can apply it

  • Compare Spec Kit, OpenSpec, and BMAD Method on file layout, command vocabulary, and where a human reviews
  • Write a project constitution with rules an agent follows, using the “do not do X because Y, do Z instead” shape
  • Choose a framework for your own code base using four questions about work type, ceremony, agent mix, and maintenance
  • Plan how your specs stay up-to-date once the implementation drifts away from them

Course description

A spec-driven development framework takes the habit of writing a specification before a coding agent implements it and turns it into something a whole team can follow: a fixed file layout, a named set of commands that drive the workflow, defaults for how requirements and acceptance criteria get written, and checkpoints where a person reviews before any code exists. Several frameworks are now in wide use, and they differ on how many documents you produce before implementation, how many agents are involved, and how much process each change has to pass through.

Guided by Alfonso Graziano, you’ll compare the three most popular frameworks: GitHub Spec Kit, OpenSpec, and BMAD Method. You’ll learn the folders each creates, the commands it adds, the artifacts it produces, and the kind of work it was designed for. You’ll work through the choice itself, using some questions about greenfield against brownfield work, how much process a team will sustain, and the agents a team already uses. The last topic is specification drift, which is where spec-driven development most often breaks down in practice, and what each framework offers to catch it.

No setup is needed. The course is discussion-based with live demos run by the instructor. If you want to follow along afterwards, the demo repo and the one-page comparison sheet are available as downloads during the session. Polls and discussion prompts throughout ask you to compare each framework against your own code base and current practice. You’ll finish the course with the ability to choose a framework and defend the choice, write project-level rules that agents follow, and keep specifications in sync with code once the implementation starts.

This live event is for you because...

  • You’re a software engineer or tech lead who already writes a spec before letting an agent code and you want that practice to spread.
  • Your team is about to pick an SDD framework and you’re the one who has to justify the choice.
  • You’ve tried one of these tools, found it heavy, and want to know whether something lighter would fit better.
  • You maintain an old code base and every SDD demo you’ve seen starts from an empty folder.

Prerequisites

  • Professional software engineering experience (any language or stack)
  • Experience using a coding agent on real work (Claude Code, Copilot, Cursor, Codex, or similar)
  • You know what a spec, a PRD, or an RFC is
  • No prior experience with any of the frameworks needed

Recommended follow-up:

Schedule

The time frames are only estimates and may vary according to how the class is progressing.

Why frameworks exist (18 minutes)

  • Presentation: What breaks when SDD is a personal habit; the moment a second engineer joins, the spec format becomes a coordination problem; where do specs live, which sections are mandatory, who approves the plan, and where do tasks come from; the three things a framework hands you—a file structure, a command vocabulary, and defaults; named checkpoints where a human reviews and approves; the ceremony spectrum—required steps, mandatory artifacts, and formal handoffs before code; light on the left—a single Markdown file; heavy on the right—a PRD, an architecture doc, and a chain of agent approvals; where the three frameworks sit, and why “heavier” is not “better”
  • Q&A

GitHub Spec Kit, the middle ground (21 minutes)

  • Presentation: The workflow; four named stages—specify, plan, tasks, implement; three optional commands—clarify, analyze, checklist; one numbered folder and one Git branch per feature, so specs pile up as a versioned library; the constitution and why it's the piece teams underrate for the first two months; why flat rules get ignored—the model’s training data is full of code that breaks your rule, so one sentence has to outweigh all of it; the fix—"do not do X because Y, do Z instead"; every rule is a small piece of teaching; extensions and presets, for when one team needs Jira and another needs a compliance format
  • Demonstration: The same feature, twice; run one—no constitution; run two—a real constitution with three rules; reading both diffs against the house rules
  • Q&A

OpenSpec, the light option (26 minutes)

  • Presentation: Delta specs and the two-folder model; most software work is modifying an existing system, and that assumption changes the whole design; specs/ is what the system does today; changes/ is what you’re proposing (archived changes merge back); a delta spec—ADDED, MODIFIED, and REMOVED requirements, each with scenarios; why the delta cuts token use and gives a reviewer a clean diff instead of a rewritten document; propose, apply, sync, archive, and where the expanded profile adds gates; the catch—propose produces the proposal, spec, design, and tasks in one shot, so you review all four together
  • Demonstration: One change on an existing repo; propose, apply, and archive, then read the spec the change left behind and ask if it’s documentation you’d trust
  • Break

BMAD Method, the heavy option (25 minutes)

  • Presentation: A product team as agents; multiple personas in the core module, each with its own workflows and its own outputs; handoffs happen through artifacts, and every workflow runs in a fresh chat on purpose; quick flow (roughly 1 to 15 stories, one tech spec, no PRD) against the standard track (a PRD, an architecture document, epics and stories); how BMAD enters an existing code base at all—bmad-document-project reads the repo and writes the artifacts the other agents expect to find; the adversarial review lens with its 10-issue floor, and why a human filter is part of that design
  • Demonstration: What a project actually drops on disk
  • Group discussion: Which of these artifacts would your team still be reading a month from now?

Choosing, and living with the choice (22 minutes)

  • Presentation: Four questions that decide it—greenfield or brownfield, how much ceremony your team will actually run (tested against your next review week), what your team's editor and agent mix looks like today, and who maintains the framework and what a breaking change costs you; drift, and how each framework helps you find it; what Spec Kit, OpenSpec, and BMAD each give you, and what none of them gives you; the habit that works in any of them
  • Q&A

Wrap-up (8 minutes)

  • Presentation: The three one-line takes, so you leave with a default rather than a shortlist; two questions from the production FAQ that always come up—how to connect specs to Jira or Linear without keeping two sources of truth, and how to assign work when stories finish in hours instead of days

Your Instructor

Alfonso Graziano

Alfonso Graziano is an AI lead at Nearform, where he builds production AI agents and helps engineering teams adopt AI-native ways of working. He writes and speaks about context engineering, spec-driven development, and shipping reliable software with AI agents, and has given over 20 talks at conferences across Europe. Alfonso is the author of AI-Native Software Engineering (O’Reilly). He’s based in Italy and is passionate about continuous learning, critical thinking, and problem-solving.

Skill covered

QA / Testing