Spec-driven development means writing a precise description of what your software should do before writing any code. With AI coding agents like Claude Code and Cursor, this matters more than ever. These tools will build what you describe, not what you meant. A clear spec gives them the context to produce accurate output and makes results straightforward to verify.
For agencies, an early spec also has commercial value. The faster you produce a solid spec, the faster you can quote, and a reliable estimate often decides whether you win the project.
The tools that got us here
We started exploring tools like BMAD, which structures development around a sequence of planning artifacts like product brief, PRD, architecture document, and sprint stories. It forces you to think before you build and gives coding agents structured context at every phase. When multiple developers came together on the same project, the spec evolved, and we needed a simple way to keep track of changes.
So we started using OpenSpec as a lightweight spec layer that sits alongside your code, helping teams agree on what to build before the agent writes a line. It works with most major AI coding assistants and keeps everything version-controlled in your repo.
When we adopted these spec-driven practices, the difference was felt. Agents stopped guessing and output quality went up.
But as our projects grew, we hit a ceiling neither tool was designed to solve, especially for agencies.
Collaboration and the alignment tax
In a real agency engagement with multiple team members, a client, and several agents running in parallel, it breaks down fast. A client changes a requirement in a call. A developer discovers a constraint mid-build. A non-technical stakeholder has questions.
The spec becomes a snapshot. The project moves on. Nobody has a clear process for proposing changes or making sure everyone is working from the same current version. You rush to organise daily standups and meetings, your pace slows down, and you are back where you started.
We call this the alignment tax. By the time someone notices, the estimate is fiction and the client is about to get a surprise they didn't budget for. AI agents make this worse, because they move fast. An agent builds confidently from whatever context it has, even if that context is three weeks out of date. Planning becomes the bottleneck, and all the gains from AI-assisted coding are lost.
How we solved it
The missing piece isn't a better spec format. It's governance.
- Treat the spec the way you treat code, with version control, branch proposals, review, and approval
- Give non-technical stakeholders a way to participate without needing to understand Git
- Follow structured planning and employ AI agents to move faster through it
- Connect a living estimate to the current scope so it stays accurate as requirements change
- Let developers and coding agents bidirectionally pull and edit context via MCP
If you're building with AI coding agents, it doesn't mean you're going to build the right thing. If your agents are guessing, be it very fast and confidently, you can still burn through the budget quite fast.
