Should I always use Spec-Driven Development? (Spoiler: NO)

Hey folks :D

The book about AI-Native Engineering is progressing, and soon we’ll release two chapters on the O’Reilly platform. Stay tuned for free access to these chapters.

The first chapter got 294 comments. The majority were punctuation and formatting, but still, it took me almost an afternoon to address everything 😄

Today I want to discuss something a friend asked me a few days ago:

“Do you think I should always use SDD?”

Short answer: yes… and no 😄

Let me explain.

If you read this newsletter, you’re probably familiar with Spec-Driven Development. The idea is to start from a clear spec and let an AI agent produce production-quality code.

I do believe SDD is extremely powerful, but it is not always the starting point. In some cases, you simply do not have enough information to write a meaningful spec yet.

Let’s say I come to you with a new feature. You do not know how to implement it, you do not know the details, you do not fully understand the constraints. Writing a spec at this stage does not make much sense.

In this situation, what you should do is a technical spike. You explore, you experiment, and you write some quick and dirty code using normal prompting. The goal is not quality, the goal is learning.

Once you have something working, not production-ready of course, you go back to your stakeholders and ask if that is what they actually need.

If the answer is yes, now you can take the code you wrote, the mistakes you made, the edge cases you discovered, and the constraints you uncovered, and use all of that to build a proper spec.

At that point, you keep your spike in a separate branch, something like experiments/my-feature, and you start fresh from main with a clean branch like my-feature. Then you implement the feature properly using SDD.

So in this case, SDD is not skipped. It is delayed until you have enough information.

For prototypes, I usually do not use SDD at all. The goal of a prototype is to showcase an idea, drive discussion, and align stakeholders. Speed matters more than structure.

In this context, rapid exploratory coding, or what people sometimes call vibe coding, works well. The scope is usually small and the focus is on feedback rather than code quality.

Bugs are a bit different. In many cases, you cannot jump straight into SDD because you do not even know what is broken exactly.

You first need to investigate, reproduce the issue, and understand the root cause. Only then you can define what the system should have done, what went wrong, and how to prevent it.

In a way, bug fixing is almost reverse SDD. You reconstruct the missing spec from the system’s behavior. Once you have that, writing a small spec for the fix can be very valuable, especially to track root causes and make the system more robust over time.

For small scripts, SDD can be overkill. If the task is simple and you know what you are doing, I often just write a single long prompt, basically a mini-spec, describing what I want and how it should work.

If everything fits in your head or in one prompt, that is usually enough. But there is a signal I have noticed. If you struggle to keep everything in a single prompt, it probably means the problem is more complex than you initially thought.

That is usually the moment to switch to proper SDD.

So should you always use SDD?

My current mental model is that SDD is almost always useful, but not always the first step. Sometimes you need exploration, experimentation, and investigation before you can write a good spec.

After talking with different colleagues, I have noticed that everyone has slightly different workflows and preferences. I would love to hear your opinion as well. Are there other cases where you would not use SDD, or where you would delay it?