What it means in practice
Vibe coding works while you are the only one using the thing. Once other people join, what was never in it starts to be missed: an exact agreement on what it is supposed to do.
Spec-driven development writes that agreement down before anything gets built:
- Problem statement: which employee or customer problem we are solving.
- User requirements: what people need from it.
- Acceptance criteria: how we will know it is done.
- Technical specification: how it should be built.
- Implementation plan and tests.
We use BMAD and GitHub Spec Kit as the working examples in the workshops.
When it is worth it
When more than one person works on the solution, when it has to behave the same way every time, when you need tests, or when it gets handed to somebody other than whoever built it.
Nine questions before building
Before anyone in the workshop writes their first prompt, their group answers nine questions. They are the same ones anyone commissioning work should ask:
- Which employee or customer problem are we solving?
- Who does that problem affect?
- What would a useful solution achieve?
- Does AI only help build the solution, or does the finished application use it too?
- What data would substantially increase its value?
- Where should the application run?
- Is this a personal tool, an internal application, or a product for a customer?
- What level of security, testing and ownership does it require?
- How will we know whether the prototype is useful?
Most failed AI projects fall over because somebody never asked question four or question nine.