Disseny per a una
Durant molt de temps, moltes experiències digitals es van dissenyar pensant en sessions…
La IA ha canviat de manera evident la forma en què molts equips s’apropen al desenvolupament de programari. El 2026 és possible generar components, funcions, proves, documentació o prototips complets amb una rapidesa que fa poc semblava impensable. Una idea que abans exigia diverses hores de feina pot convertir-se en una primera versió funcional en qüestió de minuts.
Però crec que aquesta velocitat també té una contrapartida. Generar codi més ràpid no significa necessàriament desenvolupar millor. El veritable repte no és només aconseguir que una eina escrigui línies de codi, sinó construir programari útil, mantenible, coherent amb el producte i alineat amb un objectiu real. Quan aquest objectiu no està ben definit, la intel·ligència artificial pot produir solucions tècnicament plausibles, però poc adequades per al context en què han de funcionar.
Aquí apareix un dels límits de l’anomenat vibe-coding: avançar per intuïció, provant prompts, acceptant respostes i corregint sobre la marxa, sense una definició prou clara del que es vol construir. El problema no és utilitzar IA per programar. El problema és delegar massa aviat la implementació quan encara no s’ha pensat bé l’abast, les regles, els casos límit o els criteris que permetran saber si la solució és correcta.
En aquest context, l’Specification-Driven Development proposa un canvi d’enfocament. Abans de demanar codi, es defineix millor la intenció. Abans de generar solucions, s’aclareix el problema. I abans d’accelerar la implementació, es construeix una especificació que serveixi com a referència compartida per a persones, equips i eines d’IA. Perquè en una etapa en què programar pot ser més ràpid que mai, saber què construir, per què i sota quines condicions esdevé més important que simplement produir codi.
Què és realment l’Specification-Driven Development
L’Specification-Driven Development, o SDD, parteix d’una idea senzilla: abans d’implementar, convé definir amb claredat què es vol construir. No es tracta només d’escriure una llista de requisits, sinó de crear una especificació que ajudi a ordenar el problema, l’abast, les decisions importants i els criteris que permetran validar si el resultat és correcte.
En el desenvolupament tradicional, sovint l’especificació queda separada de la feina real. Pot aparèixer a l’inici d’un projecte, en una fase de documentació, o com un document que aviat deixa d’actualitzar-se. En el context actual, marcat per eines d’IA i agents capaços de generar codi, l’especificació adquireix un paper més actiu: es converteix en una guia de treball. No només orienta l’equip humà, sinó també els sistemes que participen en la implementació.
Per això, una especificació en SDD no s’hauria d’entendre com a documentació decorativa. La seva funció no és aparentar ordre ni omplir un repositori de textos que ningú consulta. El seu valor rau a convertir-se en un punt de referència compartit: què s’ha de construir, què queda fora, quines restriccions s’han de respectar, quins comportaments són acceptables i com es comprovarà que la solució funciona com s’esperava.
Això és especialment important quan es treballa amb IA. Un prompt aïllat pot generar una resposta útil, però també pot deixar massa decisions obertes. En canvi, una bona especificació redueix l’ambigüitat. Ajuda que la IA no només produeixi codi, sinó que ho faci dins d’uns límits concrets, amb una intenció definida i amb criteris més clars per revisar-ne el resultat.
El terme encara està evolucionant. Martin Fowler el descriu, en termes generals, com una pràctica en què s’escriu una especificació abans de generar codi amb IA, de manera que aquesta especificació actua com una font de veritat tant per a les persones com per als agents que intervenen en el procés. L’important no és convertir l’SDD en una metodologia rígida, sinó entendre el canvi de mentalitat que proposa: passar de demanar codi directament a definir primer el marc en què aquest codi ha de tenir sentit.
L’SDD no substitueix el criteri tècnic. No elimina la necessitat de revisar l’arquitectura, la seguretat, el rendiment, la mantenibilitat o l’experiència d’usuari. Tampoc converteix una mala idea en un bon producte pel simple fet d’estar documentada. El que sí que fa és ordenar millor la feina. Obliga a formular millor les preguntes abans de buscar respostes i ajuda que la velocitat que aporta la IA no es converteixi en improvisació accelerada.
Per què l’SDD guanya importància en l’era dels agents d’IA
L’interès per l’Specification-Driven Development no apareix per casualitat. Està directament relacionat amb l’evolució de les eines d’IA aplicades al desenvolupament de programari. Al principi, molts usos se centraven a demanar fragments de codi, resoldre dubtes concrets o generar funcions petites. Però l’escenari està canviant: els agents d’IA ja no només responen una pregunta puntual, sinó que poden analitzar un repositori, modificar diversos fitxers, proposar una arquitectura, crear proves, documentar canvis o executar tasques encadenades.
Aquesta capacitat obre possibilitats enormes, però també augmenta el risc. Com més autònoma és una eina, més important esdevé definir bé el marc en què ha d’actuar. Un agent pot avançar ràpid, però necessita context. Necessita saber quin problema intenta resoldre, quines restriccions ha de respectar, quines decisions ja s’han pres, quins comportaments no ha de trencar i quins criteris permetran avaluar si el resultat és vàlid.
Sense aquesta informació, la IA pot generar solucions aparentment correctes, però equivocades per al projecte. Pot crear codi que compila, però que no encaixa amb l’arquitectura existent. Pot resoldre el cas més evident, però ignorar situacions límit. Pot introduir dependències innecessàries, duplicar lògica, trencar convencions internes o proposar una solució que funciona de manera aïllada, però no dins del sistema real.
Per això l’SDD guanya importància. No perquè l’especificació sigui una novetat absoluta, sinó perquè en un entorn assistit per IA es converteix en una forma de control, alineació i qualitat. L’especificació ajuda a reduir l’ambigüitat abans que es transformi en codi. També permet que les decisions no depenguin únicament de prompts improvisats o de correccions posteriors, sinó d’una intenció definida des de l’inici.
Eines com GitHub Spec Kit neixen precisament amb aquesta lògica: evitar que el desenvolupament assistit per IA comenci a partir d’instruccions vagues i avançar, en canvi, des de requisits, motivacions i detalls tècnics definits abans de la implementació. La idea no és frenar la velocitat de la IA, sinó donar-li una direcció més clara. En lloc de demanar simplement «construeix aquesta funcionalitat», l’equip defineix primer què ha de resoldre aquesta funcionalitat, per a qui, amb quins límits i sota quines condicions es podrà considerar acabada.
Aquest canvi és important perquè sovint el deute tècnic no neix d’una gran decisió equivocada, sinó de petites ambigüitats acumulades. Una validació no definida, una regla de negoci implícita, un cas límit oblidat o una integració mal entesa poden semblar detalls menors al principi. Però quan la IA genera codi a gran velocitat, aquests buits també es multipliquen amb més rapidesa.
L’SDD ajuda a introduir una pausa intel·ligent abans de l’execució. No una pausa burocràtica, sinó una pausa de claredat. Permet pensar abans de produir, alinear abans d’automatitzar i validar abans d’assumir que alguna cosa funciona. En l’era dels agents d’IA, aquesta capacitat de definir bé la feina pot ser tan important com la capacitat d’escriure codi.
Què hauria d’incloure una bona especificació
Una bona especificació no ha de ser un document interminable. Tampoc no hauria de convertir-se en una barrera que retardi qualsevol avenç. La seva funció és molt més pràctica: fer explícit allò que, altrament, quedaria repartit entre converses, suposicions, decisions implícites i correccions posteriors.
El primer punt és definir bé el problema que es vol resoldre. Abans de descriure pantalles, components o funcions, convé explicar quina necessitat existeix i per què val la pena abordar-la. No és el mateix dir «necessitem un formulari nou» que dir «necessitem reduir els abandonaments en el procés de registre perquè molts usuaris no completen la creació del compte des del mòbil». La segona formulació ja introdueix context, intenció i un criteri més clar per prendre decisions.
A partir d’aquí, l’especificació hauria de concretar l’objectiu funcional. És a dir, què ha de permetre fer la solució. Si parlem d’un formulari de registre, no n’hi ha prou de demanar «crea un formulari». Cal definir quines dades ha de recollir, quins camps són obligatoris, quines validacions s’apliquen, què passa si el correu electrònic ja existeix, com es confirma l’alta, quins missatges d’error es mostren i quin comportament ha de tenir en diferents dispositius.
També és important identificar els usuaris o casos d’ús afectats. Una mateixa funcionalitat pot tenir implicacions diferents per a un usuari nou, un usuari recurrent, un administrador o un equip intern. La IA pot generar una solució aparentment vàlida per al cas principal, però deixar sense resoldre escenaris secundaris que són importants per al negoci o per a l’experiència real del producte.
Un altre element clau és delimitar l’abast. Una bona especificació hauria d’explicar què hi entra i què en queda fora. Aquesta part evita molts malentesos. Per exemple, una funcionalitat pot incloure el registre amb correu electrònic i contrasenya, però no l’autenticació amb Google o LinkedIn. Pot incloure validacions bàsiques, però no una integració completa amb un CRM. Pot contemplar la versió mòbil, però deixar per a una fase posterior determinats ajustos avançats d’accessibilitat. Definir aquests límits no redueix l’ambició del projecte; el fa més controlable.
L’especificació també hauria de recollir les restriccions tècniques. Això inclou el framework que s’ha d’utilitzar, les convencions del projecte, les dependències permeses, els patrons d’arquitectura existents, els requisits de rendiment, seguretat o compatibilitat, i qualsevol decisió tècnica que no hauria de quedar a l’atzar. En un entorn amb IA, aquesta part és especialment rellevant, perquè el model pot proposar solucions correctes en abstracte, però poc adequades per a l’stack real del projecte.
Juntament amb això, convé incloure regles de negoci i casos límit. Moltes funcionalitats fallen no perquè el flux principal estigui mal dissenyat, sinó perquè no es van pensar bé les excepcions. Què passa si un usuari intenta registrar-se amb un correu electrònic ja utilitzat? Què passa si perd la connexió a mig procés? Com ha de respondre el sistema si una API externa no està disponible? Quin missatge rep l’usuari si la contrasenya no compleix els requisits? Aquests detalls són els que separen un prototip ràpid d’una solució preparada per funcionar en un entorn real.
Finalment, una especificació hauria d’incorporar criteris d’acceptació i validació. És a dir, com sabrem que la funcionalitat està acabada i funciona correctament. Això pot incloure proves manuals, tests automatitzats, revisió d’accessibilitat, comprovacions de rendiment o validacions de seguretat. Sense aquests criteris, el desenvolupament queda obert a interpretacions massa subjectives: sembla que funciona, però ningú no ha definit amb precisió què significa funcionar.
En aquest sentit, una bona especificació no només ajuda la IA a generar respostes millors. També ajuda l’equip a pensar millor. Obliga a convertir intuïcions en decisions, desitjos en requisits i expectatives en criteris verificables. I aquesta claredat és precisament el que permet que la velocitat del desenvolupament assistit per IA no es converteixi en una successió de solucions ràpides, però fràgils.
L’SDD no és tornar al desenvolupament feixuc: és reduir l’ambigüitat
Una de les primeres objeccions que pot aparèixer davant de l’Specification-Driven Development és comprensible: significa això tornar a escriure documents llargs abans de poder programar? És una manera de recuperar processos feixucs, lents i poc flexibles? La resposta hauria de ser clara: no. L’SDD no consisteix a omplir el projecte de documentació estàtica, sinó a reduir l’ambigüitat abans que aquesta ambigüitat es converteixi en codi.
Per això convé no confondre especificació amb burocràcia. Una especificació útil no és un document etern, tancat i immòbil que pretén anticipar-ho tot des del primer dia. És una eina de treball. Pot començar sent breu, créixer a mesura que el projecte guanya complexitat, versionar-se amb el codi i revisar-se quan canvien les necessitats del producte o apareixen nous aprenentatges.
En aquest sentit, l’SDD no ha de competir amb les metodologies àgils. Pot conviure perfectament amb iteracions curtes, lliuraments incrementals i cicles de feedback freqüents. De fet, pot reforçar-los. Una especificació clara no impedeix iterar; ajuda que cada iteració tingui una direcció més precisa. Permet saber què s’està provant, quina hipòtesi es vol validar i quins criteris s’han de complir abans de considerar que una funcionalitat està a punt.
La diferència rau en l’enfocament. No es tracta de documentar-ho tot per endavant ni de bloquejar el desenvolupament fins que cada detall estigui tancat. Es tracta de documentar prou perquè les persones i les eines d’IA treballin amb un marc comú. En molts casos, una bona especificació pot ser molt més lleugera que un document tradicional: una explicació del problema, uns criteris d’acceptació, algunes restriccions tècniques, casos límit rellevants i una definició clara d’allò que queda dins i fora de l’abast.
Aquesta claredat és especialment valuosa quan intervenen agents d’IA. Si l’equip humà ja pot malinterpretar una tasca poc definida, una eina automatitzada també pot fer-ho. La diferència és que pot avançar molt ràpid en una direcció equivocada. L’SDD introdueix una capa prèvia d’intenció compartida: no per alentir el procés, sinó per evitar correccions innecessàries, reelaboració i decisions implícites que després resulten difícils de desfer.
L’especificació, entesa així, no és un fre a la creativitat ni a la velocitat. És una manera de protegir-les totes dues. Permet experimentar sense perdre el marc, accelerar sense deixar de validar i col·laborar amb IA sense convertir cada tasca en una negociació improvisada amb el prompt. Quan el desenvolupament es recolza en una intenció clara, l’equip pot moure’s més ràpid perquè discuteix menys sobre allò que s’hauria d’haver definit abans.
Per això l’SDD no s’hauria de veure com un retorn al passat, sinó com una adaptació necessària al present. En un entorn en què generar codi és cada cop més fàcil, el valor no rau a produir més documentació, sinó a crear millors punts de referència. No es tracta d’escriure per escriure. Es tracta de compartir una intenció prou clara perquè el programari es pugui construir amb més coherència, menys ambigüitat i menys deute futur.
Del desenvolupador que escriu codi a l’equip que dissenya decisions
L’arribada de la IA al desenvolupament de programari no elimina el valor del desenvolupador. El desplaça cap a àrees on el criteri humà encara és més important. Si una eina pot generar codi, proposar solucions o modificar diversos fitxers en poc temps, la pregunta ja no és només qui escriu cada línia, sinó qui defineix el problema, qui avalua la solució i qui decideix si allò generat té sentit dins del producte.
En aquest nou context, la feina tècnica no perd rellevància. Al contrari, exigeix una mirada més àmplia. El desenvolupador ja no només ha d’implementar una tasca, sinó formular-la bé, anticipar riscos, revisar decisions arquitectòniques, detectar incoherències, protegir la mantenibilitat del sistema i validar si una solució encaixa amb les necessitats reals del projecte. La IA pot accelerar l’execució, però no substitueix la responsabilitat de decidir quina direcció val la pena seguir.
Aquí l’Specification-Driven Development aporta una cosa important: converteix l’especificació en un espai d’alineació. No és només un document tècnic perquè algú programi després. És un lloc on producte, disseny, negoci i desenvolupament poden aclarir què es vol aconseguir abans de traduir-ho a codi. Aquesta conversa prèvia pot evitar molts problemes posteriors, perquè obliga a fer visibles les decisions que normalment queden amagades en frases massa generals.
Per exemple, una petició com «millorar el procés d’alta d’usuaris» pot significar coses diferents per a cada perfil. Per al negoci, potser implica augmentar la conversió. Per a UX, reduir la fricció. Per al desenvolupament, simplificar validacions o millorar la integració amb sistemes externs. Per al suport, disminuir errors recurrents. Sense una especificació clara, totes aquestes expectatives poden conviure de manera implícita fins que apareixen els conflictes. Amb l’SDD, aquestes diferències es posen sobre la taula abans d’implementar.
Això també ajuda a millorar la col·laboració entre perfils tècnics i no tècnics. Una bona especificació no hauria d’estar escrita només per a programadors, ni tampoc limitar-se a una descripció superficial de negoci. Hauria de funcionar com un pont: prou clara perquè qualsevol persona implicada entengui l’objectiu, i prou precisa perquè l’equip tècnic pugui convertir-la en una solució robusta. En aquest equilibri rau una part important del seu valor.
En projectes digitals, moltes decisions tècniques tenen conseqüències sobre el producte, l’experiència d’usuari i el negoci. Escollir com validar una dada, quan mostrar un error, quina informació desar, com ordenar un flux o què automatitzar no són decisions purament internes del codi. Afecten l’experiència final, l’eficiència operativa, la seguretat i la capacitat d’escalar. L’SDD ajuda que aquestes decisions no es prenguin per accident, ni quedin delegades en una resposta automàtica de la IA.
Per això el desenvolupament guiat per especificacions no s’hauria d’entendre com una pràctica aïllada de l’equip tècnic. Pot convertir-se en una manera més madura de dissenyar decisions digitals. L’especificació permet que l’equip no només pregunti «què cal programar?», sinó també «quin problema estem resolent?», «quins riscos hem d’evitar?», «com sabrem que això funciona?» i «quin impacte tindrà aquesta decisió en el producte complet?».
En una etapa marcada per l’automatització, aquesta capacitat de formular decisions millors pot ser més valuosa que la velocitat d’execució. Perquè el futur del desenvolupament no dependrà únicament d’equips capaços de produir codi més ràpid, sinó d’equips capaços de pensar millor abans de produir-lo.
Riscos i límits de l’Specification-Driven Development
L’Specification-Driven Development pot aportar ordre, claredat i una millor col·laboració amb eines d’IA, però no convé presentar-lo com una solució automàtica. Una especificació no garanteix per si sola un bon resultat. De fet, si està mal plantejada, pot produir l’efecte contrari: fer que la IA generi mal codi més ràpid, amb més confiança i amb una aparença de rigor que dificulti detectar el problema.
El primer risc rau a confondre una especificació escrita amb una especificació correcta. Un document pot ser clar en la forma, però equivocat en el fons. Pot definir malament el problema, ignorar una regla de negoci important, simplificar massa el context o assumir restriccions tècniques que no encaixen amb el sistema real. En aquest cas, la IA no estarà resolent millor la tasca; simplement estarà executant amb rapidesa una instrucció defectuosa.
També existeix el risc contrari: especificar massa. Si cada funcionalitat queda atrapada en un excés de detall, l’equip pot perdre capacitat d’iteració. Una especificació útil ha d’orientar, no bloquejar. Ha d’establir intenció, límits i criteris de validació, però sense convertir-se en un contracte tan rígid que impedeixi aprendre, corregir o adaptar la solució a mesura que apareixen noves dades. L’objectiu no és anticipar-ho tot, sinó reduir prou l’ambigüitat per avançar amb més criteri.
Un altre límit important és que la IA pot continuar interpretant malament el context. Encara que existeixi una bona especificació, un agent pot no comprendre del tot l’arquitectura del projecte, les convencions internes, les dependències existents o les decisions tècniques que ja es van prendre en el passat. Pot inventar una API que no existeix, utilitzar un patró que no encaixa, duplicar lògica ja resolta o introduir una solució que sembla raonable en abstracte, però que no correspon amb el repositori real.
Algunes investigacions recents sobre SDD i agents d’IA apunten precisament en aquesta direcció: el problema no consisteix només a escriure especificacions millors, sinó a aconseguir que els agents estiguin ben connectats al context real del projecte. Un treball publicat a arXiv sobre Spec Kit Agents assenyala que els agents poden mantenir-se «cecs al context» en repositoris grans i canviants, fet que pot derivar en APIs inventades o vulneracions arquitectòniques si no hi ha mecanismes de connexió i validació contra l’entorn real.
Per això les especificacions no haurien de viure separades del sistema. S’han de contrastar amb el codi existent, amb les proves, amb les dependències, amb les convencions de l’equip i amb el comportament real del producte. Una especificació que no es valida pot convertir-se en una font de falsa seguretat. Sembla que la feina està ben definida, però potser està desconnectada d’allò que el sistema permet, necessita o ja conté.
Aquí el criteri humà continua sent imprescindible. L’SDD pot ajudar a ordenar la feina, però no substitueix la revisió tècnica, la conversa entre perfils, el coneixement del producte ni la responsabilitat de decidir. La IA pot proposar, generar i accelerar. L’especificació pot guiar. Però algú ha de comprovar si la solució és adequada, si respecta l’arquitectura, si protegeix l’experiència d’usuari, si evita deute innecessari i si respon realment al problema que es volia resoldre.
En definitiva, l’SDD no elimina els riscos del desenvolupament assistit per IA. Els fa més visibles i més gestionables. El seu valor no rau a prometre resultats perfectes, sinó a crear un marc més clar per pensar, construir, revisar i corregir. I potser aquesta és la seva fortalesa més gran: no substitueix el judici de l’equip, sinó que l’obliga a aparèixer abans que el codi comenci a multiplicar-se.
Conclusió
L’Specification-Driven Development no s’hauria d’entendre com una moda metodològica més ni com una manera sofisticada d’escriure documentació. El seu valor rau en una cosa més profunda: convertir l’especificació en una eina de pensament. Abans de construir, obliga a formular. Abans d’automatitzar, obliga a aclarir. Abans de demanar codi, obliga a definir la intenció.
Aquesta idea és especialment important en una etapa en què la IA pot produir programari a una velocitat cada vegada més gran. Quan generar codi esdevé més fàcil, la dificultat es desplaça cap a un altre lloc: saber què val la pena construir, per què, per a qui, amb quins límits i sota quins criteris podrem dir que funciona. L’avantatge no estarà només en qui aconsegueixi produir més ràpid, sinó en qui sàpiga orientar millor aquesta velocitat.
L’SDD proposa precisament aquesta pausa estratègica. No una pausa per frenar el desenvolupament, sinó per evitar que l’execució avanci sense prou direcció. Una bona especificació ajuda a separar una idea vaga d’una necessitat real, una solució aparent d’una solució adequada, una funcionalitat generada d’una funcionalitat validada. En aquest procés, l’equip no només documenta el que vol fer: aprèn a pensar millor allò que està intentant construir.
També canvia la relació amb la IA. En lloc de tractar-la com una màquina a la qual es demanen respostes immediates, l’SDD convida a utilitzar-la dins d’un marc més clar. La IA pot ajudar a implementar, revisar, proposar alternatives o detectar incoherències, però necessita una direcció. I aquesta direcció no neix d’un prompt enginyós aïllat, sinó d’una comprensió compartida del problema, del context i dels criteris d’èxit.
Per això, la nova habilitat no és simplement saber demanar codi. És saber definir la intenció. És convertir requisits dispersos en decisions comprensibles. És traduir objectius de producte, negoci, disseny i tecnologia en una especificació que permeti construir amb més coherència. És entendre que la qualitat del resultat depèn tant de l’eina que genera com de la claredat amb què se li indica cap a on ha d’avançar.
Potser el futur del desenvolupament no depengui només d’escriure prompts millors, sinó d’aprendre a formular especificacions millors. Perquè quan el codi s’accelera, la intenció esdevé més important que mai.
Estem utilitzant la IA per escriure codi més ràpid o per construir programari amb més intenció?
Fonts:
Comentaris