A common question from engineering leaders before trying Spec-Driven Development (SDD) is short: how much does it show? So far we have explained the method. This insight tells what happened on two real tickets from a development team we work with, with their numbers and with what we cannot say from them.
The idea this insight defends: on those two tickets it was not only the time that changed: the team reached a level of testing and validation it had not reached before. And since there are only two, we do not ask you to take our word: we give you the exercise so you can estimate it with your team and check it.
The two tickets
These are two tickets from a development team we work with. We do not say who the client is or what sector it is in, so it cannot be identified. These are the times, as we recorded them:
These are two tickets, not a study. There is no average, we do not extrapolate them to the work of a whole team and we do not know how much of the difference is due to the method, how much to the context that was prepared and how much to the team's own way of working. The estimate is the team's forecast, not a measurement, and the one telling it has a stake.
What the actual time includes
The 1 hour and the 3 hours are the complete work on each ticket, not just writing code. And that work included a level of testing and validation the team had not reached before. It is the fact we care about most: it did not take less time at the price of checking less, it took less time and was checked more, both at once.
So if your team measures only hours, it measures half of it. Measure also what was checked: tests added, validation done, what reached review. It is the line of what to measure in an AI development team: delivery and quality, not lines of code.
Who did it and who estimated
The work was done jointly with the client's team, not on our own: with the full project documentation as context and with the agents and skills we normally apply (skills are reusable instructions the agent follows on every task: how to specify, how to test, what to review). The team worked with the method and onext accompanied it. The 9 and 50 hour estimates were made by the team that usually works on these tickets, in its usual way of working.
Why we think it happened
This is our reading, not a measurement. We do not think the agent types faster. We think the spec sets out what has to change and how it will be checked before any code is touched, that the agent works inside that frame and that a person decides where there is risk. It is the method we describe in AI-Accelerated Development.
There is also work where the method pays off less: a trivial change does not need a spec. We develop that in when SDD pays off and when a spec is overkill, with data from a third-party study. This insight is the complement with our own data, little of it and with its limits.
Check it with your team
We do not ask you to rely on two tickets. We suggest an exercise in two steps to get your own numbers:
- Download the exercise and estimate it with your team. It is in the workshop example repository and in the slides as a PDF. Estimate it as you would any task, in your usual way of working, and write the figure down before you start. Write down what it includes too: testing, validation, review.
- Check it in the online workshop on Thursday 26 November (16:30–18:00, free, 90 minutes). Do the exercise yourself and sign up for the workshop. If you prefer to do it on your own, the repository explains the setup.
Two tickets prove nothing general. They are a reason to measure it on your team: with your estimate beforehand, with the testing you do today and with what happens when you do it from the spec.
Where to go next
If you want to compare notes with someone from outside, the diagnostic is free. If you are interested in how to write specs that can be checked, we cover it in your spec is already an eval and, on the TRGCON workshop, in TRGCON 2026: thank you for the welcome and the debate.
Frequently asked questions
How much time does SDD save?
We do not know in general, and two tickets cannot tell us. On the two we describe, this happened: a ticket estimated at 9 hours by the team that usually works on it was resolved in 1 hour in total with spec-driven development, and another estimated at 50 hours was resolved in 3 hours in total, both with a level of testing and validation that team had not reached before. They are two tickets, not an average, and we do not extrapolate them to the rest of the work.
Who made the 9 and 50 hour estimates?
The team that usually works on these tickets, in its usual way of working. We did not make them.
What does the actual time include?
All the work on each ticket, with a level of testing and validation that the team had not reached before. In other words, it took less time and was checked more, at the same time.
Who did the work?
It was done jointly with the client's development team, with the full project documentation as context and with the agents and skills we normally apply. The team worked with the method and onext accompanied it.
How can I check it with my own team?
Download the workshop exercise (example repository and slides), estimate it with your team as you would any task, write the figure down before you start and then do it with the method. You can do it on your own or in the online workshop.
When is the online workshop and how much does it cost?
On Thursday 26 November 2026, from 16:30 to 18:00. It is free, lasts 90 minutes and has room for 27 people. Registration is on the workshop page.
Sources
- Data for the two tickets: onext and the development team we work with. We do not publish the detail so the client cannot be identified.
- TRGCON 2026 SDD workshop (software development conference, Madrid): example repository and slides (PDF).
- There are no external sources: this insight reports onext's own data and cites no third-party studies.
Bernat López is founder and CEO of onext, an AI boutique. He helps development and product teams work with AI with method —specification before building, a person who decides where there is risk and Spec-Driven Development— and applies to his own company what he proposes: onext runs on its own agentic system.
LinkedIn →