Si el teu equip treballa amb agents de codi des de fa mesos, és probable que desplegui més. La pregunta incòmoda és si també falla menys.
Aquesta peça defensa una tesi senzilla de dir i difícil d'aplicar: la velocitat la posa l'eina; l'estabilitat la posa el mètode. Si l'equip no canvia com especifica, com comprova i qui decideix, la IA només accelera el que ja feia, també les fallades.
El que DORA ha vist dos anys seguits
DORA, el programa de recerca de Google sobre equips de programari, mesura cada any el rendiment del lliurament amb dues famílies d'indicadors: el ritme (quants canvis arriben a producció i amb quina rapidesa) i l'estabilitat (quants fallen i quant costa recuperar-se'n). En el seu informe de 2024 va estimar que, a mesura que augmentava l'adopció d'IA, totes dues baixaven:
DORA ho va explicar llavors així: millorar el procés de desenvolupament no millora per si sol el lliurament, si més no sense respectar el bàsic, com els lots petits i uns mecanismes de prova sòlids.
El 2025, amb respostes de gairebé 5.000 professionals, una de les dues xifres va canviar de signe. DORA ja observa una relació positiva entre l'adopció d'IA i el ritme de lliurament. L'altra no: l'adopció d'IA continua tenint una relació negativa amb l'estabilitat del lliurament. És a dir, els equips ja van més ràpid, però no fallen menys.
Risc Són correlacions en enquestes, no causes demostrades, i les xifres de 2024 són estimacions. L'anunci de 2025 no dona cap percentatge per a l'estabilitat. Res d'això diu que la IA faci malbé el teu programari. Diu que l'estabilitat no puja sola quan puja la velocitat.
Per què la velocitat arriba sola i l'estabilitat no
Amb un agent, generar un canvi costa molt menys que abans. Comprovar-lo costa el mateix. Si no canvia res més, l'equip produeix més canvis amb la mateixa capacitat de filtrar-los, i la diferència acaba a producció.
DORA ho resumeix en el seu anunci de 2025: la IA accelera el desenvolupament, però aquesta acceleració pot deixar al descobert febleses més endavant. I concreta quines: sense sistemes de control sòlids, com proves automàtiques fiables, un control de versions madur i cicles de resposta ràpids, més volum de canvis porta a més inestabilitat. És la mateixa idea del seu informe de 2025, que descriu la IA com un amplificador de les fortaleses i les febleses que l'organització ja té, i de la qual partim a abans de l'agent, la xarxa.
L'eina decideix quants canvis pots produir. El mètode decideix quants d'aquests canvis mereixen arribar a producció.
Què canvia a la pràctica
No cal frenar l'agent. Cal que cada canvi que produeix passi per una xarxa que abans era opcional i ara no ho és. Són quatre pràctiques i funcionen juntes:
- Criteris d'acceptació escrits abans del codi. Si el que ha de complir el canvi només és al cap d'algú, res no ho pot comprovar. És la base de Spec-Driven Development (SDD), el desenvolupament guiat per especificacions.
- Canvis petits. Un canvi petit es revisa, es prova i es desfà. Un de gran s'aprova per cansament.
- Desfer sense drama. Si tornar enrere és fàcil, una fallada és un incident curt. Si no ho és, és una setmana perduda.
- Comprovació automàtica abans que humana. La integració contínua filtra el que és mecànic; la persona revisa el que té risc.
La primera és la que més se salta. Escriure els criteris abans permet convertir-los en la porta del merge, i és el que expliquem a Spec-Driven Development amb IA. Val igual per als requisits de seguretat, com expliquem a el codi de l'agent passa els tests i no és segur.
La segona i la tercera són les que DORA destaca en el seu model de capacitats per a equips amb IA: treballar en lots petits és especialment útil en un entorn assistit per IA, i com que la IA augmenta la velocitat dels canvis, el control de versions es converteix en una xarxa de seguretat crítica. La seva recomanació és que els equips dominin les funcions de revertir i desfer. Com preparar-ho és a com desfer el que fa un agent de codi.
La quarta canvia el paper de la revisió. En un seminari web d'InfoQ recollit el 16 d'octubre de 2026 es va dir que la revisió manual línia a línia no pot seguir el ritme del que produeixen els agents: les comprovacions d'estil i sintaxi han d'anar a la integració contínua, i la persona ha de revisar arquitectura, intenció de negoci i requisits no funcionals. Com encaixa amb la resta del procés és a revisar codi generat per IA. I una persona decideix on hi ha risc.
Com saber si al teu equip li està passant
El parany és mesurar només la meitat. Si l'equip mira quants desplegaments fa, la IA sempre guanya. Si mira també quants d'aquests canvis s'han de corregir o revertir després, apareix l'altra meitat. Mesura les dues alhora, amb la mateixa freqüència, i compara-les amb el que tenies abans dels agents.
Quins indicadors triar és a KPI d'equips de desenvolupament amb IA. I si la despesa en IA de l'equip s'ha de justificar al pressupost, l'estabilitat forma part de la tesi de valor que convé demanar a l'equip: lliurar més ràpid el que després s'ha de refer no és un estalvi.
Una segona mirada
Si vols revisar amb algú de fora què filtra avui cada canvi del teu equip abans d'arribar a producció, el diagnòstic és gratuït, i si al diagnòstic no veiem diferència, no hi ha Quick-start. Com és la resta del camí és a AI-Accelerated Development.
Preguntes freqüents
La IA fa que el programari sigui menys estable?
No hi ha proves que la IA, per si sola, faci malbé el programari. El que DORA observa dos anys seguits és una associació: a les organitzacions amb més adopció d'IA, l'estabilitat del lliurament és més baixa. És una correlació en enquestes, no una causa demostrada. La lectura útil és una altra: l'estabilitat no puja sola quan puja la velocitat.
Què diu exactament DORA sobre la IA i la velocitat de lliurament?
El 2024, DORA va estimar que, a mesura que augmentava l'adopció d'IA, el ritme de lliurament baixava un 1,5 % i l'estabilitat del lliurament un 7,2 %. El 2025, amb respostes de gairebé 5.000 professionals, la relació amb el ritme de lliurament ja és positiva, però la relació amb l'estabilitat continua sent negativa.
Per què puja la velocitat i no l'estabilitat?
Perquè generar canvis s'ha abaratit i comprovar-los no. DORA ho explica així: sense sistemes de control sòlids, com proves automàtiques fiables, un control de versions madur i cicles de resposta ràpids, més volum de canvis porta a més inestabilitat. L'eina accelera; la xarxa que filtra cada canvi l'ha de posar l'equip.
Quines pràctiques protegeixen l'estabilitat quan l'equip fa servir agents de codi?
Quatre, i funcionen juntes: criteris d'acceptació escrits abans del codi, canvis petits, la capacitat de desfer qualsevol canvi sense drama i una comprovació automàtica a cada canvi abans de la revisió humana. On el risc és alt, decideix una persona.
Encara cal revisar el codi a mà?
Sí, però no línia a línia. En un seminari web d'InfoQ recollit el 16 d'octubre de 2026 es va dir que la revisió manual línia a línia no aguanta el ritme dels agents: les comprovacions d'estil i sintaxi van a la integració contínua, i la persona revisa arquitectura, intenció i requisits no funcionals.
Com sé si al meu equip li està passant?
Mesura alhora quant lliures i quant has de corregir o revertir després. Si els desplegaments pugen i les fallades després del canvi no baixen, la IA està accelerant també el que ja fallava. Mirar només una de les dues xifres amaga el problema.
Fonts
- Nathen Harvey i Derek DeBellis (DORA), «Announcing the 2024 DORA report», Google Cloud Blog, 23 d'octubre de 2024.
- Nathen Harvey i Derek DeBellis (DORA), «Announcing the 2025 DORA Report: State of AI-Assisted Software Development», Google Cloud Blog, 23 de setembre de 2025 (gairebé 5.000 professionals enquestats).
- DORA, «State of AI-assisted Software Development 2025», 2025 (sense data exacta visible; consultat el 21 d'octubre de 2026).
- Kevin M. Storer i Derek DeBellis, «Introducing the DORA AI Capabilities Model», Google Cloud Blog, 23 de setembre de 2025.
- Olimpiu Pop, «AI in Production: Panellists Highlight Silent Failures, Harness Engineering, and Agent Governance», InfoQ, 16 d'octubre de 2026.
- Les cites de fonts en anglès estan traduïdes per onext. La llista de quatre pràctiques i la manera de mesurar són elaboració pròpia d'onext.
Bernat López és fundador i CEO d'onext, boutique d'IA. Acompanya equips de desenvolupament i de producte a treballar amb IA amb mètode —especificació abans de programar, una persona que decideix on hi ha risc i Spec-Driven Development— i aplica a la seva pròpia empresa el que proposa: onext funciona amb el seu propi sistema agèntic.
LinkedIn →