Spec drive development is the formalization of a way of working for building software at a enterprise level. There are other varieties such as Test Driven Development or Design Driven Development.
Majority of places I have worked where we are building software applications it has been very much Design Driven Development. Developers following figma designs was the general trend up until 2026.
That is till now where we have AI-driven Software Development Life Cycle.
As a vibe coder I use feature driven development. Spec driven I believe is more enterprise level methodology. Product people I believe you need to live in the context area. That is going love a lot different than what you were used to but you need to adaptable to change.
I have numerous thoughts on this….
Table of Contents
Firstly this jump happened as agentic coding systems have got better. The biggest shift is AIs ability to generate credible UI quality designs. What has enabled this step jump in ability is the design plugins.
They also have provided a framework to help people to actually do spec driven development or they like to call it feature driven development with another plugin:
Feature Dev – Claude Plugin | Anthropic A structured 7-phase workflow for building features systematically. Rather than jumping into code, this plugin guides you through understanding the existing codebase, clarifying requirements, designing architecture thoughtfully, and conducting quality reviews before and after implementation.
Spec Driven Development + Tech Lead = 100x
My first time really seeing what Vibe Coding is like in the hands of a senior developer and what he produced is mind blowing.
A recent project of mine failed UAT. Not a huge surprise as we had make several compromises to get something out the door a month earlier than planned.
We were given a 2 weeks to rectify.
We had a team meeting and the tech lead gave me a ultimatum. I can spend the weekend fixing bugs and trying get what we have to work or I can use Kiro to rebuild it from scratch.
It was zero sum as him working over weekend was a bonus so we called it Project Hail Mary.
What we had originally built worked but wasn’t user friendly – it was an excellent prototype that helped us understand the flows and what the jobs the users were trying to do.
He got a large spec created detailing problems, architecture, solutions etc to completely refactored application, turning a fairly basic single-function application into a visually rich workflow targeting three different users, including a complex drag-and-drop scheduler and an outlook-style calendar view.
- Application was completely retooled, including a web sockets-based data synchronization engine.
- New three-screen-based UI and workflow for a drag-and-drop-based schedule calendar view, work order request sidebars, and work order request screens are all new features.
- Brand new data model.
- Full test suite.
- New CI/CD approach for loading complex deployment of multiple applications in the Reality Hub suite in different configurations.
Completing work that normally would take a developer four to six months in a single week. Has now turned into a solid workload at a team, and developers can use it to deliver consistent value and increase pace and quality.
That said….
- Created a lot of tech debt
- Not seen same productivity for all developers
- Confusion how to estimate and complete work.
More on spec driven development
Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl
Two-pizza teams are dead.
It’s going to go on to one-pizza team or even a sandwich team or some sort of equivalent food-related idea. Bag of sandwiches. Big teams are no longer required; small, efficient teams. One engineer and Tropic CPO interview talking about engineer-led teams.
The times of a Figma designer creating software and then developers following bit by bit is gone. Instead, they’ll be writing specs with problem statements and goals and non-goals and acceptance criteria instead of looking at Figma and copying it exactly.
The developers will need to have context and understand what actually is the outcome trying to be achieved.
Training introducing new ways of working.
People will lack identity:
Designers not doing UI
Developers not designing code
BA is not writing requirements
A lot of changes in the way we are working in the team is makeshift. Need to adjust to new ways. Find their new skills, get everyone comfortable with vibe coding practises, and understand what’s happening behind the hood.
Get everyone access to the GitLab, seeing the code and repositories, the specs being created, the plans being made, and the outputs. No black box approach.
Product Owners Role in Spec Driven Development
Creating Context File aka customer insights.
Understanding Skills of Agents for Product Manager
- Creare QRG agent
- Create release notes agent
Jobs to be done Framework IS A MUST
Jobs to be done could be a perfect input from BAs and UX designers. Jobs to be done framework will frame exactly what needs to be done and what they’re trying to be achieved. It’s our thinking about the jobs achieved by the system or the solution instead of trying to couple everything together very smartly.
You Are Not a Product Person If Not Vibe Coding
Claude code and vibe coding using lovable, etc., is a great starting place for people to learn what vibe coding is and understand what actually is happening behind the hood and seeing the results.
With people worried about fixing small bugs that previously might have taken two or three days but now can be done in two to three hours maximum from idea to delivery. Need to understand the increase in time, transparency, and speed.
No longer do screenshots or wireframes do for validating ideas. Prototypes rebuild quickly and easily using the figure main CP or just directly going into it and building something.
Claude Code is Rewiring Software Engineering – Here’s How to Keep Up | V2 AI
It doesn’t work in the backend but looks and feels right to quickly validate the look and feel using vibe coding.
Is this the designer learning, or is this the developer going in front of the customer and being able to speak to them, understand their problems and pain points, and be able to take that, without doing everything, to put something in front of them to get quick, iterative feedback?
We lost weeks, months using screenshots instead of a prototype, which was initially rejected. Are you ready?
Product roadmaps Need Focus on OKRs not FEATURES
- How do you build project schedules and road maps and story plans based off this?
- If you can complete a feature in a day, you could build the product in a week.
- How are we supposed to build out three-week and three-month plans and QPRs and road maps that the business wants?
- Maybe we move to milestone-based planning instead of actually decomposing work and trying to estimate stories to a story plan and sprinting. Is sprinting dead?
- Is Scrum dead? Is it better to make more sense to use Kanban or a defined definition of activity or milestone and work towards that in small, quick iterative respects?
ML Ops as a framework is a work looking into an ML Ops kind of approach.
Should We Reduce Handovers From User to Dev
Going to be moving from managing how do you manage expectations when they think you can just do everything overnight, or if you actually do everything overnight?
- Do you just drip feed features?
- Do you just show what you can? How do you best approach it?
- Expectations can be changed very quickly, or what they want and need.
- Handoffs should be reduced dramatically from customer to BA to UI to developer to tester to UAT to go live. Could you do it?
- How many of those steps could you cut out?
Could the developer talk straight to them?
Who develops the skill set? The developer or the BA/UI?
Does the developer have the people skills? The product knowledge to see through what’s important and what’s not important?
Does the BA have the coding skills to be able to see what the agent is giving back that actually is right, or if it went off in its own thing the wrong way?
Reducing new issues, tools for using for 10x, but also reducing handovers to us to compromise