🧭 Spec-Driven Development Oct 1, 2026
From vibe-coding to a repeatable workflow. Today you'll start a real project the spec-driven way: settle the problem, the plan, and what counts as done — before any code exists — then let an AI agent build it.
Pick one of two fun cases and build it end to end. Beginners can follow the guided happy path step by step; experienced devs treat the MVP as a warm-up and chase the stretch goals. Facilitators are here the whole time — wave one over whenever you're stuck.
📅 Part of the GroningenPHP meetup on Thu, Oct 1, 2026 · doors 19:30 — event details & RSVP.
1 · Set up your tools
Before anything else, get the free tooling running — it takes about 15 minutes.
2 · The flow — seven steps, two phases
This is the whole idea: the first four steps happen before any code exists. You decide what, why and how up front — then the agent writes, a check gates it, and a human reads it.
- 1Intentwhat problem
- 2Specwhat & why
- 3Planhow, grounded
- 4Tasksunits of work
- 5Implementagent writes
- 6Verifya check gates it
- 7Reviewa human reads
Kickoff checkpoints the facilitators will look for as you go:
- You picked a case and can say what it is in one sentence.
- You wrote
spec.md— what & why, no code — before building. - You got your
plan.mdsigned off before writing code. - You hit a wrong assumption and fixed it in the plan, cheaply.
- You made one rule enforceable with a real check.
3 · One vocabulary — four artifacts
Five independent frameworks (GitHub Spec Kit, AWS Kiro, BMAD, OpenSpec, Superpowers) all reinvented the same four files. They're files in the repo the agent reads every session — not a chat that vanishes.
Placement that works best across agents: keep agents.md at repo root, and keep spec.md, plan.md, tasks.md in /.specification/changes/feature-name/. Include that folder path in the session chat when you start work so the agent uses the right files.
Constitution agents.md
The rules that don't change per feature — how you commit, what needs a human "yes". Written once, read every session.
Plan plan.md
How, grounded in the codebase. Which files, which order, and the check that proves it worked.
4 · Choose your case
Now put it into practice. Both cases run the exact same spec-driven arc — pick whichever sounds more fun.
5 · When is it worth the ceremony?
Spec-driven development earns its keep for auditability (what was decided, not just what changed), governance (one file people and agents both read), and parallelisation (agents in parallel need contracts that don't overlap).
It is not for prototypes, one-line fixes, or exploration.
Simple tasks need a prompt. Complex ones need a spec. Writing the decision down turns a six-month bet into an experiment you can fail in an afternoon.
This workshop is based on the GroningenPHP talk "Spec-Driven Development: from vibe-coding to integrating AI coding assistants into the software development lifecycle."
6 · Take it home
Today you'll do spec-driven development by hand. To keep doing it on your own projects, there's a free tool that gives it structure and a repeatable lifecycle — OpenSpec. The take-home guide walks you through install → propose → apply → archive, and points at the real change that built this very workshop.
Use this default layout: /agents.md at repo root, and work-specific files in /.specification/changes/feature-name/. At session start, include that folder path in chat so the agent loads the right context.
Curious what this workshop is built on? See the about & credits page for the full list of tools and technologies used.