Spec-Driven Development (SDD) és una metodologia de desenvolupament de programari amb IA que substitueix els prompts ad hoc per una especificació estructurada que guia l'agent durant tota la generació de codi. Apareix al Technology Radar 2025 com a tècnica emergent.
SDD existeix perquè els equips que fan servir GitHub Copilot, Claude Code o Cursor sense mètode obtenen resultats inconsistents: el mateix problema es resol de tres maneres diferents per tres developers distints. L'especificació elimina la variabilitat.
El teu equip fa servir GitHub Copilot o Claude Code. Escriuen un prompt, obtenen codi, el revisen, l'ajusten, l'integren. Funciona... de vegades. Altres vegades el codi generat no entén el context, ignora l'arquitectura existent, o resol un problema diferent del plantejat. El problema no és la IA. És com l'estàs fent servir.
Spec-Driven Development (SDD) és una metodologia emergent que ja apareix al Technology Radar 2025. No és una altra eina d'IA. És un canvi fonamental en com els equips de desenvolupament interactuen amb agents d'IA per escriure codi. Si arribes aquí des de fora del context agèntic, abans convé revisar què és agentic AI i com està transformant el desenvolupament de programari.
El problema: prompts ad hoc = resultats impredictibles
La majoria d'equips fa servir la IA per programar d'aquesta manera:
- El developer té una tasca
- Escriu un prompt descrivint el que necessita
- La IA genera codi
- El developer revisa, ajusta, integra
- Repetir per a la següent tasca
Problema: Cada prompt és independent. No hi ha context compartit. No hi ha "memòria" del projecte. El resultat depèn de l'habilitat del developer per escriure bons prompts.
Conseqüències típiques:
- Scope creep: la IA resol més (o menys) del que es demana
- Falta de context: codi que no respecta l'arquitectura existent
- "Caixa negra": difícil entendre per què la IA va generar el que va generar
- Inconsistència: el mateix problema resolt de 3 maneres diferents per 3 developers
A la pràctica, el gap de qualitat i monitoring que apareix quan els agents IA arriben a producció és on la majoria de projectes es trenquen. SDD existeix precisament per tancar-lo des de la fase de disseny.
Què és Spec-Driven Development
Spec-Driven Development inverteix el flux. En lloc d'escriure prompts ad hoc, comences amb una especificació estructurada que guia tot el procés de generació de codi.
La idea central: una especificació funcional detallada actua com a "North Star" per als agents d'IA, en lloc de dependre de prompts improvisats.
El workflow de SDD
1. ESPECIFICACIO
- Document estructurat amb requisits, intencions, restriccions
- Actua com a "font de veritat" per al projecte
- Versionat juntament amb el codi
2. DESCOMPOSICIO
- L'especificació es desglossa en tasques més petites
- Cada tasca és manejable per un agent d'IA
3. GENERACIO
- Els agents d'IA generen codi basat en l'especificació
- El context ve del document, no del prompt instantani
4. REVISIO HUMANA
- Els developers revisen a cada pas
- Els ajustos es documenten per millorar el sistema
5. ITERACIO
- El feedback s'incorpora a l'especificació
- Es construeix una base de coneixement amb el temps
Aquest pipeline esdevé crític en workflows multi-etapa amb agents IA on una fallada al pas N es propaga a N+1 i N+2 fins a amplificar-se en el resultat final. L'especificació estructurada actua com a contracte entre etapes i limita aquesta propagació.
Per què SDD és diferent (i millor)
1. Control i predictibilitat
Amb prompts ad hoc, el resultat depèn de la qualitat del prompt en aquell moment. Amb SDD, el resultat depèn d'una especificació ben pensada que ha estat revisada per l'equip.
Resultat: Menys sorpreses. Codi més consistent. Menys "què feia aquest codi?" tres mesos després.
2. Col·laboració estructurada
L'especificació es converteix en un document versionat que l'equip pot revisar, discutir i millorar. És la font de veritat del projecte.
Resultat: Millor comunicació entre producte, desenvolupament i QA. Tothom parla el mateix idioma.
3. Supera les limitacions de la IA
Els agents d'IA tenen context limitat. Amb SDD, aquest context ve de l'especificació, no de l'historial de chat que es perd entre sessions.
Resultat: Codi que respecta l'arquitectura existent. Menys refactoring posterior.
4. Traçabilitat completa
Cada línia de codi generada es pot traçar fins a un requisit específic. Quan alguna cosa falla, saps exactament on buscar.
Resultat: Debugging més ràpid. Manteniment més simple.
Per a sectors regulats (banca, salut, administració), el disseny compliance-first per a agents amb traçabilitat d'auditoria deixa de ser opcional — és la diferència entre una arquitectura que passa l'auditoria de l'EU AI Act i una que no.
3 eines que implementen SDD
Actualment hi ha tres aproximacions principals a SDD, cadascuna amb un enfocament diferent:
1. Amazon Kiro
Guia els usuaris a través de tres fases: requisits, disseny i creació de tasques. Enfocament estructurat però tradicional.
2. GitHub spec-kit
Procés de tres passos amb orquestració més rica. Inclou prompts configurables i una "constitució" que defineix principis immutables del projecte.
3. Tessl Framework
L'enfocament més radical: la mateixa especificació es converteix en l'artefacte mantingut, no el codi. El codi és un derivat de l'especificació.
Com implementem SDD a onext
A onext, SDD és la base dels nostres Centres d'Excel·lència d'IA. No és teoria: és com transformem equips de desenvolupament en 4-6 setmanes.
El nostre flux provat
Fase 1: Documentació d'especificació (Setmana 1)
- Auditoria del projecte: Entenem arquitectura, patrons, convencions
- Creació de la "constitució": Regles immutables que la IA ha de respectar
- Template d'especificació: Format estàndard per a noves features
Fase 2: Integració amb eines (Setmana 2)
- Configuració d'agents: Claude Code, Copilot o similar amb context del projecte
- Playbook de prompts: Templates provats per a tasques comunes
- Flux de code review: Checklist específic per a codi generat per IA
Fase 3: Adopció de l'equip (Setmana 3-4)
- Workshop pràctic: L'equip aprèn escrivint especificacions reals
- Pair programming: Developers experimentats guien juniors
- Mètriques de seguiment: Temps estalviat, qualitat del codi, consistència
Fase 4: Optimització contínua (Setmana 5-6)
- Refinament d'especificacions: Aprenem del que funciona i del que no
- Expansió de casos d'ús: Apliquem SDD a més tipus de tasques
- Autonomia de l'equip: L'equip manté i millora el sistema sense nosaltres
Cas real: De 2 hores per feature a 30 minuts
Client: SaaS B2B Sèrie A, 8 developers
Problema: Codi generat per IA inconsistent, molt temps en refactoring
Before (sense SDD)
- Cada developer feia servir Copilot "a la seva manera"
- El codi generat ignorava les convencions del projecte
- 60% del temps a ajustar codi generat
- 3 developers feien el mateix problema de 3 maneres
After (amb SDD)
- Especificació compartida amb patrons del projecte
- "Constitució" que defineix arquitectura i convencions
- Templates de spec per a features, bugs, refactoring
- Codi generat consistent entre developers
Resultats (6 setmanes):
- Temps per feature: 2h -> 30min (-75%)
- Temps en refactoring: 60% -> 15% (-75%)
- Consistència de codi: Mesurada per linter, +40% menys warnings
- Satisfacció de l'equip: 3.2/5 -> 4.6/5
"Ara el codi generat sembla escrit per nosaltres, no per un bot genèric"
Un matís important: cautela constructiva
El Technology Radar classifica SDD en la categoria "Assess" (explorar amb cautela). L'avaluació és realista:
"Encara que l'espai resulta fascinant, els fluxos de treball continuen sent elaborats i plens de decisions preses per criteri propi. Les eines generen especificacions extenses difícils de revisar."
La nostra interpretació: Les eines genèriques de SDD poden ser complexes. Però quan la metodologia s'adapta al teu context específic (la teva arquitectura, el teu equip, les teves convencions), els beneficis superen la corba d'aprenentatge.
Per això a onext no venem una eina. Implementem la metodologia adaptada al teu equip.
Principis clau de SDD per començar avui
No necessites eines complexes per començar amb SDD. Aquests són els principis que pots aplicar des d'avui:
1. Escriu abans de demanar
Abans d'escriure un prompt, escriu 3-5 línies descrivint:
- Quin problema resol això
- Quines restriccions té
- Com s'hauria d'integrar amb el codi existent
2. Defineix la teva "constitució"
Documenta les regles immutables del teu projecte:
- Patrons d'arquitectura que sempre fas servir
- Convencions de naming
- Dependències permeses i prohibides
- Estructura de carpetes
3. Crea templates d'especificació
Un template simple per a noves features:
## Feature: [Nom]
### Problema
[Quin problema de l'usuari resol]
### Solució
[Com ho resolem a alt nivell]
### Restriccions
- [Arquitectura a respectar]
- [Patrons a fer servir]
- [El que NO ha de fer]
### Criteris d'acceptació
- [ ] [Criteri 1]
- [ ] [Criteri 2]
### Integració
[Com s'integra amb el codi existent]
4. Revisa amb l'especificació a la mà
En code review, no revisis només el codi. Revisa si el codi compleix l'especificació. Si no hi ha especificació, aquest és el primer problema.
Conclusió: De "fer servir la IA" a "integrar la IA"
Spec-Driven Development no és una eina més. És un canvi de mentalitat:
- De: "La IA és un autocomplete intel·ligent"
- A: "La IA és un agent que executa especificacions"
Els equips que adopten SDD no escriuen menys codi. Escriuen millor codi, més ràpid, amb més consistència. I el més important: el codi generat és mantenible a llarg termini.
La pregunta no és si el teu equip farà servir la IA per programar. La pregunta és si la farà servir de manera caòtica (prompts ad hoc) o de manera controlada (spec-driven).
Preguntes freqüents sobre Spec-Driven Development
Què és Spec-Driven Development (SDD)?
Spec-Driven Development és una metodologia de desenvolupament de programari amb IA que reemplaça els prompts ad hoc per una especificació estructurada que descriu què ha de fer el codi, sota quina arquitectura i amb quines restriccions. L'agent IA (Claude Code, Copilot, Cursor) genera el codi contra aquesta especificació, no contra un prompt solt. Resultat: el mateix problema resolt de la mateixa manera per developers distints.
En què es diferencia SDD de TDD o BDD?
TDD (Test-Driven Development) escriu primer els tests; BDD (Behavior-Driven Development) escriu primer el comportament esperat en llenguatge natural. SDD escriu primer l'especificació funcional i arquitectònica completa que l'agent IA farà servir per generar tot el codi. TDD i BDD són disciplines de persones escrivint codi; SDD és disciplina de persones dirigint agents IA que escriuen codi.
Com s'aplica SDD amb Claude Code o GitHub Copilot?
L'spec es materialitza en un document estructurat (Markdown o YAML) que
l'agent llegeix com a context abans de generar. A Claude Code es fa servir
CLAUDE.md o fitxers de spec dedicats; a Copilot es fa servir
.github/copilot-instructions.md; a Cursor es fan servir regles de
projecte. L'spec descriu context del producte, arquitectura, convencions
de codi, casos límit i criteris d'acceptació.
SDD funciona amb equips que mantenen codi legacy?
Sí, i precisament allà dona més retorn. En codi legacy l'spec actua com a mapa: defineix l'arquitectura real existent, els punts d'extensió segurs i les zones que no s'han de tocar. L'agent IA deixa d'"inventar" perquè l'spec li dona el context que el codi legacy no documenta per si mateix.
Quan NO convé aplicar SDD?
Prototips exploratoris on l'objectiu és descobrir què construir, no construir-ho bé. En aquests casos l'spec prematura mata la velocitat. SDD encaixa quan ja hi ha producció, arquitectura definida i equip multi-developer. Si treballes sol en un MVP de 2 setmanes, no el necessites.