El cicle de vida del desenvolupament de programari (SDLC) ha experimentat una transformació profunda amb la irrupció de la intel·ligència artificial. Ja no es tracta només d'automatitzar tasques repetitives; la IA pot generar codi, proves, configuracions d'infraestructura i fins manifests de desplegament en qüestió de segons. Tanmateix, la velocitat sense control pot ser perillosa. La part realment costosa del desenvolupament no és escriure codi, sinó definir què ha de fer el sistema, verificar que la implementació coincideix amb aquella intenció i gestionar el canvi a través d'arquitectura, seguretat i operacions. Aquí és on sorgeix el desenvolupament guiat per especificacions (spec-driven development) com una pràctica que retorna el control als equips humans, fins i tot quan els agents d'IA participen activament.
A Q2BSTUDIO, entenem que l'especificació s'ha de convertir en el plànol director del cicle de vida. No parlem de documents monolítics que s'arxiven després de l'anàlisi inicial, sinó d'artefactes vius, versionats i executables: contractes d'API, regles de domini, esquemes de dades, restriccions no funcionals i criteris d'acceptació. Aquests elements defineixen el comportament esperat de forma precisa i revisable. Quan un agent d'IA genera codi a partir d'una especificació, el resultat es pot validar automàticament contra aquells límits explícits, reduint el risc que la IA inventi regles o prengui decisions no autoritzades.
La clau està en invertir la relació tradicional: en lloc que el codi sigui l'única font de veritat, l'especificació passa a ser el plà de control. Cada canvi en codi, proves o infraestructura s'ha de remuntar a una declaració acordada d'intenció. Això no significa que el codi deixi de ser important; al contrari, es converteix en una projecció més fiable perquè està governada per restriccions estables. Per a un equip que treballa amb .NET i Azure, aquesta pràctica permet que l'especificació funcioni com un plà d'enginyeria: constreny la generació de codi, revisa canvis proposats, genera proves de contracte, valida infraestructura i explica el comportament en producció.
Un flux pràctic comença per definir el problema, obtenir requisits, redactar l'especificació, validar-la amb els interessats, derivar l'arquitectura, implementar contra l'especificació, generar proves des de la mateixa font, integrar contínuament, 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ò mai no ha de posseir silenciosament un límit d'aprovació. Les persones continuen sent responsables de la intenció, l'acceptació de riscos i les compensacions.
En aquest nou SDLC, les portes de lliurament canvien de significat. La 'Definició de Llest' (Definition of Ready) ha d'incloure criteris d'acceptació inequívocs, propietat de dades identificada, classificació de seguretat, comportament davant fallades i objectius no funcionals mesurables. La 'Definició d'Acabat' (Definition of Done) requereix traçabilitat des del requisit fins a l'especificació, disseny, codi, proves i telemetria. Una sol·licitud d'extracció (pull request) que afegeix codi funcional sense actualitzar l'especificació que el governa es considera incompleta, igual que una migració de base de dades sense estratègia de reversió.
La iteració es torna més natural: la telemetria de producció pot revelar que un objectiu de latència no era realista, que un flux de treball causa abandonament o que una integració falla sota una configuració d'inquilí específica. Aquesta evidència s'ha de convertir en un canvi d'especificació abans de demanar a un agent que modifiqui la implementació. D'aquesta manera, l'aprenentatge queda explícit i s'evita que el comportament en producció es desviï de la intenció documentada.
Per a les empreses que busquen aplicacions a mida, aquesta metodologia resulta especialment valuosa. En externalitzar el desenvolupament o utilitzar equips interns amb ajuda d'IA, l'especificació actua com un contracte inquebrantable que protegeix la inversió. A Q2BSTUDIO combinem el desenvolupament guiat per especificacions amb les nostres capacitats en IA per oferir solucions robustes, escalables i segures. A més, la integració amb serveis cloud com AWS o Azure, la implementació de mesures de ciberseguretat i l'ús d'eines de BI/Power BI es beneficien de tenir especificacions precises que guiïn la generació de codi i la validació d'infraestructura.
Un exemple concret: suposem que necessitem implementar un mòdul de comandes amb restriccions de format de producte i quantitat. L'especificació defineix el contracte de l'API, els límits de validació, la resposta acceptada, les expectatives d'idempotència, la política d'autorització i l'objectiu de nivell de servei. A partir d'aquí, un agent d'IA pot generar el codi de l'API en .NET i les proves de contracte corresponents. Però la clau és que l'agent no pot desviar-se dels límits fixats: el codi generat ha de superar les mateixes proves que un desenvolupador humà escriuria, i qualsevol canvi en el comportament requereix una modificació aprovada de l'especificació.
La governança dels canvis generats per IA s'ha de centrar en l'evidència i l'autoritat, no en prohibir eines o afegir aprovacions ceremonials. Cal decidir quins artefactes pot proposar un agent, quins pot modificar automàticament i quins requereixen aprovació humana. Per exemple, un agent pot generar bastides, mapats, proves, documentació i refactoritzacions de baix risc, però no ha de redefinir una API pública, debilitar una política d'autorització, canviar una regla de retenció o acceptar un risc de producció. A més, és important preservar el context de generació: la versió de l'especificació, el model o agent utilitzat, les indicacions rellevants, els fitxers modificats i els resultats de validació han de quedar registrats com a part de la sol·licitud d'extracció o les metadades de la compilació.
El pipeline d'integració contínua ha de validar relacions, no només fitxers. Verificar que cada requisit canviat té criteris d'acceptació corresponents, validar documents OpenAPI i JSON Schema, executar proves arquitectòniques que prohibeixin dependències no desitjades, comparar la infraestructura contra Azure Policy, executar anàlisi de seguretat, proves unitàries, d'integració i llindars de rendiment. Finalment, verificar que existeix telemetria per als resultats i modes de fallada declarats a l'especificació.
Les mètriques han de reflectir la qualitat del lliurament, no la quantitat de codi generat per IA. Rastrejar la traçabilitat requisit-prova, la taxa de defectes escapats, la taxa de fallades de canvi, el temps de lliurament, el temps mitjà de recuperació, la volatilitat de l'especificació i la proporció de canvis generats que s'accepten sense retreball substancial. Les línies de codi generat i el nombre d'indicacions són mesures d'activitat; diuen poc sobre si es va construir el sistema correcte.
En resum, la IA abarateix la implementació, cosa que incrementa el cost relatiu de l'ambigüitat. Quan el codi es produeix ràpidament, una intenció poc clara genera més codi incorrecte a major velocitat. El desenvolupament guiat per especificacions contraresta aquest risc col·locant el comportament acordat, les restriccions i l'evidència al centre del cicle de vida. Proporciona als enginyers un llenguatge compartit i als agents d'IA un problema acotat que poden resoldre de manera fiable. No es tracta de formalitzar perfectament 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 en desplegaments i objectius operatius.
A Q2BSTUDIO apliquem aquests principis en cada projecte, ajudant les organitzacions a construir el sistema correcte, construir-lo bé i mantenir la demostració que continua sent correcte al llarg del temps. L'especificació no és paperassa prèvia 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ó. A l'era de la IA, aquesta connexió és més valuosa que mai.
