Spec-driven development with AI: a guide for client projects
Last updated
What is spec-driven development with AI?
Spec-driven development with AI means writing a clear specification first and treating it as the source of truth an AI coding agent builds from, instead of steering the agent prompt by prompt. In client projects the spec should come from the client conversation and be approved by the client before any code is generated. The approved spec, not the chat history, decides what gets built.
AI coding agents changed how fast software gets written, and also how easily it drifts. Prompt by prompt, an agent makes hundreds of small decisions nobody wrote down. That works for a weekend experiment. It does not work when a client is paying for a specific result and will judge the project against what they asked for.
Spec-driven development, sometimes shortened to SDD, puts a written specification in front of the code. Plenty of material explains the idea in general terms. This guide covers the client-work version: where the spec should come from, who has to approve it, and how it then drives the AI build. If you need a starting file, use the PRD template for Claude Code and Cursor.
Step by step
- 1
Capture the client conversation
The requirements for a client project live in the discovery call. Record or transcribe it, so the spec can be written from what the client said rather than from what you remember.
- 2
Write the spec from the call
Turn the conversation into a spec: project type, goals, users, prioritized features, data, UI direction, out of scope, assumptions and open questions. The meeting transcript to PRD guide walks through this step by step.
- 3
Get the client to approve it
Send the spec to the client and resolve the open questions. Their approval turns your interpretation into the agreed baseline, which is what makes the rest of the process safe to automate.
- 4
Plan the build from the spec
Break the approved features into small, ordered tasks. Some teams ask the agent to propose this plan from the spec, then review it before any code is written.
- 5
Let the agent build feature by feature
Give the agent the spec and one task at a time. Review each result against the spec before moving on, so mistakes are caught while they are small.
- 6
Change the spec first, then the code
When the client asks for something new, update the spec, get it approved as a change, and only then ask the agent to build it. The spec stays the single record of what was agreed.
Spec-driven development vs vibe coding
Vibe coding means describing what you want in conversation and accepting what the agent produces, adjusting as you go. It is fast and fun for prototypes, but the decisions live in a chat history that nobody reviews and nobody signs.
Spec-driven development keeps the speed of an agent but moves the decisions into a document. The agent still writes the code. The difference is that it builds against an agreed spec, so you can check its work, restart a session without losing context, and explain to a client exactly why something was or was not built.
Why client projects need a client-approved spec
In product companies, the spec is usually written by the team that builds the product. In client work, the person who decides what is right is someone else: the client. A spec written from your own assumptions, however detailed, can still be the wrong spec.
That is why the spec for a client project should come from the client conversation and be approved before the agent starts. It protects the budget, because new requests are visibly outside the approved spec. It also protects the relationship, because the client recognizes their own words in the document the build follows.
Spec-driven development tools, and where TaskyTrack fits
Several frameworks help structure spec-driven work inside the repository. GitHub Spec Kit, for example, gives an AI agent a workflow that moves from a specification to a technical plan to a task list. Tools like this work on the spec once you have one.
TaskyTrack works one step earlier, on getting the right spec in the first place. It drafts the spec from the client call with an AI PRD generator, you edit and approve it, and then you hand it to the agent as spec.md, as a ready-to-paste prompt, or over the MCP connector on Pro and Max. From there, the coding agent (and any spec framework you use) builds from an approved document. See how TaskyTrack hands specs to AI coding tools.
Key takeaways
- Spec-driven development makes a written spec, not the chat history, the source of truth for an AI build.
- For client work, the spec should come from the client conversation and be approved by the client.
- Change the spec first, then the code, so the agreed scope and the build never drift apart.
Frequently asked
What is spec-driven development?
It is a way of building software where a written specification comes first and acts as the source of truth. With AI, the coding agent builds from that spec instead of from a series of ad hoc prompts, and changes go through the spec before they reach the code.
Is spec-driven development the same as vibe coding?
No. Vibe coding steers an agent through conversation and accepts the result as you go. Spec-driven development agrees the requirements in a document first, then has the agent build against it. Many teams vibe code a prototype and switch to a spec for the real build.
What are some spec-driven development tools?
Frameworks such as GitHub Spec Kit structure the spec, plan and task steps inside your repository. TaskyTrack covers the step before: writing the spec from the client call and getting it approved. Most AI coding tools, including Claude Code and Cursor, can follow a spec file in the repo.
Does spec-driven development work with Claude Code and Cursor?
Yes. Keep the spec as spec.md in the repo and reference it in your prompts or project rules. The PRD template for Claude Code shows the sections that help an agent most.
Who writes the spec in a client project?
Whoever runs the discovery call, usually the agency lead or the freelancer, but the content should come from the client and be approved by them. An AI tool can draft it from the call transcript to save time.
Is spec-driven development worth it for small projects?
Usually, yes, because the spec can be short. One or two pages that list the features, what is out of scope and the open questions is often enough, and it prevents the most expensive kind of rework: building the wrong thing.
Related guides
- How to turn a meeting transcript into a PRD
- PRD template for Claude Code, Cursor and vibe coding
- Client discovery questionnaire for web and app projects
- Website requirements document template
- How to prevent scope creep on client projects
- Is there an AI tool that turns client calls into product specs?
- Scope of work template for software development
- Functional specification document template (and how AI fills it)
- How to deploy a client project using AI in seconds
Get practical guides by email
Occasional, useful tips on turning client calls into build-ready specs. No spam. Unsubscribe anytime.
Turn your next call into a spec
Free to start. No card required.