bybrandonbrown With the release of Spec Kit from GitHub, the term Spec Driven Development, or SDD for short, is now gaining some ground. Oddly enough, in their own documentation of SDD they use a term I feel will better describe the workflow expectations of an AI tool-based workflow: Intent-Driven Development.
What Is Spec Driven Development
From Spec Kit:
Spec-Driven Development flips the script on traditional software development. For decades, code has been king — specifications were just scaffolding we built and discarded once the “real work” of coding began. Spec-Driven Development changes this: specifications become executable, directly generating working implementations rather than just guiding them.
This, in my opinion, sounds like good software building practice. Building a set of specifications for work has always been a key part of any collaborative effort. Maybe this is where I am missing the point- is the use of this term meant for a more “solo-dev supported by AI” future?
Even in this solo-running future, spec would still be the best way to start before writing a single line of code meant to ship. I get it, many of us will build v1 on experience and a good coffee because the focus has been for sometime now, being first to market.
Now AI changes that equation. When everyone can Vibe Code their way to a fast release, what’s the plan and patterns to follow to be the one that lands in the market at the right time, with a codebase that actually works.
So, writing specs has always been put-off or thrown out in many smaller, more start-up oriented businesses, but eventually we all come back around to writing spec first. “What went wrong” we say at the beginning of a general post-mortem:
“If we had only realized we needed to zig before we zagged.”
“I wish I knew X was going to build this way, so Y could have worked on something else entirely.”
“Somehow, Palpatine returned.”
We’ve all seen the outcomes of failing to plan or not spotting the gaps in our planning. We’re only human, after all.
Intent Driven Development
Working with AI in today’s toolset is inherently conversational. There are pipelines, workflows, architectures, and other abstractions that may connect behind the scenes in your organization or applications, but most interactions are being triggered by “human-like interactions.”
Thinking in this way, how would I respond to another person who did something wrong, not to spec, in real-time.
“Go back and look at the spec.”
Wow, okay, thanks for the help, bro.
“That’s not what I intended”
“Oh, what did you intend with”
reads spec back to the person who wrote it
“Well, not that. Here’s what I meant.”
Hey, that was great! A quick clarifying discussion that brought the problem into context and prompted the author of the spec to reconsider how they communicate so future specs are more accurate.
This focus on intention seems to be more honest of the workflows and the reality of interacting with human-language and AI tools.
Flip The Script
Working with AI tools puts us in the position of interacting with codebases and other mediums through the communication of a set of intentions, not necessarily a spec.
A spec doc could be an outcome of this work, but it’s not the goal of the work. A spec can help to clarify the intentions of my prompts, but it isn’t any good until a prompt triggers the need for it.
The goal of the workflow pattern is to clearly outline the intention of your prompts and how you expect the AI tools to react to your requests.
I believe people are excited and frustrated by the tools in the AI ecosystem right now based on their capabilities in clearly defining their intentions to the models they’re working with. From my point of view, working with AI to create a codebase is Intent Driven Development.