I’m writing this because I keep seeing the same pattern in AI projects.
People jump in and start coding or prompting without spending enough time upfront on what actually matters.
After working on a lot of AI projects, specification-driven development has become my default approach. It’s served me well, especially on the projects that matter most.
You spend most of your time upfront thinking carefully.
Not coding.
Not prompting at random.
Defining what you actually need.
That means getting clear on:
All of it needs to be organised and structured first.
Only when that’s in place do you move to the next layer.
Then you start considering the user:
At this stage, you’re not telling the AI exactly how to build it.
You’re giving it:
You can use diagrams, examples, or rough sketches. Anything that helps the system understand what you’re trying to achieve.
Here’s the key point.
You’re not prompting in isolation.
You’re building a structured environment for the AI to operate in.
That changes everything:
It also helps you think ahead.
You can define:
That thinking gets baked in early rather than patched later.
Once all of that is set, you can step back and say, “This is what I want to build now.”
At that point, AI becomes far more useful.
Not as something you experiment with, but as something you direct with intent.
A small note of caution.
This isn’t always the best way for every situation.
It’s the best method for complex, multi-system, long-lived builds.
It can be overkill for small tasks or rapid prototyping.
So I’d say this.
Specification-driven development is the most effective approach when you actually care about building something that lasts.
Leaders keep asking me the same question: “Why does our AI work feel unpredictable?”
Here’s the thing.
A lot of AI delivery problems are not model problems. They’re clarity problems.
When the team does not share a single, explicit view of intent, constraints, and success, the AI becomes a mirror. It reflects the ambiguity back at you, at speed.
Spec-driven development (often shortened to SDD) is the habit of writing the plan before generating the output.
Quoc Viet Ha puts it cleanly:
“Spec Engineering, also known as Spec-Driven Development (SDD), is an approach to coding with AI where you first prompt the AI to create a comprehensive plan or "spec" before generating the actual code. Think of it like creating blueprints before building a house.”
From a leadership perspective, the value is less about “better code”.
It’s about:
If you are building an agentic workflow (a system where AI takes actions across tools and steps), drift is expensive.
It shows up as:
Aaron Lazar captures the shift you want:
“Instead of starting with code, SDD forces you to start with intent. Clear requirements. Explicit constraints. A shared spec that both humans and AI can reason about. Suddenly, AI stopped guessing and started executing.”
That line “shared spec that both humans and AI can reason about” is the leadership win.
It creates a single artefact that:
There is a fair critique of spec-first approaches.
Kent Beck raises a concern that matters for any long-lived build:
“The descriptions of Spec-Driven development that I have seen emphasize writing the whole specification before implementation. This encodes the (to me bizarre) assumption that you aren't going to learn anything during implementation that would change the specification.”
I agree with the spirit of that.
If your spec becomes a frozen document, you will ship the wrong thing with confidence.
So the practical move is not “spec once”.
It’s “spec, build, learn, update spec”.
If you want the benefits without the bureaucracy, keep the spec lightweight and alive.
Use this as your minimum viable spec (MVS) for AI projects:
Then make it operational:
You do not need heavy specs for everything.
It can be too much when:
In those cases, prototype fast.
But still write down:
That keeps experimentation safe and useful.
If you lead a team building with LLMs (Large Language Models), try this:
Then iterate.
This stuff is genuinely hard, especially when everyone is under pressure to “move faster”.
The quiet advantage is that spec-driven work often makes you faster anyway.
Not because the AI is smarter.
Because the team is clearer.