L'objecció més repetida al Spec-Driven Development (SDD), el desenvolupament guiat per especificacions, és que és paperassa: escriure un document abans de cada canvi frena l'equip. Un estudi recent ha mirat com el practiquen els equips que ja el fan servir, i la resposta és més útil que un sí o un no.
La idea que defensa aquest insight: l'SDD no es defensa dient que serveix per a tot, sinó triant on es fa servir. Funcionalitats noves o amb risc, sí; un canvi trivial, no. L'especificació diu què i per què, no com. I es comprova contra el codi a cada canvi, no al final. Una especificació que ningú no comprova és documentació que caduca.
El primer estudi sobre com es practica l'SDD
Shyam Agarwal, Anmol Singhal, Andrew Macvean, Bogdan Vasilescu i Travis Breaux (Carnegie Mellon University i Google) han comparat el que prescriuen les eines d'SDD amb el que fan de debò els qui les fan servir. La versió més recent del treball és del 15 d'octubre de 2026. Ajunten tres fonts: una anàlisi de converses a Reddit, entrevistes a 21 professionals (8 d'ells fabricants d'eines) i SpecMine, un corpus de 470.795 fitxers d'especificació de 73.030 repositoris públics de GitHub, del qual analitzen a fons una mostra de 266 repositoris actius i populars (36.890 fitxers). Tres xifres d'aquesta mostra:
Risc És un preprint sense revisió per parells. Els repositoris són públics i populars, i a la mostra hi domina una eina (OpenSpec, el 78,4 %): poden no assemblar-se als de la teva empresa. Les xifres són percentatges de fitxers, no d'equips. Els entrevistats probablement estan més implicats amb l'SDD que la mitjana, l'estudi troba associacions i no causes, i els mateixos participants no podien separar el que guanyaven amb l'SDD del que milloraven els models.
El que fan els equips que ja el fan servir
Quatre troballes de l'estudi, explicades per separat perquè cadascuna canvia una decisió diferent:
- El fan servir de manera selectiva. Sobretot en funcionalitats noves i més grans. Per a bugs, hotfixes i tasques petites, els entrevistats no escrivien especificació.
- L'agent és més fiable, però costa més. Els participants explicaven un comportament de l'agent més fiable i una intenció més clara, a canvi de més planificació i més revisió. Un equip va explicar que amb SDD gastava de dues a tres vegades més tokens i trigava el doble que demanant-ho directament a l'agent: és un cas explicat, no una estadística.
- L'especificació acaba portant el com. Tothom coincideix que ha de dir què cal construir, però la majoria dels qui fan servir les eines també escriu com construir-ho, sobretot en tasques complexes o quan l'agent no té el coneixement. Els fabricants d'eines, en canvi, separen el com en documents de disseny o de tasques.
- La comprovació arriba al final. Els participants comprovaven que especificació i codi coincidien sobretot en acabar el canvi, no amb el temps. Els qui volien detectar la deriva després es van muntar les seves pròpies comprovacions.
Els autors posen nom al que passa llavors: l'especificació caduca (spec decay), es queda vella a mesura que canvia el codi, sobretot quan un canvi altera un comportament que descriuen altres especificacions. És la mateixa pèrdua de què parlem a deute de comprensió: el que ningú no manté deixa d'explicar el codi.
On compensa l'especificació i on sobra
Si el cost és real (més planificació i més revisió), la pregunta no és si es fa servir l'SDD, sinó en quins canvis. La taula és la nostra proposta a partir del que fan els equips de l'estudi, no un resultat de l'estudi.
| Tipus de canvi | Especificació? | Per què |
|---|---|---|
| Funcionalitat nova | Sí | Cal fixar què es construeix abans que l'agent ho decideixi pel seu compte |
| Canvi amb risc (cobraments, permisos, dades personals) | Sí | Els criteris d'acceptació són el que després comprova la màquina i signa una persona |
| Canvi que passa per diverses persones o rols | Sí | L'especificació és el que tothom entén igual; l'estudi hi veu el benefici compartit |
| Bug acotat | No, un test | Un test que reprodueix l'error ja diu què ha de passar |
| Hotfix | Després, si canvia un comportament | Primer s'arregla; si altera el que descriu una altra especificació, s'actualitza aquella |
| Text, estil o canvi trivial | No | El cost d'escriure-la supera el que aclareix |
Elaboració d'onext a partir d'Agarwal i altres (2026)
El criteri de fons és el mateix que a una issue no és una especificació: cal especificació quan, si no s'escriu, l'agent omple els buits amb el que creu. I no substitueix el que ja fan bé els tests: com es reparteixen SDD, TDD i BDD és a què aporta cadascun quan el codi l'escriu un agent.
Què va a l'especificació i què no
La nostra lectura de la troballa del com: el detall d'implementació ajuda l'agent avui i caduca demà. L'especificació que dura diu què cal construir, per a qui, per què i amb quins criteris d'acceptació. El com (quina llibreria, quina estructura, quins passos) va a part, en un document de disseny o a les tasques, com fan els fabricants d'eines de l'estudi. Així, quan el com canvia, l'especificació continua sent certa.
Hi ha una excepció raonable, que el mateix estudi recull: el que l'agent no pot saber. Les decisions que l'equip ja va prendre i que no són al codi han de quedar escrites, com expliquem a decisions d'arquitectura, però al seu lloc, no repetides a cada especificació.
Comprovar-la a cada canvi, no al final
Si l'especificació només es compara amb el codi quan el canvi està acabat, la deriva apareix al següent. La manera d'evitar-ho no és rellegir-la més, sinó fer que es comprovi sola: que els criteris d'acceptació es converteixin en tests que s'executen a cada integració, com expliquem a la teva spec ja és un eval. El mateix estudi apunta en aquesta direcció: revisions programades o tests d'extrem a extrem a la integració contínua poden mostrar que codi i especificació ja no coincideixen.
DORA ho diu de manera més general al seu model de capacitats d'IA (setembre del 2025): treballar en lots petits, un principi de sempre, és especialment potent quan es treballa amb IA. Un canvi petit amb la seva especificació i la seva comprovació és fàcil de revisar; un de gran, comprovat al final, no.
Una especificació que ningú no comprova és documentació que caduca. Si no hi ha un test que falli quan el codi se n'aparta, no està guiant el desenvolupament.
La resposta honesta a «l'SDD és burocràcia»
Ho és si s'aplica a tot i ningú no manté el que hi ha escrit. El cost existeix: l'estudi el troba en esforç de planificació i de revisió, i un equip també l'explicava en tokens i en temps. El que canvia el compte és on es gasta.
L'estudi ho resumeix en dos plans: el benefici individual pot venir d'aclarir la intenció abans de delegar en l'agent, i el de l'equip depèn que l'SDD sigui un procés compartit. Un marc conceptual publicat l'agost del 2026 (Díaz, Gayoso, Cimminio i Pérez) ho planteja igual des de la teoria: les especificacions són el contracte entre les persones i els agents, i distingeix la part tècnica que envolta l'agent de les pràctiques de l'equip. És una anàlisi basada en literatura, no un estudi empíric, però coincideix en el que és important: una plantilla no fa el procés. És el que expliquem a les plantilles d'SDD ja són gratis.
El que ens quedem per a un equip que comença: decidir per escrit quins tipus de canvi porten especificació, què hi va i quina comprovació automàtica l'acompanya. Amb aquestes tres decisions, l'SDD deixa de ser un document més i passa a ser la manera de treballar de l'equip.
Si vols veure amb algú de fora on compensa al teu equip, el diagnòstic és gratuït, i si al diagnòstic no veiem diferència, no hi ha Quick-start. Com és la resta del camí és a AI-Accelerated Development. El mètode complet és a Spec-Driven Development amb IA.
Preguntes freqüents
Cal escriure una especificació per a cada canvi amb Spec-Driven Development?
No, i els equips que el practiquen tampoc no ho fan. A l'estudi de Carnegie Mellon i Google sobre com es practica l'SDD, els entrevistats el feien servir de manera selectiva, sobretot en funcionalitats noves, i no el feien servir per a bugs, hotfixes ni tasques petites. A la mostra analitzada, s'estima que el 82,0 % de les especificacions descriu funcionalitats noves.
Quan compensa escriure una especificació abans de donar-la a un agent de codi?
La nostra proposta: quan el canvi és una funcionalitat nova, quan toca alguna cosa amb risc (cobraments, permisos, dades personals) o quan passa per diverses persones o rols que han d'entendre el mateix. Per a un bug acotat sol n'hi ha prou amb un test que el reprodueixi, i un canvi de text o d'estil no necessita especificació.
Què ha de portar una especificació i què no?
Què cal construir i per què, amb criteris d'acceptació que es puguin comprovar. El com (disseny, tasques, detalls d'implementació), millor en un document a part. A l'estudi, el 77,6 % dels fitxers d'especificació porta detalls d'implementació, i els autors assenyalen que això pot ajudar l'agent però fa que l'especificació caduqui abans.
Per què caduca una especificació?
Perquè el codi canvia i l'especificació no. Els autors en diuen spec decay: l'especificació es queda vella a mesura que canvia el codi. Passa sobretot quan un canvi altera un comportament que descriuen altres especificacions. A la mostra, el 81,5 % dels fitxers d'especificació té un sol commit registrat.
Quan cal comprovar que l'especificació i el codi coincideixen?
A cada canvi, no al final. Els participants de l'estudi comprovaven especificació i codi sobretot en acabar el canvi, no amb el temps, i qui volia detectar la deriva després es va haver de muntar les seves pròpies comprovacions. Si els criteris d'acceptació es converteixen en tests que s'executen a cada integració, la comprovació es fa sola.
L'SDD és burocràcia?
Ho és si s'aplica a tot i ningú no manté el que hi ha escrit. L'estudi troba que el comportament de l'agent és més fiable a canvi de més esforç de planificació i de revisió. Aquest cost compensa on el canvi ho justifica i deixa de compensar quan s'especifica un canvi trivial o quan l'especificació no es torna a mirar.
Fonts
- Shyam Agarwal, Anmol Singhal, Andrew Macvean, Bogdan Vasilescu i Travis Breaux (Carnegie Mellon University i Google), «Spec-Driven Development as Prescribed and as Practiced», arXiv:2608.25202, versió 4 del 15 d'octubre de 2026 (preprint).
- Jessica Díaz, Joaquín Gayoso, Andrea Cimminio i Jorge Pérez, «Spec-Driven Development for Agentic Software Engineering: Harnessing Human-Agent Teamwork», arXiv:2609.00252, 31 d'agost de 2026 (preprint).
- Kevin M. Storer i Derek DeBellis, «Introducing DORA's inaugural AI Capabilities Model», Google Cloud Blog, 23 de setembre de 2025.
- Les xifres i cites de fonts en anglès estan traduïdes per onext. La taula d'on compensa, la separació entre què i com i la lectura de les troballes són elaboració pròpia d'onext.
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 →