At Vibe Coding Bremen I ran a practical workshop on spec-driven development. The exercise started with a vague product idea: a flower postcard shop. Before touching implementation, the group wrote down what the product was, who it was for, how it should feel, and where its technical limits were.
The workshop ended with the specs. I completed the implementation after the event and turned those decisions into a working frontend demo. That distinction matters. The design was not discovered by repeatedly asking a model to make the page prettier. It was already present in the direction.
The important work happened before the code
The product overview defined the emotional job. This was not a generic postcard configurator. It was a small, more affordable version of sending flowers.
“The sentiment is the same as sending flowers: I’m thinking of you.”
Project overview
The design spec then ruled out the most likely default.
“It should not look like clean, technical SaaS. Think 80s floral wallpaper, flower power, graphic organic shapes, and a design that feels emotionally loaded.”
Design direction
The technical spec made the boundary equally clear: frontend only, no backend, no real payment, and a simulated checkout. These are simple sentences. Together they remove a large amount of guesswork.
A spec is a decision surface
A spec does not need a complicated format. It needs to state the decisions that should survive across prompts, sessions, tools, and people. Product intent, audience, design language, architecture, constraints, and acceptance criteria all belong there when they affect the result.
This is why I see specs as the base of advanced AI development workflows and automations. A planning agent can split work. A coding agent can implement it. A browser agent can test it. An automation can repeat the sequence. None of them can recover a decision that was never made.
Automation accelerates decisions.
Without specs, it accelerates assumptions.
Distinct direction produces a distinct result
AI-assisted interfaces often feel generic because the request is generic. “Build a modern shop” leaves typography, composition, color, movement, imagery, and emotional tone open. The model has to fill every gap with a familiar average.
Here, the direction rejected that average. It asked for floral excess, organic shapes, a warm gifting ritual, and a frontend that still worked as a small product. The implementation had room to invent, but not to drift.
That balance is the point. Specs are not there to prescribe every pixel. They provide enough clarity for useful judgment. The better question is not what the model can build. It is what I have made clear enough that it no longer needs to guess.