L'altre dia un equip de desenvolupament va rebre una pull request aprovada en menys de dos minuts. Catorze fitxers, un wrapper de reintents per a un client HTTP, una petita refactorització en un gestor d'errors i una nova dependència. El diff estava net, el missatge de commit era clar i el revisor va donar el vistiplau sense dubtar. Tot i això, ningú hauria pogut explicar per què l'estratègia de backoff tenia aquella forma concreta o per què aquella dependència havia guanyat davant de tres altres que feien el mateix. El codi havia estat generat per un assistent d'intel·ligència artificial (IA), lleugerament ajustat amb un prompt i acceptat ràpidament. Semblava qualsevol altra PR que aquell revisor hagués aprovat aquella setmana. Res en ella deia 'aquí cal fer més preguntes'. Aquest és el problema que moltes converses sobre desenvolupament assistit per IA subestimen: no és que el model escrigui mal codi — la majoria de vegades no ho fa — sinó que el codi amb aparença raonable és exactament el que la revisió de codi mai va ser dissenyada per detectar.
Quan un desenvolupador accepta un suggeriment d'IA sense rastrejar completament per què funciona, i l'envia com un canvi propi, el diff es veu idèntic tant si l'autor va llegir cada línia tres vegades com si va fer clic a 'acceptar' i va passar a la següent pestanya. El revisor que aprova aquella PR no està fent res malament: tenia tres altres pestanyes obertes, una daily en vint minuts i un diff que es llegia net de principi a fi. Però aquesta aprovació significa alguna cosa més silenciosa del que solia. Abans significava 'una persona que entenia això ho avala'. Cada cop més significa 'una persona va mirar la sortida del model i li va semblar plausible'. No és el mateix, i el format de pull request no té manera de distingir entre tots dos casos perquè mai va ser dissenyat per fer-ho.
El cost real d'aquest fenomen no apareix en el moment de l'aprovació, sinó mesos després, quan la lògica de reintents es comporta de manera estranya sota un patró de càrrega que ningú va provar, i la persona que depura busca la raó darrere d'aquest timeout de cinc segons (enfront dels dos segons que utilitza la resta del servei) i no troba res, perquè no hi havia cap raó a trobar, només un nombre que sonava plausible. Aquest buit d'enteniment s'acumula silenciosament, PR a PR, i acaba generant deute tècnic invisible. A Q2BSTUDIO, on treballem diàriament amb aplicacions a mida per a clients de diversos sectors, sabem que la qualitat del software no depèn només que el codi compili i passi tests, sinó que cada decisió tècnica tingui una traçabilitat clara i una comprensió profunda. Per això combinem l'ús d'eines d'IA amb metodologies que preserven la responsabilitat humana a cada línia de codi.
La paradoxa és que el codi generat per IA sol ser correcte sintàcticament i segueix patrons coneguts — backoff exponencial amb jitter, gestió d'excepcions estàndard, temps d'espera raonables —, però precisament per això enganya el revisor. No hi ha res que sembli malament, així que no es fan preguntes. Tanmateix, les preguntes importants no estan al diff: per què tres intents i no cinc? Per què aquest timeout concret? L'excepció TransientError cobreix realment el fracàs que es produeix a la pràctica o és la classe que el model va triar perquè sonava bé? Cap d'aquestes qüestions té una resposta incorrecta, però són desconegudes tant per al revisor com per al desenvolupador que va acceptar el suggeriment. El codi no dona cap senyal que hi hagi incertesa. Una versió escrita a mà per un desenvolupador que hagués estat escalat a les 2 a.m. per aquell mateix endpoint probablement seria gairebé idèntica, però significaria una cosa completament diferent.
Per tancar aquesta bretxa entre el codi correcte i el codi comprès, a Q2BSTUDIO apostem per dues pràctiques que van més enllà del review tradicional. La primera és la proveniència en el moment de la generació del codi. Quan un assistent d'IA produeix un fragment, aquesta informació — juntament amb el prompt utilitzat i el context que tenia el model — hauria de viatjar amb el canvi en lloc de desaparèixer tan bon punt el desenvolupador prem acceptar. Sis mesos després, quan alguna cosa falla, saber exactament què se li va demanar a la IA és la pregunta que qualsevol investigació vol respondre. La segona és un registre de revisió que indiqui què es va revisar realment. Una aprovació en una PR de catorze fitxers no hauria de significar el mateix si el revisor va llegir cada línia que si simplement va fullejar el resum i va confiar en els tests. Una distinció bàsica — 'he traçat la lògica de backoff i l'entenc' davant de 'tests passen, res em va saltar a la vista' — dona a un futur lector alguna cosa amb què treballar, en lloc d'una marca plana que representa ambdós casos. Ambdues mesures són factibles en comparació amb el que els equips ja construeixen per a integració contínua, però requereixen admetre en veu alta que moltes revisions actuals s'assemblen més al segon tipus que al primer.
En el context empresarial, aquesta reflexió cobra especial rellevància quan parlem de serveis cloud a AWS i Azure, ciberseguretat, Business Intelligence amb Power BI i el desenvolupament d'agents d'IA. Tots aquests àmbits exigeixen un nivell de comprensió que va més enllà d'un diff net. Per exemple, en desplegar una aplicació al núvol, l'elecció del tipus d'instància, la configuració d'escalat automàtic o les polítiques de seguretat no poden basar-se en un número que 'sona bé'. De la mateixa manera, en un projecte de BI, els algoritmes de transformació de dades han de ser auditables i justificats, no només funcionar en les dades de prova. I quan parlem d'agents d'IA autònoms, que prenen decisions en temps real, la traçabilitat de cada pas és crítica per a la confiança i el compliment normatiu. A Q2BSTUDIO, integrem aquests principis a cada lliurament: des del disseny d'aplicacions a mida fins a la implantació d'estratègies de ciberseguretat, passant per la migració al núvol i la implementació de quadres de comandament amb Power BI. El nostre enfocament combina la potència de la IA amb l'experiència humana per garantir que cada línia de codi no només sigui correcta, sinó que estigui compresa.
La majoria dels equips que utilitzen assistents d'IA avui no han adoptat cap d'aquestes dues pràctiques. Les pull requests que circulen pels seus pipelines tenen exactament el mateix aspecte de confiança que fa un any, perquè el format no ha canviat, encara que el que hi ha darrere sí ha canviat. Aquesta bretxa es continua tancant silenciosament, un diff net cada vegada. Algú la notarà tard o d'hora, ja sigui perquè un equip decideixi modificar què significa realment un registre de revisió, o perquè un incident prengui la decisió per ells. A Q2BSTUDIO preferim escriure sobre la primera opció: com construir software que no només funcioni, sinó que s'entengui. Perquè, al final, el risc més gran no és que la IA escrigui mal codi, sinó que acceptem codi que sembla correcte sense preguntar-nos per què.
