The spec is the product

I used to think specs were overhead. Documents that satisfied a process but didn't improve the product.

With AI, the spec became the product. Literally. The spec is the input that determines the output. A vague spec produces vague code. A precise spec produces precise code.

A good spec, for me, starts with context: what problem exists and who has it. Instead of "users need a dashboard," I write "board members check compliance status weekly and currently dig through three spreadsheets to find it."

Then behavior, step by step, including what most people skip. What happens when the request fails? When the list is empty? When the user doesn't have permission? I also write down what we're explicitly not building. Without boundaries, AI fills in the gaps with reasonable-looking features you never asked for.

The last section is concrete examples. "When an improvement has been fully depreciated, show 0 kr remaining value and grey out the row." That sentence does more work than "handle edge cases appropriately" ever could.

The effort moved upstream. I spend more time writing specs than I ever spent writing code, and the output is better because the spec forces me to resolve ambiguity before implementation starts.

This is what Wayform does. It turns rough ideas into detailed specs because the spec is where the real product decisions happen. Everything after is execution.