Part 1: One Spec To Rule Them All

One Spec to rule them all, one Spec to find them, one Spec to bring them all, and in the darkness bind them.

This is the first post in a series about spec-driven development. Not which tool to use or how to get started, but what I learned after living with a spec long enough to hit the problems that nobody writes about yet. I do not have all the answers and I am not trying to be a guru. I am sharing what worked, what did not, and what I am still figuring out. If you have been down this road too, I would love to hear your experience in the comments.

Spec-driven development is having a moment. Microsoft shipped a on using a spec-driven approach with AI coding tools. Tools like are building entire development models around the idea that specs, not code, are the primary artefact. Martin Fowler's blog has a solves this cleanly: MUST means mandatory, SHOULD means recommended, MAY means optional. Adopting this convention costs nothing and eliminates an entire category of misinterpretation. When someone asks "is this behaviour required or just a suggestion", the spec answers the question without needing a conversation.

Further Reading

If you want to explore the current state of spec-driven development, here are the resources mentioned in this post:

Follow or subscribe so you do not miss Part 2. And if any of this resonates with your own experience, or if you think I am getting something wrong, I would genuinely love to hear it in the comments.