Una pregunta habitual dels responsables d'enginyeria abans de provar el Spec-Driven Development (SDD), el desenvolupament guiat per especificacions, és curta: i això, quant es nota? Fins ara hem explicat el mètode. Aquest insight explica què va passar en dues incidències reals d'un equip de desenvolupament amb qui treballem, amb els seus números i amb el que no podem dir a partir d'ells.
La idea que defensa aquest insight: en aquestes dues incidències no només va canviar el temps: l'equip va assolir un nivell de proves i validació que no havia assolit abans. I com que són només dues, no et demanem que ens creguis: et donem l'exercici perquè l'estimis amb el teu equip i ho comprovis.
Les dues incidències
Són dues incidències d'un equip de desenvolupament amb qui treballem. No diem quin és el client ni el seu sector, perquè no es pugui identificar. Aquests són els temps, tal com els hem registrat:
Són dues incidències, no un estudi. No hi ha una mitjana, no les extrapolem al treball d'un equip sencer i no sabem quant de la diferència es deu al mètode, quant al context que es va preparar i quant a la manera de treballar de l'equip. L'estimació és una previsió de l'equip, no un mesurament, i qui ho explica és part interessada.
Què inclou el temps real
L'hora i les 3 hores són el treball complet de cada incidència, no només escriure codi. I aquest treball va incloure un nivell de proves i validació que l'equip no havia assolit abans. És la dada que més ens importa: no es va trigar menys a canvi de comprovar menys, sinó que es va trigar menys i es va comprovar més alhora.
Per això, si el teu equip mesura només hores, mesura la meitat. Mesura també què es va comprovar: proves afegides, validació feta, què va arribar a revisió. És la línia de què mesurar en un equip de desenvolupament amb IA: lliurament i qualitat, no línies de codi.
Qui ho va fer i qui va estimar
La feina es va fer conjuntament amb l'equip del client, no pel nostre compte: amb tot el context de documentació del projecte i amb els agents i skills que apliquem habitualment (les skills són instruccions reutilitzables que l’agent segueix en cada tasca: com especificar, com provar, què revisar). L'equip va treballar amb el mètode i onext el va acompanyar. Les estimacions de 9 i 50 hores les va fer l'equip que treballa habitualment amb aquestes incidències, amb la seva manera habitual de treballar.
Per què creiem que va passar
És la nostra lectura, no un mesurament. No creiem que l'agent teclegi més de pressa. Creiem que l'especificació delimita què cal canviar i com es comprovarà abans de tocar codi, que l'agent treballa dins d'aquest marc i que una persona decideix on hi ha risc. És el mètode que expliquem a AI-Accelerated Development.
També hi ha feina on el mètode compensa menys: un canvi trivial no necessita una especificació. Ho desenvolupem a quan compensa l'SDD i quan sobra l'especificació, amb dades d'un estudi de tercers. Aquest insight és el complement amb dades nostres, poques i amb els seus límits.
Comprova-ho amb el teu equip
No et demanem que te'n refiïs de dues incidències. Et proposem un exercici en dos passos per treure els teus propis números:
- Descarrega l'exercici i estima'l amb el teu equip. És al repositori d'exemple del taller i a la presentació en PDF. Estimeu-lo com estimaríeu qualsevol tasca, amb la vostra manera habitual de treballar, i apunteu la xifra abans de començar. Apunteu també què inclou: proves, validació, revisió.
- Comprova-ho al taller en línia del dijous 26 de novembre (16:30–18:00, gratuït, 90 minuts). Fes l'exercici tu mateix i inscriu-te al taller. Si prefereixes fer-ho pel teu compte, el repositori explica la preparació.
Dues incidències no demostren res de general. Sí que són una raó per mesurar-ho al teu equip: amb la teva estimació d'abans, amb les proves que feu avui i amb el que passa en fer-ho des de l'especificació.
Per on seguir
Si vols comparar notes amb algú de fora, el diagnòstic és gratuït. Si t'interessa com especificar perquè es pugui comprovar, ho expliquem a la teva spec ja és un eval i, sobre el taller de TRGCON, a TRGCON 2026: gràcies per l'acollida i pel debat.
Preguntes freqüents
Quant de temps estalvia l'SDD?
No ho sabem en general, i amb dues incidències no ho podem dir. En les dues que expliquem va passar això: una incidència estimada en 9 hores per l'equip que treballa habitualment amb ella es va resoldre en 1 hora en total amb desenvolupament guiat per especificacions, i una altra estimada en 50 hores es va resoldre en 3 hores en total, totes dues amb un nivell de proves i validació que aquell equip no havia assolit. Són dues incidències, no una mitjana, i no les extrapolem a la resta del treball.
Qui va fer les estimacions de 9 i 50 hores?
L'equip que treballa habitualment amb aquestes incidències, amb la seva manera habitual de treballar. No les vam fer nosaltres.
Què inclou el temps real?
Tot el treball de cada incidència, amb un nivell de proves i validació que aquell equip no havia assolit abans. És a dir, es va trigar menys i es va comprovar més alhora.
Qui va fer la feina?
Es va fer conjuntament amb l'equip de desenvolupament del client, amb tot el context de documentació del projecte i amb els agents i skills que apliquem habitualment. L'equip va treballar amb el mètode i onext el va acompanyar.
Com ho puc comprovar al meu equip?
Descarrega l'exercici del taller (repositori d'exemple i presentació), estima'l amb el teu equip com estimaríeu qualsevol tasca, apunteu la xifra abans de començar i després feu-lo amb el mètode. Ho podeu fer pel vostre compte o al taller en línia.
Quan és el taller en línia i quant costa?
El dijous 26 de novembre de 2026, de 16:30 a 18:00. És gratuït, dura 90 minuts i l'aforament és de 27 persones. La inscripció és a la pàgina del taller.
Fonts
- Dades de les dues incidències: onext i l'equip de desenvolupament amb qui treballem. No publiquem el detall perquè el client no sigui identificable.
- Taller d'SDD de TRGCON 2026 (conferència de desenvolupament de programari, Madrid): repositori d'exemple i presentació (PDF).
- No hi ha fonts externes: aquest insight explica dades pròpies d'onext i no cita estudis de tercers.
Bernat López és fundador i CEO d'onext, boutique d'IA. Acompanya equips de desenvolupament i de producte a treballar amb IA amb mètode —especificació abans de programar, una persona que decideix on hi ha risc i Spec-Driven Development— i aplica a la seva pròpia empresa el que proposa: onext funciona amb el seu propi sistema agèntic.
LinkedIn →