Quan un equip de desenvolupament comença un projecte des de zero, la temptació de delegar-ho tot en agents d’intel·ligència artificial és enorme. Aquests agents de codi prometen velocitat, imiten patrons d’una base de codi saludable i fan que les proves passin en temps rècord. No obstant, el problema sorgeix quan el repositori és buit: no hi ha referències, no hi ha regles establertes, i l’agent no té criteri per decidir com estructurar el projecte. Com a resultat, apareixen fitxers de mil línies, contractes inconsistents i criteris d’èxit impossibles de verificar. Aquesta història no és única, i per a aquells que treballem en aplicacions a mida a Q2BSTUDIO, trobar un equilibri entre velocitat i disciplina és un repte quotidià.
La frustració de veure com un agent construeix exactament el que se li va demanar, però res del que realment es necessitava, va portar a la creació d’un marc de treball basat en especificacions. La idea central és capturar les decisions ja preses en lloc de descobrir-les mitjançant preguntes estructurades. Això evita que la documentació i el codi es desincronitzin, una cosa que passa sovint quan els agents generen artefactes sense supervisió. El marc proposa un cicle de cinc passos: capturar, analitzar, planificar, executar i convergir. Cada artefacte —constitució, model de dades, interfície— es manté viu i subjecte a verificacions creuades. Una anàlisi periòdica detecta contradiccions com límits de participants diferents en diversos documents, o principis de TDD que es violen perquè no hi ha cap mecanisme que els faci complir.
L’interessant és que aquest enfocament no busca eliminar l’emoció del desenvolupament, sinó canalitzar-la. A Q2BSTUDIO, quan abordem projectes d’IA o solucions cloud amb AWS i Azure, la disciplina que aporta un marc estructurat és crítica. No només per evitar errors tècnics, sinó per garantir que la ciberseguretat no quedi relegada a un segon pla. Per exemple, un agent pot generar un proxy local amb un port mal configurat, i si no hi ha una constitució que exigeixi variables d’entorn, aquest error passa desapercebut fins que algú hi ensopega tres mesos després. El marc converteix aquests gotchas en principis versionats actualitzats amb cada incident.
Un altre aspecte clau és la verificació contra el codi real. No n’hi ha prou que els artefactes estiguin ben escrits; han de reflectir fidelment què fa el codi. Una anàlisi de deriva (drift) pot revelar que la documentació diu CommonJS mentre que el codi ja és ESM. Aquesta discrepància es registra, es corregeix i es versiona com un pedaç a la constitució. Així, el marc no només manté la coherència, sinó que construeix una memòria institucional del projecte. Això és especialment útil quan es treballa amb business intelligence i Power BI, on els models de dades evolucionen ràpidament i qualsevol desajust pot invalidar informes sencers.
No obstant, aquest nivell de disciplina té un cost. No és un sistema lleuger; està pensat per a projectes greenfield o grans girs, no per a bases de codi madures on el valor afegit és mínim. La pregunta inevitable és si realment es necessita tanta maquinària. La resposta depèn del perfil del desenvolupador. Alguns equips prosperen amb un bon fitxer CLAUDE.md i regles clares. D’altres, com els que ens trobem constantment saltant d’una idea a una altra, necessiten fricció deliberada: un sistema que ens obligui a aturar-nos abans de cometre el mateix error per segona vegada.
A Q2BSTUDIO hem vist que la combinació d’agents d’IA amb un marc d’especificacions robust permet escalar projectes de forma segura. No es tracta de frenar la creativitat, sinó d’assegurar que cada decisió quedi registrada i que el codi resultant sigui mantenible. L’automatització de processos, la ciberseguretat i el cloud computing es beneficien enormement d’aquesta metodologia. Perquè al final, la disciplina no és un fi en si mateixa, sinó l’eina que converteix la inspiració en programari sòlid i funcional.
