Outline — Spec-Driven Development: From Prompting to Production-Ready Systems

Speaker

Alfonso Graziano — AI Tech Lead at Nearform. Strong background in software engineering, specializing in JavaScript, AI and distributed systems. Currently leads engineering teams delivering AI-assisted projects; active contributor to tech communities. There appears to be a co-presenter in the room who fields several audience questions (identity not named in the transcript); attribute jointly as "the presenters" when unclear.

Abstract (verbatim from user)

Spec-Driven Development (SDD) is what turns AI-assisted coding from a fast prototyping tool into a reliable engineering discipline. The real challenge isn't generating code: it's ensuring that what gets built is correct, complete, and aligned with intent. In this workshop, we focus on using an SDD tool properly: treating specifications as first-class artifacts, enforcing alignment before execution, and using them to drive predictable implementation outcomes.

The session is a 90-minute hands-on workshop: take a loosely defined feature, turn it into a production-ready spec, and use that spec to guide AI-assisted implementation. Coverage includes an SDD primer, translating vague requirements into structured specs, the core SDD workflow, using an SDD tool effectively, and preventing drift over time.

Thesis (synthesis)

Vibe coding (raw prompt → code) hits a wall because agents are "constantly incorrect" with high confidence, and reviewing every line erases the speed advantage. SDD reframes the unit of work from writing code to clarifying intent: the spec is the contract between human and AI. Spec Kit's four phases (specify, plan, tasks, implement) layered with a constitution and project-context files let the human review at checkpoints rather than line-by-line, producing reproducible outcomes. The right tooling and a tiered model strategy (powerful model for spec; smaller for implementation) make the upfront cost worth it.

Section TOC

Terminology glossary (speaker's own framing)

• Spec-Driven Development (SDD) — using specs as the contract between human and AI; "the spec is more about you're planning out the work that needs to be done. You're setting up that contract between human and AI to develop new way which is safe and reproducible."
• Vibe coding (transcript: "biocoding"/"bipoding"/"by coding") — "you just fire it in and you get something. You haven't got a checkpoint."
• Spec Kit (transcript variously: "Spekit", "psyched", "spike pay") — "a lighter weight framework… four phases… specify, plan, tasks" + implement.
• BMAD (transcript variously: "be matched", "vmod", "vmatch", "bm", "demed", "beam ads", "BAD", "BMS", "be mat") — heavier alternative framework with analysis, planning, brainstorming, and work-breakdown workflows ("create stories that fix").
• Constitution — "a file which is loaded every time… contains all the information about our system… all the principles."
• Project context / guardrails — "what are we trying to build overall, what are the things we should be doing… do not do x in this situation."
• Problem space vs solution space — "we try as much as we can to keep the spec in the problem space not the solution space. So in spec is defining the what and then the implementation plan should find the how."
• EARS format — "when this happens I want that… I want that distinct fbx whatever" — template for requirements.
• Needs-clarification placeholders — "the agent inserts… needs and needs clarification placeholders where he's not sure what to do."
• Clarify skill — Spekit clarify: "another skill that you can run" to resolve placeholders interactively.
• Adversarial review — "Spekit does its own thing and then it checks that it did everything"; also applied manually: "you have to find inconsistencies, find blind spots, missing edge cases."
• Thin slice (spec) — "a spec should be like a thin slice of your system and it should both contain functional requirement and non-functional requirement."
• Living documentation — specs/docs you maintain ("the documents which are read… every interaction"), as opposed to throwaway thinking aids.
• Harness — the agent runtime (e.g. Claude Code, Codex CLI); distinct from the underlying model.

Named frameworks / concepts

1. Spec Kit four phases — Specify → Plan → Tasks → Implement, with human review between each.
2. Crisp / verify loop — "We trust it can come up with the right output… but we verified that the [outputs]."
3. Layered verification — "you can have like layers and layers of verification starting from deterministic aids that an interviewer sat on top of each other. And at that point you don't have to review any more line by line."
4. Model-tier split — "use a very powerful model initially… and then slightly smaller model like sonnet or something… for the actual implementation."
5. EARS-format requirements — "when this happens I want that".
6. "Ask me as many questions as you can" prompt — used in the specify phase to surface edge cases up front.
7. Adversarial review from a fresh context — "we start from a new context window… find inconsistencies, find blind spots, missing edge cases."
8. Spec slicing into thin slices — each spec is self-contained and implementable.
9. Project constitution + guardrails files — loaded each interaction to anchor agent behaviour.

Open questions / not covered

• Concrete metrics on rework reduction, time-to-merge, or defect rates from adopting SDD — claimed qualitatively but not quantified.
• Specific tooling for non-Claude-Code agents beyond brief mentions of Codex and "harnesses" — no comparison matrix.
• Security / compliance specifics beyond the offhand "security scanning, secret… subprime" mention.
• Team-scaling playbook is mentioned as a topic the presenters can discuss but is largely deferred.
• Detailed BMAD comparison — repeatedly disclaimed ("I promised to myself I'm not gonna talk about [BMAD] today").
• How to handle spec conflicts across multiple parallel feature branches beyond "use separate trees".
• Cost/token accounting beyond the heuristic that strong-model-for-spec uses few tokens.
• Concrete enterprise migration path from existing PRDs/Jira into Spec Kit — touched on but not detailed.
• Testing strategy specifics — TDD/BDD relationship to SDD only briefly invoked via Gherkin given/when/then.
• What "16 levels" of idea expansion actually look like beyond a UI demo reference.