This is my unpopular take on Spec Driven Development.
Most developers I talked to are doubling down on it. AWS is definitely putting emphasis on it with Kiro, and I do understand why.
Look, I still use Plan Mode and don’t prompt without thinking, providing a lot of context and having a conversation to raise the best course of action.
But I still keep it a short cycle and emphasize getting something out quickly, rather than spending all my time writing a full spec and missing the flexibility and magic of AI coding agents.
The promise of spec-driven development (unabridged)
The idea behind spec-driven development is that before handing off a task to your coding agent, you should spend most of the time planning out the task and feature all the way through. Pretty much thinking of everything up front, adding all of the relevant context, and then handing it over.
Then, by the time the coding agent finishes work, you can close the Jira ticket and call it a day because you thought through and planned everything.
Of course, thinking and planning involve a session with the coding agent to uncover things about the tasks. For example, a few security approaches and things that would otherwise slip under your human radar.
It also forces you to write, which is a great way to clarify your thinking (which I am a big fan of, btw - it’s an underutilized tool).
So you start with a long planning session, then do more planning, then a little more, and finally hand it over. Maybe add goals and loops?
Perfect.
Spec Driven Development also advertises a few benefits:
- Lower token usage - because you need fewer iterations as you already solved all of your problems ahead of time (work with me here). So cost is down. Sweet.
- One-shotting the task. Just send and forget.
- Reduced chances for bugs and issues.
- It makes you look good - writing a lot of specs and quickly closing tickets.
Well, that’s the premise.
My case against Spec Driven Development
If I haven’t upset you by now, now is my chance to double down.
One thing that you should keep in mind, and probably won’t want to, is that A LOT of code you will write during your career is not going to see the light of day or actually be used.
I’m sorry, but that’s the reality, no matter how proud we are as software developers.
And that’s for a few reasons that stem from building the wrong thing:
- Most startups build the wrong thing and die.
- A lot of product features are not going to be used by users.
- If your product team is doing their job, a lot of the features you write will get redesigned and rewritten.
- A lot of features get left out of releases and die because they don’t actually make sense.
It’s frustrating, and I’ve been there so many times.
AI’s gift
The greatest gift that AI agents have given us is shortening the feedback loop.
The artifacts are part of the conversation.
That means that we can have an idea and actually see it working within minutes or hours. It might not be perfect, but we can understand how it works and if it makes sense.
There are many unknowns when creating software. And while plan mode helps clarify things, it is still driven by your initial understanding of the task.
I think AI lets us get to the point quickly, see if the task makes sense, and shape it fast.
Lower token usage and lower cost? Not if you figure out you built the wrong thing. Or worse, if sunk-cost bias kicks in and you keep the feature as is because you’ve already spent a lot of time on it.
The most expensive tokens are the ones you didn’t spend discovering you were wrong.
Fewer mistakes? Again, what about building the wrong thing? Or not realizing the UX should be different? Or that you haven’t fully understood how the feature will be used and missed out on important security aspects.
At TopoReady, I worked on several flows for working with various AWS architectures.
For me, the best feature of working with the AI coding agent was that I was able to try it on first. I spent little time in plan mode, mostly talking about my vision for a flow, then giving it a few of my best practices and security concerns, which you can always have as skills and context files, and then let it run.
In many cases, I found out that I was completely off with how I thought things should be, and because it didn’t take long to get there, I wasn’t attached to the feature.
Or maybe I was misunderstanding how an integration works, and the AI just went along with me without raising a red flag.
Once I knew I had built the right thing, it was easy to do more fine-tuning.
I’m not presumptuous enough to think that my spec is going to hit the mark the first time.
Maybe it’s just my style, and what makes me way more productive, and for some engineers, spec-driven is the way.
I see Spec-Driven development as a bit like forcing old paradigms onto new ones because AI is scary.
Now you may say that you work in a big team, that you get hard requirements handed down from Product, and that you have no say in it. Well, that’s why I also think that means your organization is bloated or not structured for the new way of working. Mostly just trying to preserve the good old times.
If spec-first is genuinely working for you and you’re shipping the right things, I want to hear it.