Quo vadis Spec-Driven-Development
Are we heading in the right direction after vibe coding?
Introduction
Ever since I embraced AI-assisted software engineering, there's been one constant shaping my workflows, thinking, and experiments: the adoption of human interaction patterns when working with AI assistants. My conversation-first approach - as I've come to phrase it - dramatically helped me both embody Amazon Q Developer in my workflows while improving my efficiency. This became central to getting better at context management and prompt engineering, all surrounded by a phase of AI-assisted adoption that was mostly dominated by vibe-coding approaches.
My paradigm of adopting AI in software engineering by imitating human collaboration isn't bound to just that realm. This is my personal best practice for adopting AI in many domains.
Take a recent use case I worked on with a team at Bundesliga about using AI to assist in copywriting marketing campaigns. The initial attempt by the team was just arguing that we needed to pick the latest frontier model and hope for the best. My learnings draw a different picture. The differentiator isn't the model itself, but your ability to provide the right context, the right data, and the right instructions. A mix of context management, data foundations, and prompt engineering.
So I asked: What do human copywriters need to create a world-class tagline for a marketing campaign? The answers to that question are exactly what you need to provide to the AI to get a similar world-class experience.
And this is exactly what works with software engineering. What do teams need to build comprehensive and detailed specs to reduce time to market?
The Evolution from Vibe Coding
With spec-driven development, we're making the next evolution in AI-assisted software engineering. The following quote is from GitHubs Spec-Kit and from my perspective on point:
Spec-Driven Development flips the script on traditional software development. For decades, code has been king — specifications were just scaffolding we built and discarded once the "real work" of coding began. Spec-Driven Development changes this: specifications become executable, directly generating working implementations rather than just guiding them.
But here's what's been nagging at me: my current workflow doesn't feel "realistic" if I take human collaboration as the baseline. My current specification-driven development workflow is a three-phase process where I give input to a single agent to create detailed technical specifications, break them down into implementation plans, and execute step-by-step with comprehensive context management through what I call "Project Intelligence." I've written extensively about this approach, and it has been transformative for me.
However, I see a problem we might be running into.
The Single-Perspective Trap
How were specs created in our human world before AI entered the field? Multiple people with different roles collaborate: product managers bring market understanding, architects contribute technical constraints, UX designers add interaction patterns, security engineers raise compliance factors, DevOps engineers highlight operational considerations, and QA engineers anticipate edge cases. Each perspective makes the specification more comprehensive and implementable.
How are specs created with AI-assisted software engineering today? One person enters input to one agent.
For me, this feels fundamentally incomplete, but I didn't fully understand why until I started adopting the spec-driven approach. Despite detailed specification conversations with Q Developer, comprehensive Project Intelligence context, and structured prompt frameworks, I kept discovering critical requirements during implementation that felt obvious in hindsight:
Security implications I hadn't considered
UX patterns that conflicted with existing flows
Operational complexities that would emerge at scale
Testing scenarios that weren't obvious from business requirements
These weren't process failures—they were natural blind spots that emerge when any single perspective tries to capture the full complexity of a software system.
The collaborative approach I was craving is also constrained by current technical limitations. Most AI development tools are still designed around single-agent interactions. While custom agents offer specialized knowledge bases, they operate independently without a native capability for agents to build upon each other's insights or challenge assumptions.
Interestingly, Claude Code represents progress toward orchestration approaches that could simulate collaborative team dynamics. But this technical gap between valuable multi-agent collaboration and what's available in mainstream tools creates a forcing function that keeps us in suboptimal workflows, regardless of how sophisticated our prompting techniques become.
Where We Need to Go
The future of spec-driven development isn't about better prompts or more sophisticated single-agent workflows. It's about recreating the collaborative dynamic that makes human specification creation so effective. I see three potential paths forward:
Path 1: Upfront Human Collaboration (this is on us engineers)
Before engaging with AI, assemble cross-functional input. Instead of one person having a specification conversation with Q Developer, have multiple stakeholders contribute their perspective upfront:
Product requirements from the PM
Technical constraints from the architect
User experience considerations from design
Security and compliance requirements from security engineering
Operational requirements from DevOps
Then use this rich, multi-perspective input to drive the AI specification conversation.
Path 2: Multi-Agent Collaboration (this is on the tool vendors)
Leverage specialized AI agents that can simulate different roles and perspectives:
A "Product Agent" that focuses on user needs and business value
A "Security Agent" that raises compliance and risk considerations
An "Architecture Agent" that considers technical design and scalability
A "UX Agent" that thinks about user workflows and interaction patterns
These agents challenge assumptions and surface considerations that a single agent might miss. Most importantly: those agents can work together!
Path 3: Hybrid Collaborative Workflows (this is on us engineers)
Combine human expertise with AI capabilities in iterative cycles. Start with human stakeholder input, let AI agents extend and challenge those perspectives, then bring humans back in to validate and refine.
The Bottom Line
Spec-Driven Development has been a massive improvement over vibe coding, bringing rigor, context, and systematic thinking back to AI-assisted software engineering. But if we're honest about how human engineering teams create specifications - through rich, multi-perspective collaboration - then our current single-person-to-single-agent workflows are still leaving significant value on the table.
I believe the next evolution of AI-assisted software engineering will be fundamentally collaborative. Not just human-to-AI collaboration, but multi-perspective collaboration that mirrors how high-performing human teams actually work. Instead of considering AI assistants as individual tools, we should start thinking about them as participants in collaborative engineering processes.
The question isn't whether we should abandon spec-driven development - it's whether we should evolve it to be more collaborative, more representative of how actual engineering teams work, and more aligned with the patterns that make human specification creation so effective.
What do you think? Are we heading in the right direction, or do we need a more fundamental shift toward collaborative specification creation?
Want to dive deeper into spec-driven development approaches? Check out promptz.dev for a collection of prompts and patterns for AI-assisted software engineering. I'd love to hear about your experiences with collaborative specification creation - reach out and let's continue this conversation.
