Spec-driven development: write the plan before the code

AI can turn a short prompt into working code in minutes. That is wonderful for experiments. It can also make it easy to build the wrong thing very quickly.

The question for the session was: if implementation is becoming abundant, where should our attention go? Our answer was the specification—the small, shared agreement that says who the software is for, what it must do, what it must not do, and how we will know it is finished.

For a small project, a useful specification can be five clear answers. It should be understandable by the person with the idea, the AI agent doing the work, and the person checking the result.

Vibe coding often lets decisions emerge while you are building: prompt, inspect, notice a gap, then prompt again. A spec-driven process moves the important decisions earlier, so they can be reviewed before the agent writes the implementation.

Both approaches still involve iteration. The difference is where the decisions happen. For a tiny, reversible experiment, a prompt may be enough. When other people, important data, or several connected rules are involved, a lightweight spec saves confusion later.

We began with a vague request: “Build an event registration app.” It sounds clear until you try to build it. How many people can attend? What happens when it is full? Can one email address register twice? What should the visitor see after submitting?

Before touching the code, we turned those unknowns into four rules. The app would confirm the first 100 guests, start a first-in waitlist after that, block duplicate email addresses, and show the result immediately. The code had not changed yet, but the task had become buildable and reviewable.

For the fun part of the demo, we added a deliberately silly requirement: if somebody entered a Yahoo email address, the form should reply, “You are a boomer.” The AI implemented it exactly, and the room immediately saw the lesson.

An agent does not know which product decisions are sensible, kind, or useful. It follows the decisions we make explicit. The Yahoo rule was a joke for the workshop—not something we would ship—but it made the responsibility impossible to miss: a precise spec can still describe a bad idea.

The last step is to turn each important rule into something the agent can check. For the capacity rule, the acceptance criterion was simple: given that 100 people are confirmed, when one more person registers, then that person joins the waitlist.

That small given–when–then statement connects the idea to a test. Instead of deciding that the app looks finished, we can show evidence that the promised behaviour actually works.

Not every idea needs a formal process. A tiny experiment with no important data can begin with a prompt. A shared feature deserves a lightweight spec. Payments, privacy, security, and irreversible actions need detailed rules, tests, and explicit human approval.

The practical habit is to write five lines before your next meaningful AI build: the problem, the user, the outcome, the constraints, and the evidence of done. That is enough to move from a plausible answer toward a shared engineering decision.