Si tu equipo trabaja con agentes de código desde hace meses, es probable que despliegue más. La pregunta incómoda es si también falla menos.
Esta pieza defiende una tesis sencilla de decir y difícil de aplicar: la velocidad la pone la herramienta; la estabilidad la pone el método. Si el equipo no cambia cómo especifica, cómo comprueba y quién decide, la IA solo acelera lo que ya hacía, también los fallos.
Lo que DORA ha visto dos años seguidos
DORA, el programa de investigación de Google sobre equipos de software, mide cada año el rendimiento de la entrega con dos familias de indicadores: el ritmo (cuántos cambios llegan a producción y con qué rapidez) y la estabilidad (cuántos fallan y cuánto cuesta recuperarse). En su informe de 2024 estimó que, a medida que aumentaba la adopción de IA, las dos bajaban:
DORA lo explicó entonces así: mejorar el proceso de desarrollo no mejora por sí solo la entrega, al menos sin respetar lo básico, como los lotes pequeños y unos mecanismos de prueba sólidos.
En 2025, con respuestas de casi 5.000 profesionales, una de las dos cifras cambió de signo. DORA observa ya una relación positiva entre la adopción de IA y el ritmo de entrega. La otra no: la adopción de IA sigue teniendo una relación negativa con la estabilidad de la entrega. Es decir, los equipos ya van más rápido, pero no fallan menos.
Riesgo Son correlaciones en encuestas, no causas demostradas, y las cifras de 2024 son estimaciones. El anuncio de 2025 no da un porcentaje para la estabilidad. Nada de esto dice que la IA estropee tu software. Dice que la estabilidad no sube sola cuando sube la velocidad.
Por qué la velocidad llega sola y la estabilidad no
Con un agente, generar un cambio cuesta mucho menos que antes. Comprobarlo cuesta lo mismo. Si nada más cambia, el equipo produce más cambios con la misma capacidad de filtrarlos, y la diferencia acaba en producción.
DORA lo resume en su anuncio de 2025: la IA acelera el desarrollo, pero esa aceleración puede dejar al descubierto debilidades más adelante. Y concreta cuáles: sin sistemas de control sólidos, como pruebas automáticas fiables, un control de versiones maduro y ciclos de respuesta rápidos, más volumen de cambios lleva a más inestabilidad. Es la misma idea de su informe de 2025, que describe la IA como un amplificador de las fortalezas y las debilidades que la organización ya tiene, y de la que partimos en antes del agente, la red.
La herramienta decide cuántos cambios puedes producir. El método decide cuántos de esos cambios merecen llegar a producción.
Qué cambia en la práctica
No hace falta frenar al agente. Hace falta que cada cambio que produce pase por una red que antes era opcional y ahora no lo es. Son cuatro prácticas y funcionan juntas:
- Criterios de aceptación escritos antes del código. Si lo que tiene que cumplir el cambio solo está en la cabeza de alguien, nada lo puede comprobar. Es la base de Spec-Driven Development (SDD), el desarrollo guiado por especificaciones.
- Cambios pequeños. Un cambio pequeño se revisa, se prueba y se deshace. Uno grande se aprueba por cansancio.
- Deshacer sin drama. Si volver atrás es fácil, un fallo es un incidente corto. Si no lo es, es una semana perdida.
- Comprobación automática antes que humana. La integración continua filtra lo mecánico; la persona revisa lo que tiene riesgo.
La primera es la que más se salta. Escribir los criterios antes permite convertirlos en la puerta del merge, y es lo que explicamos en Spec-Driven Development con IA. Vale igual para los requisitos de seguridad, como contamos en el código del agente pasa los tests y no es seguro.
La segunda y la tercera son las que DORA destaca en su modelo de capacidades para equipos con IA: trabajar en lotes pequeños es especialmente útil en un entorno asistido por IA, y como la IA aumenta la velocidad de los cambios, el control de versiones se convierte en una red de seguridad crítica. Su recomendación es que los equipos dominen las funciones de revertir y deshacer. Cómo prepararlo está en cómo deshacer lo que hace un agente de código.
La cuarta cambia el papel de la revisión. En un webinar de InfoQ recogido el 16 de octubre de 2026 se dijo que la revisión manual línea a línea no puede seguir el ritmo de lo que producen los agentes: las comprobaciones de estilo y sintaxis tienen que ir a la integración continua, y la persona tiene que revisar arquitectura, intención de negocio y requisitos no funcionales. Cómo encaja con el resto del proceso está en revisar código generado por IA. Y una persona decide donde hay riesgo.
Cómo saber si a tu equipo le está pasando
La trampa es medir solo la mitad. Si el equipo mira cuántos despliegues hace, la IA siempre gana. Si mira también cuántos de esos cambios hay que corregir o revertir después, aparece la otra mitad. Mide las dos a la vez, con la misma frecuencia, y compáralas con lo que tenías antes de los agentes.
Qué indicadores elegir está en KPIs de equipos de desarrollo con IA. Y si el gasto en IA del equipo tiene que justificarse en el presupuesto, la estabilidad forma parte de la tesis de valor que conviene pedirle al equipo: entregar más rápido lo que luego hay que rehacer no es un ahorro.
Una segunda mirada
Si quieres revisar con alguien de fuera qué filtra hoy cada cambio de tu equipo antes de llegar a producción, el diagnóstico es gratuito, y si en el diagnóstico no vemos diferencia, no hay Quick-start. Antes, puedes ver en qué punto estás con el autodiagnóstico de SDD. Cómo es el resto del camino está en AI-Accelerated Development.
Preguntas frecuentes
¿La IA hace que el software sea menos estable?
No hay pruebas de que la IA, por sí sola, estropee el software. Lo que DORA observa dos años seguidos es una asociación: en las organizaciones con más adopción de IA, la estabilidad de la entrega es menor. Es una correlación en encuestas, no una causa demostrada. La lectura útil es otra: la estabilidad no sube sola cuando sube la velocidad.
¿Qué dice exactamente DORA sobre la IA y la velocidad de entrega?
En 2024, DORA estimó que, a medida que aumentaba la adopción de IA, el ritmo de entrega bajaba un 1,5 % y la estabilidad de la entrega un 7,2 %. En 2025, con respuestas de casi 5.000 profesionales, la relación con el ritmo de entrega ya es positiva, pero la relación con la estabilidad sigue siendo negativa.
¿Por qué sube la velocidad y no la estabilidad?
Porque generar cambios se ha abaratado y comprobarlos no. DORA lo explica así: sin sistemas de control sólidos, como pruebas automáticas fiables, un control de versiones maduro y ciclos de respuesta rápidos, más volumen de cambios lleva a más inestabilidad. La herramienta acelera; la red que filtra cada cambio la tiene que poner el equipo.
¿Qué prácticas protegen la estabilidad cuando el equipo usa agentes de código?
Cuatro, y funcionan juntas: criterios de aceptación escritos antes del código, cambios pequeños, la capacidad de deshacer cualquier cambio sin drama y una comprobación automática en cada cambio antes de la revisión humana. Donde el riesgo es alto, decide una persona.
¿Sigue haciendo falta revisar el código a mano?
Sí, pero no línea a línea. En un webinar de InfoQ recogido el 16 de octubre de 2026 se dijo que la revisión manual línea a línea no aguanta el ritmo de los agentes: las comprobaciones de estilo y sintaxis van a la integración continua, y la persona revisa arquitectura, intención y requisitos no funcionales.
¿Cómo sé si a mi equipo le está pasando?
Mide a la vez cuánto entregas y cuánto tienes que corregir o revertir después. Si los despliegues suben y los fallos tras el cambio no bajan, la IA está acelerando también lo que ya fallaba. Mirar solo una de las dos cifras esconde el problema.
Fuentes
- Nathen Harvey y Derek DeBellis (DORA), «Announcing the 2024 DORA report», Google Cloud Blog, 23 de octubre de 2024.
- Nathen Harvey y Derek DeBellis (DORA), «Announcing the 2025 DORA Report: State of AI-Assisted Software Development», Google Cloud Blog, 23 de septiembre de 2025 (casi 5.000 profesionales encuestados).
- DORA, «State of AI-assisted Software Development 2025», 2025 (sin fecha exacta visible; consultado el 21 de octubre de 2026).
- Kevin M. Storer y Derek DeBellis, «Introducing the DORA AI Capabilities Model», Google Cloud Blog, 23 de septiembre de 2025.
- Olimpiu Pop, «AI in Production: Panellists Highlight Silent Failures, Harness Engineering, and Agent Governance», InfoQ, 16 de octubre de 2026.
- Las citas de fuentes en inglés están traducidas por onext. La lista de cuatro prácticas y la forma de medir son elaboración propia de onext.
Bernat López es fundador y CEO de onext, boutique de IA. Acompaña a equipos de desarrollo y de producto a trabajar con IA con método —especificación antes de programar, una persona que decide donde hay riesgo y Spec-Driven Development— y aplica a su propia empresa lo que propone: onext funciona con su propio sistema agéntico.
LinkedIn →