Durant els darrers anys, la intel·ligència artificial aplicada a la programació funcionava com un autocompletat molt avançat: suggeria línies i el desenvolupador les revisava una a una. Avui l’escenari és diferent. Els agents d’IA generen funcionalitats completes, obren pull requests i escriuen els seus propis tests. El coll d’ampolla ja no és escriure codi, sinó aconseguir que el que s’escriu sigui exactament el que el negoci necessita.
D’aquí neix el Spec-Driven Development (SDD), o desenvolupament dirigit per especificacions: una manera de treballar en què l’especificació —no el prompt— és la font de veritat del projecte.
El problema del «vibe coding»
Demanar a un assistent «afegeix filtres al llistat d’usuaris» i acceptar el que retorna és ràpid i, de vegades, suficient. El problema apareix quan el projecte creix: cada petició s’interpreta d’una manera, cada agent pren decisions d’arquitectura pel seu compte i ningú no ha escrit enlloc què es considera correcte.
El resultat són funcionalitats que «funcionen» però no fan el que s’esperava, codi sense tests, components duplicats i revisions interminables. Un estudi de METR publicat el 2025 va posar xifres a aquesta sensació: desenvolupadors experimentats que treballaven sense una metodologia estructurada van ser al voltant d’un 19% més lents fent servir IA, tot i que ells creien que anaven més ràpid.
Què és exactament l’Spec-Driven Development
L’SDD consisteix a escriure, abans de generar codi, un document breu i versionat que descriu què es vol construir, amb quins límits i com es validarà. Aquest document viu al repositori, es revisa com es revisa el codi i s’actualitza quan canvien els requisits.
No és tornar al waterfall ni redactar documentació de cent pàgines. És donar prou context perquè tant una persona com un agent puguin prendre les mateixes decisions.
Dos nivells d’especificació
- Especificació de sistema: arquitectura, convencions de codi, model de dades, llibreries permeses i prohibides. És estable i normalment la manté qui lidera tècnicament el projecte.
- Especificació de funcionalitat: el canvi concret que s’implementarà, amb els seus criteris d’acceptació. És efímera i la manté qui desenvolupa aquella funcionalitat.
Com és una spec mínima
Una especificació útil no cal que sigui llarga, però sí que ha de respondre aquestes preguntes:
- Objectiu: quin problema de negoci resol.
- Capacitats: què ha de poder fer l’usuari.
- Criteris d’acceptació: com sabrem que està ben fet.
- Restriccions: què no es pot tocar, quin stack es fa servir.
- Decisions tècniques: patrons i components a reutilitzar.
- Casos d’error: què passa quan alguna cosa falla.
- Tasques: els passos d’implementació.
La diferència es veu de seguida a la pràctica: «afegir filtres» produeix codi improvisat que cau a la revisió; una spec amb criteris d’acceptació produeix lògica correcta, tests dels casos rellevants i reutilització dels components que ja existeixen.
El cicle de treball
El flux habitual té poques fases i totes són revisables:
- Es parteix d’una història d’usuari en llenguatge de negoci.
- L’agent la refina i retorna els dubtes que detecta.
- S’acorda l’especificació tècnica amb criteris i pla de tasques.
- L’agent implementa: branca, codi i tests.
- La revisió es fa contra els criteris d’acceptació, no línia a línia.
- Es verifica, s’arxiva l’especificació i queda registrada al repositori.
Eines per començar
- GitHub Spec Kit: framework obert i agnòstic, compatible amb Copilot, Claude o Cursor.
- Kiro (AWS): entorn de desenvolupament amb un flux integrat de requisits, disseny i tasques.
- OpenSpec: cicle complet des de la història d’usuari fins a l’arxivat de l’especificació.
- BMAD-Method: rols diferenciats (producte, arquitectura, desenvolupament) per a equips grans.
- Fitxers de context al repositori (tipus CLAUDE.md o .cursorrules): la via més ràpida si encara no vols afegir eines noves.
Errors habituals
- Especificacions ambigües que acaben delegant decisions importants a l’agent.
- Sobreespecificar fins al detall de cada línia, cosa que elimina qualsevol marge de millora.
- Congelar l’especificació i convertir el procés en un waterfall encobert.
- No versionar-la: si no és al repositori, deixa de ser la font de veritat.
- Escriure-la en solitari: una spec que l’equip no comparteix només és una opinió.
Per què això també és una qüestió de seguretat
Quan ningú no defineix les restriccions, és la IA qui decideix com es gestionen les sessions, què es registra als logs, com es validen les entrades o quines dependències s’instal·len. Escriure aquestes regles una sola vegada, a l’especificació de sistema, evita haver-les de detectar més tard en una auditoria —o després d’un incident. És la diferència entre un web generat de pressa i un projecte que es pot mantenir durant anys.
Per on començar
No cal transformar l’equip de cop. Un bon primer pas és escriure una especificació de sistema mínima (stack, convencions i prohibicions), aplicar una spec petita a la propera funcionalitat abans d’escriure el primer prompt i mesurar el resultat. I compte amb la mètrica: l’SDD no accelera la primera versió, redueix el nombre d’iteracions fins a arribar a la bona.
La IA no deixa de ser impredictible perquè el model millori, sinó perquè li donem una intenció clara i verificable. Això és, al capdavall, tot l’Spec-Driven Development.
Article elaborat a partir de l’anàlisi sobre Spec-Driven Development publicada per LIDR.