Quan un equip sent parlar de l'Spec-Driven Development (SDD), el desenvolupament guiat per especificacions, la primera pregunta sol ser si és una metodologia més per afegir a la llista. Ja tenien el TDD, ja havien provat el BDD, i ara arriba una tercera sigla amb «Driven» al mig.
La pregunta té sentit, però parteix d'una premissa equivocada: que totes tres competeixen pel mateix lloc. No és així. Cadascuna respon una pregunta diferent, i quan el codi l'escriu un agent, les tres preguntes continuen allà. El que canvia és qui llegeix la resposta.
La tesi d'aquesta peça: l'SDD no substitueix el TDD ni el BDD; els necessita. El BDD aporta la manera d'escriure els criteris, amb exemples concrets. El TDD aporta el cicle que demostra que es compleixen, amb un test que falla abans que existeixi el codi. L'SDD hi afegeix que aquesta especificació és el que llegeix l'agent i la font de veritat de la feina. Treure qualsevol de les tres deixa un forat que l'agent no omplirà pel seu compte.
Tres preguntes diferents
Abans de comparar-les, convé separar quina pregunta contesta cadascuna. Les tres es poden confondre perquè totes parlen d'especificar abans de programar.
| Pràctica | Pregunta que respon | Què produeix | Què aporta quan escriu un agent |
|---|---|---|---|
| BDD (Behaviour-Driven Development) | Com descrivim el que ha de fer el sistema? | Exemples concrets, llegibles per persones i per màquines | Criteris sense ambigüitat, que es poden convertir en escenaris |
| TDD (Test-Driven Development) | Com demostrem que el codi compleix? | Un test que primer falla i després passa | Una comprovació que l'agent no controla |
| SDD (Spec-Driven Development) | Què llegeix l'agent abans d'escriure? | Una especificació que és l'entrada de la feina i la font de veritat | El context i l'abast de la tasca, escrits i revisables |
Elaboració pròpia d'onext, a partir de Cucumber, l'especificació de spec-kit i l'anàlisi de Birgitta Böckeler (consultats el 10 d'octubre de 2026)
BDD: la manera d'escriure el criteri
Cucumber, l'eina que va néixer per donar suport al BDD, l'organitza en tres pràctiques. En la descoberta, converses estructurades al voltant d'exemples reals del sistema des del punt de vista de l'usuari. En la formulació, cada exemple s'escriu com a documentació estructurada, en un mitjà que poden llegir «tant persones com màquines». En l'automatització, aquesta especificació executable guia la implementació.
Aquesta manera d'escriure no ha desaparegut amb els agents: ha tornat. Birgitta Böckeler, de Thoughtworks, va analitzar tres eines d'SDD i descriu que Kiro estructura els requisits com a històries d'usuari amb criteris d'acceptació en format GIVEN… WHEN… THEN…, el que va popularitzar el BDD. Un criteri escrit així es pot llegir en una reunió i també executar en una prova.
La mateixa anàlisi porta l'avís contrari: en una de les seves proves, el document de requisits va convertir una correcció petita en quatre històries d'usuari amb setze criteris. El format ajuda a precisar; no decideix quant cal precisar. Aquesta decisió continua sent d'una persona, i la vam defensar amb més detall a MVP davant d'especificació.
TDD: la prova que es compleix
Aquí hi ha la part que més es perd quan es parla d'SDD. L'especificació de spec-kit, el kit de GitHub per treballar amb SDD, l'anomena «Test-First Imperative» i l'escriu com a regla: tota implementació segueix un TDD estricte, i no s'escriu codi d'implementació fins que els tests estan escrits, «validats i aprovats per l'usuari» i comprovats en vermell, és a dir, fallant. En un altre punt ho resumeix en una frase: els escenaris d'acceptació es converteixen en tests.
Kent Beck, que va popularitzar el TDD, explica a «Augmented Coding: Beyond the Vibes» com va intentar que el seu agent treballés així. Les instruccions eren explícites: seguir sempre el cicle vermell, verd, refactoritzar; escriure primer el test més simple que falli; un test cada vegada. I enumera tres senyals que l'agent s'estava desviant: bucles, funcionalitat que no havia demanat i qualsevol indici que feia trampa, per exemple desactivant o esborrant tests.
Risc Un agent que pot editar els tests pot fer que «passin» sense complir res. Els canvis en els tests són canvis en el criteri amb què es jutja la resta del codi: mereixen una revisió a part, i abans que la del codi.
Hi ha un matís que no convé saltar-se: que un test existeixi no vol dir que provi el que ha de provar. Un test escrit mirant el codi que ja hi ha descriu el que fa aquest codi, no el que hauria de fer; ho expliquem a els tests generats per IA no proven el codi, el descriuen. Per això l'ordre importa: el test surt del criteri i falla abans que el codi existeixi.
SDD: el que canvia quan el lector és un agent
El que l'SDD afegeix a les altres dues no és una tècnica nova de proves. És un canvi de lector. En el TDD i en el BDD, qui llegeix el criteri és una persona que programarà. En l'SDD, qui el llegeix és un agent, i l'especificació passa a ser l'entrada de la feina: el context, l'abast i el que es considera acabat.
Böckeler distingeix tres nivells. En el primer, l'especificació s'escriu abans i es fa servir per a la tasca (spec-first). En el segon, es conserva després per continuar fent evolucionar aquesta funcionalitat (spec-anchored). En el tercer, l'especificació és el fitxer principal i la persona ja no toca el codi (spec-as-source). Per a un equip que comença, el primer és el punt de partida natural, i és on més rendeix la combinació amb el TDD.
I aquí hi ha la raó de fons de la tesi. Böckeler ho diu amb les seves paraules: fins i tot amb tots aquests fitxers, plantilles, fluxos i llistes de comprovació, sovint va veure que l'agent acabava sense seguir totes les instruccions. També el va veure excedir-se amb alguna. Una especificació que l'agent llegeix però que res no comprova depèn que l'agent la segueixi. Un test que falla mentre el comportament no existeixi no en depèn.
Com encaixen en una tasca
Posades en ordre, les tres pràctiques no es trepitgen: cadascuna ocupa un tram. Aquesta seqüència és una proposta de criteri, no una norma de cap de les fonts:
- Exemples abans que requisits. Negoci i desenvolupament acorden dos o tres casos concrets del que ha de passar, inclòs un que no ha de passar (BDD, descoberta).
- Criteris a l'especificació. Cada exemple s'escriu com a criteri d'acceptació verificable, en GIVEN/WHEN/THEN o en un format equivalent, dins de l'especificació que llegirà l'agent (BDD, formulació; SDD).
- Tests que fallen, aprovats per una persona. De cada criteri en surt un test; algú comprova que prova el que diu el criteri i que falla (TDD, vermell).
- L'agent implementa. Amb l'especificació com a context i els tests com a meta, sense permís per canviar-los sense revisió (SDD i TDD, verd).
- Revisió del que el test no cobreix. El que ha passat en verd no es torna a revisar línia per línia; es revisa el que cap criteri no cobria i qualsevol canvi en els tests.
El tercer pas és el que converteix l'especificació en una porta i no en un document: el desenvolupem a la teva spec ja és un eval. I el punt en què una persona signa aquesta especificació, abans que l'agent generi res, a l'especificació és on se signa.
La discrepància: s'assembla més al TDD o a l'MDD?
Seria més còmode presentar l'SDD com l'evolució natural del TDD i del BDD. Böckeler no ho veu ben bé així. Admet que molta gent fa l'analogia amb el TDD i el BDD, però proposa mirar un altre paral·lel, sobretot per al nivell spec-as-source: el Model-Driven Development (MDD), en què els models eren les especificacions i un generador produïa el codi. L'MDD no va acabar de quallar en les aplicacions de negoci, i ella es pregunta si aquest nivell d'SDD acabarà amb els inconvenients de l'MDD i dels models de llenguatge alhora.
El seu tancament és encara més incòmode: es pregunta si algunes eines no estan traslladant els fluxos existents als agents de manera massa literal i amplificant problemes que ja existien, com la sobrecàrrega de revisió. Fa servir una paraula alemanya per descriure-ho, Verschlimmbesserung: empitjorar una cosa en intentar millorar-la.
No cal resoldre aquí aquesta discussió, però sí treure'n una conseqüència pràctica. El risc que descriu creix com més s'allunya l'especificació d'alguna cosa que es pugui comprovar: molts fitxers, molta prosa, cap test que falli. La combinació amb el TDD és justament el que manté l'SDD al costat verificable. És el mateix argument amb què vam començar a parlar d'Spec-Driven Development i codi sota control.
I si aquesta especificació viu en un repositori amb un assistent com Claude Code, l'altra meitat de la pregunta és quines regles se suggereixen a l'agent i quines se li imposen; ho expliquem a CLAUDE.md és context, no control.
Preguntes freqüents
Quina diferència hi ha entre SDD, TDD i BDD?
Responen preguntes diferents. El BDD (Behaviour-Driven Development) tracta de com es descriu el comportament esperat: amb exemples concrets, acordats entre negoci i desenvolupament i escrits perquè els puguin llegir persones i màquines. El TDD (Test-Driven Development) tracta de com es demostra que el codi compleix: primer s'escriu un test que falla i després el codi mínim que el fa passar. L'SDD (Spec-Driven Development) tracta de què llegeix l'agent que escriu el codi: l'especificació és l'entrada de la feina i la font de veritat.
L'SDD substitueix el TDD?
No. La mateixa especificació de spec-kit, el kit de GitHub per a l'SDD, inclou el TDD com a regla: cap codi d'implementació abans que els tests estiguin escrits, aprovats per l'usuari i comprovats en vermell. Sense un test que falli primer, l'especificació orienta l'agent, però res no demostra que l'hagi complert.
Cal escriure les especificacions en format GIVEN/WHEN/THEN?
No és obligatori, però ajuda. Birgitta Böckeler descriu que Kiro estructura els requisits com a històries d'usuari amb criteris d'acceptació en format GIVEN… WHEN… THEN…. És el format que va popularitzar el BDD, i té l'avantatge que cada criteri es pot convertir en un escenari executable. El risc és el contrari: Böckeler va veure com una correcció petita es convertia en quatre històries d'usuari amb setze criteris.
Per què un agent es pot saltar l'especificació?
Perquè llegir-la no garanteix seguir-la. Böckeler explica que, fins i tot amb plantilles, fluxos i llistes de comprovació, sovint va veure que l'agent no seguia totes les instruccions, i també que n'aplicava alguna massa al peu de la lletra. Per això cal alguna cosa que l'agent no controli: un test que falla mentre el comportament no existeixi.
Què faig si l'agent modifica o esborra els tests perquè passin?
Tractar-ho com un senyal d'alarma, no com un detall. Kent Beck l'inclou entre els tres senyals que l'agent s'està desviant: qualsevol indici que fa trampa, per exemple desactivant o esborrant tests. A la pràctica, els canvis en els tests s'haurien de revisar a part del codi i amb més atenció, perquè són el criteri amb què es jutja tota la resta.
L'SDD és el mateix que el Model-Driven Development?
No, però hi ha qui hi veu la semblança. Böckeler apunta que, sobretot en el nivell en què l'especificació és l'única font que edita una persona (spec-as-source), un altre paral·lel important és l'MDD: els models eren especificacions de les quals es generava el codi. L'MDD no va acabar de quallar en les aplicacions de negoci, i ella es pregunta si aquest nivell d'SDD acabarà amb els inconvenients dels dos mons.
Fonts
- Birgitta Böckeler (Thoughtworks), «Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl», martinfowler.com, 15 d'octubre de 2025.
- GitHub spec-kit, «Specification-Driven Development (SDD)» (sense data visible; consultada el 10 d'octubre de 2026).
- Kent Beck, «Augmented Coding: Beyond the Vibes», Software Design: Tidy First?, 25 de juny de 2025.
- Cucumber, «Behaviour-Driven Development» (consultada el 10 d'octubre de 2026).
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 →