Spec-Driven Development Tools Are Solving the Wrong Problem
I have been experimenting with spec-driven development (SDD) tools lately, and I keep running into the same issue. These tools are built for a workflow that does not exist in most organizations.
If you are not familiar with them, SDD tools are AI-powered systems that interview you about what you want to build, then generate detailed specs and PRDs before you write code. Frameworks like BMAD and Agent OS are popular examples. The promise sounds good: think through your solution first, get AI to help structure it, then implement with clarity.
The concept is sound. The execution misses the mark for most teams.
The Product Organization Problem
Here is the fundamental mismatch: SDD tools are designed for developers sitting at the CLI, answering AI questions to generate specs. But in most companies, product requirements come from a product organization upstream of engineering.
Think about your typical workflow:
- Product owner writes requirements in Jira, Linear, or Notion
- Those get reviewed, prioritized, and groomed
- Eventually they land on an engineer's desk
- Engineer implements
Now insert a SDD tool into that flow. Where does it fit?
The tool wants the developer to sit at the terminal and describe what they are building. But the developer is not the one defining what to build. That came from product. So now you have two parallel specification processes: product defining requirements in their tools, and a developer creating AI-generated specs in the codebase.
These do not sync. They drift. The SDD spec becomes one more document that does not match the Jira ticket, which does not match the actual implementation.
The Tooling Assumption Problem
SDD tools assume the developer is the product owner. They are designed for solo developers wearing every hat. Product manager, architect, developer, QA.
That is a valid use case. If you are a solo founder building your MVP, SDD might help you think through requirements before coding. But that is not how most software gets built.
In a real organization, asking product owners to abandon their existing workflows and jump into the codebase to use CLI tools is a non-starter. They have their own processes and their own stakeholders. They are not going to start using spec-gen or whatever CLI tool you found on GitHub.
So you end up with a tool designed for solo developers, marketed to teams, creating friction in actual product workflows.
What We Should Be Building Instead
Specs are not the problem. Specs are great. The problem is that SDD tools insert themselves in the wrong place in the pipeline.
Instead of asking developers to re-specify what product already defined, we should be using AI to strengthen the processes that already exist. That means meeting product organizations where they are.
Product owners write PRDs, user stories, acceptance criteria, and technical requirements in tools like Jira, Asana, Linear, and Notion. AI should help them write better versions of those documents, not replace their tools with a CLI.
In any real product organization, there are multiple artifacts floating around: the PRD, the technical design doc, the user stories, the acceptance criteria. These drift apart over time. AI is good at flagging when two of those documents disagree. "Your PRD says the API returns paginated results, but the user story says it returns everything at once." That kind of consistency checking is where AI actually adds value to product workflows.
Once the specs are solid and aligned, AI can help break them down into implementation tickets directly in Jira, Asana, or whatever tool the team already uses. Not in a separate SDD system. In the tool that already exists.
On the engineering side, this is where MCP servers and CLI skills come in. I write skills for Claude Code that use glab or gh to fetch issues directly from GitLab or GitHub. The AI reads the ticket, understands the requirements, and starts implementing. No parallel specification process. The source of truth is the ticket that product already wrote and approved.
The idea is straightforward: AI helps product write better specs in their tools, and AI helps engineering consume those specs in their tools. One source of truth flows through the whole pipeline.
When SDD Tools Actually Work
I want to be fair. There are cases where the SDD model fits.
If you are a solo developer wearing all the hats and you are thoughtful about tooling, SDD can help you think through edge cases before coding, structure your approach, and generate documentation.
Some frameworks are evolving in the right direction. Agent OS v3 recently retired its implementation and orchestration phases entirely. The developers recognized that frontier models handle spec implementation well on their own, and that features like plan mode in Claude Code are how most people do SDD now. Agent OS v3 focuses on establishing and injecting development standards. It enhances plan mode with targeted questions that consider your standards and product mission, rather than trying to replace the entire workflow.
That is a healthier approach. Do one thing well and integrate with what developers are already using, rather than trying to be the entire pipeline.
This Is Short-Term Advice
I want to be honest about something: everything in this article has a shelf life. The AI landscape is moving fast, and as these tools approach AGI-level capabilities the boundaries between roles will blur. The workflows I am describing here will probably look quaint in a couple of years.
But right now, in the short to medium term, I do not think we should be condensing all the roles down into one. Product owners, architects, and developers exist for good reasons. Their separation of concerns is not bureaucracy. It is how organizations manage complexity at scale. The right move today is to make AI a force multiplier for each of those roles individually, not to collapse them all into a developer sitting at a terminal.
That will change. When it does, I will write about it.
Final Thoughts
SDD tooling has a place, but it is much smaller than the hype suggests. The current generation of tools is designed for a workflow where developers are also product owners, and that is not most teams.
Product organizations have existing processes. Those processes exist for good reasons. Instead of replacing them with a CLI tool, make AI better at the things each role already does.
If you are considering SDD tools, ask yourself: does this fit my organization's workflow, or does it create a parallel process? Am I the target audience (solo dev), or am I trying to force a team fit?
Make sure the tool fits your actual workflow, not the workflow the tool wants you to have.
Have you tried integrating AI into your product workflow? What worked and what did not? I am curious how other teams are bridging the gap between product and engineering with AI tooling.