Spec Kit, el kit de GitHub per treballar amb Spec-Driven Development (SDD), el desenvolupament guiat per especificacions, és de codi obert, té llicència MIT i el 15 d'octubre de 2026 sumava unes 141.300 estrelles a GitHub. Porta el flux complet: una constitució amb els principis del projecte, l'especificació, el pla, les tasques i la implementació.
És una bona notícia per a qualsevol equip de desenvolupament, i té una conseqüència que convé dir en veu alta: si la plantilla és gratis i la pot instal·lar qualsevol, la plantilla ja no és el que distingeix un equip d'un altre.
D'aquí surt la tesi d'aquesta peça: el que decideix si un equip lliura diferent amb SDD és el que la plantilla no porta. Quan es fa servir l'especificació completa, quant pot ocupar perquè algú la llegeixi, què prova que l'agent l'ha seguida i qui manté les regles del projecte. Això no es descarrega: es decideix.
Què porta la plantilla, i què no
Què és SDD i en què es diferencia de programar a base de prompts ho expliquem a Spec-Driven Development: codi amb IA sota control. Aquí n'hi ha prou amb l'essencial: abans que l'agent escrigui codi, s'escriu què cal construir, per què i amb quins criteris es donarà per bo. Spec Kit converteix aquest principi en ordres que es llancen des del xat de l'agent, i la majoria de les eines d'SDD segueixen un esquema semblant.
El que cap plantilla no pot portar és el context de l'equip: quina mida tenen els seus canvis, quant temps de revisió té, quins riscos assumeix i qui respon de cada decisió. Una plantilla està feta per servir a qualsevol, i per això no sap res de ningú.
El que expliquen els qui l'han provada
El més útil sobre aquestes eines ho explica qui les ha fet servir amb calma. L'octubre de 2025, Birgitta Böckeler, de Thoughtworks, va provar Kiro, Spec Kit i Tessl i va publicar el que va veure a martinfowler.com. Hi ha tres observacions que importen aquí:
- La mida. Va demanar a Kiro que corregís un error petit i el flux va ser, en paraules seves, «com fer servir una maça per trencar una nou»: quatre històries d'usuari amb setze criteris d'acceptació. Conclou que una bona eina hauria d'oferir fluxos diferents per a canvis de mida i tipus diferents.
- La revisió. Spec Kit li va generar molts fitxers markdown per revisar, repetitius i feixucs. Segons ella, una eina d'SDD eficaç hauria d'oferir una experiència molt bona de revisió d'especificacions.
- El compliment. Malgrat els fitxers, les plantilles i les llistes de comprovació, va veure sovint que l'agent acabava sense seguir totes les instruccions.
I tot i així no descarta la idea: escriu que el principi d'especificar primer és, sens dubte, valuós en moltes situacions. El Technology Radar de Thoughtworks va dir una cosa semblant el novembre de 2025, quan va col·locar el desenvolupament guiat per especificacions a l'anell «Assess» (avaluar): els fluxos continuen sent «elaborats i amb opinions fortes», i algunes eines generen especificacions llargues i difícils de revisar. Aquesta entrada ja no figura a l'edició vigent del Radar.
Cap d'aquestes crítiques no diu que especificar sobri. Diuen que l'eina no decideix per l'equip quan cal especificar, quant ni com comprovar-ho.
Quatre decisions que no porta la plantilla
Cadascuna de les crítiques anteriors correspon a una decisió que l'equip ha de prendre abans que la plantilla li serveixi de res:
| Decisió | El que porta la plantilla | El que ha de decidir l'equip |
|---|---|---|
| Quan hi ha especificació completa | Un flux pensat per a qualsevol canvi | Un llindar per mida i risc: per sota, un carril curt; per sobre, el flux sencer |
| Quant pot ocupar | Els documents que generi l'agent | Un límit de lectura: el que una persona revisa amb atenció d'una vegada. Si no es llegeix, no s'aprova |
| Què prova que s'ha complert | Instruccions per a l'agent | Criteris d'acceptació que es converteixen en proves i decideixen si el canvi entra |
| Qui manté les regles del projecte | Un fitxer de principis (la constitució) | Una persona amb nom que respon d'aquestes regles, i canvis que s'aproven a part |
Elaboració pròpia d'onext a partir de les observacions de Birgitta Böckeler i del Technology Radar de Thoughtworks
Les dues últimes files tenen peça pròpia. Com un criteri d'acceptació es converteix en la porta del merge és a la teva spec ja és un eval, i què signa cada persona en el cicle, a specs i agents: on se signa. La relació d'SDD amb les proves escrites abans del codi, Test-Driven Development (TDD), l'expliquem a SDD, TDD i BDD: què aporta cadascun.
Les dues primeres són les que més se salten, perquè no semblen decisions tècniques. Ho són. Sense llindar, l'equip ho especifica tot o deixa d'especificar al cap de poc temps, cansat d'omplir documents per a canvis de deu línies. Sense límit de lectura, l'especificació creix fins que ningú no la llegeix, i aleshores l'aprovació és una signatura sense lectura al darrere. Si a més el codi és antic, el llindar encara importa més: no s'especifica el sistema sencer, sinó la part que es tocarà, com expliquem a especificar el codi legacy abans dels agents.
Una cosa semblant passa amb la constitució. Un fitxer de principis que l'agent llegeix no fa complir res per si sol: orienta, però no impedeix. El que s'ha de complir va en controls que s'apliquen sols, com expliquem a Claude Code per a equips: context no és control.
Risc Instal·lar la plantilla sense aquestes quatre decisions dona l'aparença de mètode: documents llargs, aprovacions que ningú no exerceix i un agent que segueix les instruccions a mitges, amb tot ben arxivat.
L'eina amplifica el que ja hi ha
DORA, el programa de recerca de Google sobre equips de programari, va arribar al seu informe de 2025 sobre desenvolupament assistit per IA a una conclusió que també val per a SDD: el paper principal de la IA és el d'amplificador, que magnifica les fortaleses i les febleses que l'organització ja té. I els retorns més grans de la inversió en IA, segons el mateix informe, no venen de les eines en si.
Aplicat a les plantilles d'SDD: en un equip que ja sap trossejar la feina, revisar amb criteri i decidir qui respon de què, Spec Kit ordena i accelera. En un equip que no ho sap, produeix més documents sense canviar com es treballa. Per això convé revisar primer la xarxa que detecta els errors, com expliquem a abans de l'agent, la xarxa, i després triar la plantilla.
Que la plantilla sigui gratis té un avantatge: l'equip pot canviar d'eina sense perdre res, sempre que el seu mètode no en depengui. Si demà apareix un kit millor, les quatre decisions continuen valent.
On encaixa onext
A AI-Accelerated Development construïm amb el teu equip el context en què treballa la IA i el procés amb què treballeu. Tots dos es queden a casa teva. Una persona decideix on hi ha risc. El primer pas és un diagnòstic gratuït, i si al diagnòstic no veiem diferència, no hi ha Quick-start.
Preguntes freqüents
Què és Spec Kit?
És el kit de codi obert de GitHub per treballar amb Spec-Driven Development (SDD), amb llicència MIT. Dona als agents de programació un procés estructurat: una constitució amb els principis del projecte, l'especificació, el pla, les tasques i la implementació.
Si la plantilla és gratis, per a què cal ningú més?
Per instal·lar-la, no cal. El que costa és el que la plantilla no porta: decidir quan es fa servir l'especificació completa, quant pot ocupar perquè algú la llegeixi, què prova que l'agent l'ha seguida i qui manté les regles del projecte. Un equip ho pot decidir sol; l'important és que ho decideixi, no que ho compri.
Serveix SDD per corregir un error petit?
Amb el flux complet, normalment no. Birgitta Böckeler, de Thoughtworks, explica que demanar a Kiro que corregís un error petit va ser com fer servir una maça per trencar una nou: en van sortir quatre històries d'usuari amb setze criteris d'acceptació. Per això convé fixar un llindar: per sota, un carril curt; per sobre, especificació completa.
Com s'evita escriure especificacions que ningú no llegeix?
Posant un límit de lectura: el que una persona pot revisar amb atenció d'una vegada. Si l'especificació el supera, es parteix o es retalla. El Technology Radar de Thoughtworks ja avisava que algunes eines generen especificacions llargues i difícils de revisar, i una especificació que ningú no llegeix tampoc no l'aprova ningú de veritat.
L'agent segueix sempre l'especificació?
No. Böckeler escriu que, malgrat tots els fitxers, plantilles i llistes de comprovació, va veure sovint que l'agent acabava sense seguir totes les instruccions. Per això l'especificació ha de portar criteris d'acceptació que es puguin comprovar amb proves, i no només instruccions per a l'agent.
Quina eina convé triar: Spec Kit, Kiro o Tessl?
Primer el mètode i després l'eina. Totes tres parteixen d'una especificació abans del codi i es diferencien en el flux i en quant conserven l'especificació després. Si l'equip té decidits el llindar, el límit de lectura, la comprovació i qui decideix, canviar d'eina no canvia la seva manera de treballar.
Fonts
- GitHub, «Spec Kit», repositori (sense data visible; consultat el 15 d'octubre de 2026, unes 141.300 estrelles aquell dia).
- Birgitta Böckeler (Thoughtworks), «Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl», martinfowler.com, 15 d'octubre de 2025.
- Thoughtworks, «Spec-driven development», Technology Radar, anell Assess, 5 de novembre de 2025 (no figura a l'edició vigent).
- DORA, «State of AI-assisted Software Development 2025» (2025; sense data exacta visible).
- Les cites de fonts en anglès estan traduïdes per onext. La taula de les quatre decisions i la seva lectura 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 →