La intel·ligència artificial ha transformat la manera com concebem el cicle de vida del desenvolupament de programari (SDLC). En qüestió de segons, un model generatiu pot produir fragments de codi, plantilles de proves o manifestos de desplegament. Tanmateix, aquesta velocitat revela una paradoxa: com més ràpid generem implementacions, major és el cost de l'ambigüitat. Si els requisits no són clars, la IA pot crear codi incorrecte a un ritme vertiginós, violant regles de negoci, contractes d'integració o polítiques de seguretat. Per navegar aquesta nova realitat, les organitzacions necessiten un enfocament que posi les especificacions al centre del procés: el desenvolupament guiat per especificacions (spec-driven development).
A Q2BSTUDIO, com a empresa de desenvolupament de programari i tecnologia, hem acompanyat nombrosos equips en l'adopció de metodologies modernes. Entenem que la IA no és un substitut del judici humà, sinó un accelerador que requereix un marc sòlid de control. Aquest article explora com el desenvolupament guiat per especificacions esdevé el pla de control indispensable en l'era de la IA, i com serveis com el desenvolupament d'aplicacions a mida i les solucions al núvol poden beneficiar-se d'aquesta filosofia.
El repte de l'especificació tradicional
Històricament, les especificacions han estat documents temporals: una història d'usuari, un requisit funcional redactat en una eina de gestió, i després la interpretació es dispersa entre el codi, les proves, els comentaris en pull requests i el coneixement operatiu. La IA amplifica aquesta debilitat. Sense límits explícits, un model de llenguatge pot omplir llacunes amb suposicions incorrectes, optimitzar localment o triar valors per defecte que no corresponen a la intenció del negoci. El resultat pot compilar i passar proves unitàries, però incomplir regles de domini, comprometre la seguretat o trencar contractes amb altres sistemes.
Per exemple, imagineu un equip que desenvolupa un mòdul de processament de comandes. Un agent d'IA podria generar una API REST que accepti quantitats negatives o codis de producte no validats simplement perquè el prompt no especificava restriccions. El codi funciona, però el sistema falla en producció a causa de dades invàlides. Aquí és on el desenvolupament guiat per especificacions marca la diferència.
Especificacions com a pla de control durador
El desenvolupament guiat per especificacions inverteix la relació tradicional: l'especificació esdevé autoritativa durant tot el cicle de vida. No es tracta d'un document monolític, sinó d'un conjunt versionat d'artefactes vinculats: contractes OpenAPI, regles de domini, esquemes de dades, decisions d'arquitectura, fluxos d'usuari, requisits no funcionals i criteris d'acceptació executables. L'essencial és que cada decisió material d'implementació es pugui traçar fins a una declaració d'intenció acordada.
Aquest enfocament permet que la IA assisteixi de forma segura. Els enginyers poden proporcionar l'especificació com a entrada a un agent, i el resultat generat s'avalua contra restriccions estables i revisables. A més, facilita la col·laboració entre equips: els analistes de negoci mantenen el què, els arquitectes defineixen el com (amb restriccions), i els desenvolupadors i agents d'IA implementen el detall dins d'aquests límits. El codi segueix sent important, però es converteix en una projecció verificable de l'especificació, no en l'única descripció fiable del sistema.
Reconstruir el cicle de vida al voltant de la intenció executable
No cal substituir el SDLC per una metodologia específica d'IA; es tracta d'ajustar les transicions entre les seves fases. El descobriment ha de produir resultats mesurables i riscos explícits. Els requisits han de separar el comportament del negoci de les preferències d'implementació. L'arquitectura ha de registrar les restriccions que el codi generat ha de respectar. La implementació només hauria de començar quan l'especificació rellevant sigui comprovable. Les proves han de verificar l'especificació, no només exercitar el codi que es va escriure.
Un flux pràctic podria ser: definir el problema, obtenir requisits, redactar l'especificació, validar-la amb les parts interessades, derivar l'arquitectura, implementar contra l'especificació, generar proves des de la mateixa font, integrar de forma contínua, alliberar amb controls observables i retroalimentar l'evidència de producció en la següent revisió de l'especificació. La IA pot assistir en cada pas, però no ha de posseir silenciosament cap límit d'aprovació. Les persones segueixen sent responsables de la intenció, l'acceptació del risc i les compensacions.
A Q2BSTUDIO apliquem aquest principi en els nostres projectes de cloud AWS/Azure, on les especificacions d'infraestructura (com polítiques de xarxa, identitats gestionades, xifrat) es deriven de requisits no funcionals i es validen mitjançant policy-as-code. Això assegura que tant el codi d'aplicació com la infraestructura compleixin amb el mateix conjunt de regles acordades.
Exemple pràctic: especificació d'una API de comandes
Suposem que necessitem construir una funcionalitat d'enviament de comandes. En lloc de descriure-la vagament, definim un contracte explícit: el codi de producte ha de seguir una expressió regular amb caràcters alfanumèrics i guions, la quantitat ha d'estar entre 1 i 100, les respostes exitoses retornen 202 Accepted amb una localització, i les entrades invàlides retornen un problema de validació (400 Bad Request). Aquest conjunt de regles forma part de l'especificació, no del codi. Un enginyer o un agent d'IA pot implementar-lo amb llibertat, però qualsevol desviació serà detectada per les proves d'acceptació executables.
Aquestes proves no són només protecció contra regressió; són criteris d'acceptació vius. Si un agent modifica la implementació, ha de preservar aquestes proves o estendre-les quan l'especificació canviï. La integració contínua verifica que el comportament es manté alineat. Aquest patró s'estén a proves de contracte, proves d'integració, tests de seguretat i, gràcies a eines de BI com Power BI, a la monitorització d'indicadors de rendiment i qualitat en producció.
Governança de canvis generats per IA
La governança no ha de consistir a prohibir eines o afegir aprovacions cerimonials, sinó a centrar-se en l'evidència i l'autoritat. Decideixi quins artefactes pot proposar un agent d'IA, quins pot modificar automàticament i quins requereixen aprovació humana. En general, un agent pot generar bastides, assignacions, proves, documentació i refactoritzacions de baix risc. No hauria de redefinir una API pública, debilitar una política d'autorització, canviar una regla de retenció de dades o acceptar un risc de producció.
És crucial preservar el context de generació: registrar la versió de l'especificació, el model o agent utilitzat, els prompts rellevants, els fitxers modificats i els resultats de validació com a part de la pull request. No cal arxivar cada token conversacional, però sí suficient proveniència per explicar per què existeix un canvi i quines restriccions el van governar. Això esdevé especialment important quan diversos agents treballen en codi d'aplicació, infraestructura (Bicep/Terraform), pipelines i documentació operativa.
Mètriques que importen
Les mètriques han de reflectir la qualitat del lliurament, no la quantitat de sortida d'IA. En lloc de comptar línies de codi generat o nombre de prompts, centri's en la traçabilitat requisit-prova, la taxa de defectes escapats, la taxa de fallades en canvis, el temps de lliurament, el temps mitjà de recuperació, la rotació d'especificacions i la proporció de canvis generats que s'accepten sense retreball substancial. Aquestes mètriques indiquen si realment s'està construint el sistema correcte.
A Q2BSTUDIO, combinem aquestes pràctiques amb la nostra experiència en agents d'IA i transformació digital. Ajudem les empreses a definir especificacions precises en àrees com finances, identitat, seguretat (ciberseguretat) i compliment normatiu, perquè la IA pugui operar dins de límits segurs i productius.
Conclusió
La IA fa que la implementació sigui més barata, cosa que augmenta el cost relatiu de l'ambigüitat. Quan el codi es pot produir ràpidament, una intenció poc clara genera més codi erroni a major velocitat. El desenvolupament guiat per especificacions contraresta aquest risc fent que el comportament acordat, les restriccions i les proves siguin el centre del cicle de vida. No es tracta de formalitzar cada detall, sinó d'aplicar precisió on els errors són costosos: contractes públics, regles financeres, identitat i accés, maneig de dades, integracions, seguretat del desplegament i objectius operatius. Mantingui l'especificació versionada, revisable i connectada a comprovacions executables. Després, utilitzi la IA agressivament dins d'aquests límits per accelerar l'anàlisi, la implementació, les proves, la documentació i l'aprenentatge d'incidents. El principi operatiu és senzill: construeixi el correcte, construeixi'l bé i segueixi demostrant que segueix sent correcte. En l'era de la IA, l'especificació no és un tràmit previ al desenvolupament; és el mecanisme durador que connecta la intenció del negoci amb l'arquitectura, el codi, les proves, el desplegament i l'evidència de producció.
