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:
- Architecture
- Systems
- Security
- Data structures
- User requirements
- Hardware and infrastructure
- Server-side behaviour
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:
- What do they want to do?
- How do they interact with the system?
- What are their goals?
- What does “good” look like from their perspective?
At this stage, you’re not telling the AI exactly how to build it.
You’re giving it:
- Direction
- Context
- Constraints
- Intent
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:
- You get more consistent outputs
- You reduce drift
- You avoid rework
- You get closer to what you actually want
It also helps you think ahead.
You can define:
- How the system should scale
- Where it might break
- What risks exist
- What constraints must never be violated
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.
Agentic (AI created research and content)
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.
What Spec-Driven Development Actually Means (In Plain English)
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:
- Faster alignment across functions
- Fewer hidden assumptions
- Better governance, because decisions are recorded
- More predictable delivery, because work is chunked and testable
Why This Reduces Drift In Agentic Workflows
If you are building an agentic workflow (a system where AI takes actions across tools and steps), drift is expensive.
It shows up as:
- The AI “helpfully” doing the wrong thing
- Teams re-litigating decisions every sprint
- Silent scope creep, because nobody can point to the source of truth
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:
- Product can validate
- Legal and security can review
- Delivery can estimate
- AI can use as operating context
The Counterpoint Leaders Should Take Seriously
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”.
A Leadership-Level Way To Run Spec-Driven Work (Without Slowing Down)
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:
- Intent
- What problem are we solving?
- What decision or action changes because of this?
- Users And Context
- Who is it for?
- What do they do before and after this exists?
- Boundaries
- What must the system never do?
- What data must it never access or expose?
- Success
- What does “good” look like?
- What is the acceptance test in plain English?
- Workflow
- What are the steps?
- Where does a human approve, override, or escalate?
- Tooling
- What systems are in scope (for example HubSpot, Airtable, Xero)?
- What is read-only vs write access?
Then make it operational:
- Put the spec somewhere visible and versioned.
- Review it in the same cadence as delivery.
- Treat changes as learning, not failure.
When Spec-Driven Development Is Overkill
You do not need heavy specs for everything.
It can be too much when:
- You are exploring a brand-new use case
- The cost of being wrong is low
- You need quick signal before investing
In those cases, prototype fast.
But still write down:
- The intent
- The constraint you cannot break
- The one thing you want to learn
That keeps experimentation safe and useful.
Practical Next Steps You Can Do This Week
If you lead a team building with LLMs (Large Language Models), try this:
- Pick one AI initiative that is wobbling.
- Run a 45-minute spec workshop with the people who keep getting surprised.
- Leave with:
- One page of intent, constraints, and success
- A simple diagram of the workflow
- A decision on who owns the spec
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.
Links
- No validated links were provided in this run.
Quotes
- “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.”
- “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.”
- “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.”
