Métricas DORA en 2026: la Inteligencia Artificial Acelera la Entrega y la Estabilidad Paga la Cuenta
Adoptar inteligencia artificial en el desarrollo correlaciona con más entrega y con más inestabilidad. La telemetría de producción muestra por qué: la mayoría de los fallos vienen de límites de capacidad, no del modelo. Qué cambia eso en las métricas DORA y para quien responde por la plataforma.
Desde hace dos años la conversación sobre inteligencia artificial en el desarrollo de software gira en torno a la velocidad. Se entrega más rápido, se escribe código más rápido, se revisa más rápido. Esa parte se confirmó y está medida.
Lo que también está medido, y circula mucho menos, es lo que ocurre del otro lado. La misma investigación que registra la ganancia de velocidad registra, año tras año, que la estabilidad de la entrega no acompaña. Y la telemetría de producción dice dónde se pierde.
Qué cambió en el informe de referencia del sector
DORA, el programa de investigación que mide el desempeño de entrega de software desde hace más de una década, cambió de nombre y de método en 2025. Pasó a llamarse State of AI-assisted Software Development, y abandonó los grupos de desempeño que todo el mundo citaba, los cuatro niveles de bajo a elite, sustituyéndolos por siete arquetipos construidos sobre ocho medidas.
El cambio no es cosmético. Los niveles describían equipos a lo largo de un único eje, del peor al mejor. Los arquetipos admiten que un equipo puede entregar mucho y ser inestable, o ser estable y lento, y que esas son situaciones distintas y no grados de la misma cosa.
Quien sigue citando "equipo de elite" a partir de datos de 2025 está citando una categoría que dejó de existir.
La adopción ya no es la variable interesante
Cuando casi todo el mundo adopta una práctica, la adopción deja de explicar diferencias de resultado. La pregunta útil pasa a ser otra: qué separa a las organizaciones donde la inteligencia artificial produjo una ganancia sostenida de aquellas donde produjo una ganancia seguida de más incidentes.
El patrón que no desaparece con más adopción
La investigación de 2025 es consistente en un punto incómodo. El uso de inteligencia artificial correlaciona positivamente con el rendimiento de entrega, con la eficacia individual percibida y con el desempeño organizacional. Y correlaciona, al mismo tiempo, con mayor inestabilidad de entrega.
Vale la pena detenerse aquí, porque la lectura fácil de este resultado es errónea. No dice que la inteligencia artificial degrade la calidad del código. Dice que el volumen y la cadencia de cambios suben más rápido que la capacidad del sistema para absorberlos con seguridad.
La conclusión que el propio informe extrae es que el desafío definidor dejó de ser la velocidad. Pasó a ser la estabilidad.
Lo que muestra la telemetría de producción, y las encuestas no
Los datos anteriores vienen de encuesta. Lo que sigue viene de observación directa, lo que le da otro peso.
Este es el número que cambia la naturaleza del problema. La mayoría de los fallos de inteligencia artificial en producción no es un problema de modelo. Es un problema de cuotas, de límites de tasa, de concurrencia y de dimensionamiento. Es decir, es infraestructura.
Y hay un segundo detalle en la misma fuente que agrava la cuenta. Siete de cada diez organizaciones ejecutan tres o más modelos en paralelo, lo que multiplica los puntos donde se puede alcanzar un límite, y distribuye la responsabilidad entre proveedores distintos con reglas distintas.
Por qué es un problema de plataforma y no de modelo
Se junta lo que dicen las dos fuentes, y el cuadro cierra.
La encuesta dice que la entrega acelera y la estabilidad sufre. La telemetría dice que, cuando la parte de inteligencia artificial falla en producción, la causa dominante es capacidad. Ambas apuntan al mismo sitio: la arquitectura que sirve a los modelos, no los modelos que ella sirve.
Esto tiene una consecuencia práctica incómoda para quien decide la inversión. La respuesta a la inestabilidad asociada a inteligencia artificial no es cambiar de modelo, ni afinar prompts, ni esperar la versión siguiente. Es trabajo de ingeniería de plataforma: límites explícitos, degradación controlada cuando la cuota se agota, aislamiento entre servicios que comparten el mismo proveedor, e instrumentación que distinga un fallo de modelo de un fallo de capacidad.
Ninguna de esas cosas se compra en una suscripción.
La métrica que pasa a decidir
Las métricas DORA se organizan en dos ejes. Rendimiento, que reúne frecuencia de despliegue, tiempo de espera hasta que el cambio llega a producción y, desde 2024, también el tiempo hasta reponer el servicio. Y estabilidad, que reúne tasa de fallo de cambio y la más reciente tasa de retrabajo.
Lo que suele pasar desapercibido es un cambio de vocabulario con significado real. El antiguo tiempo medio de reposición, conocido por la sigla MTTR, fue reposicionado como tiempo de recuperación de despliegue fallido. No es lo mismo. El primero mide cuánto tarda en reponerse un servicio, sea cual sea la causa. El segundo mide específicamente la capacidad de deshacer lo que se acaba de hacer.
En una operación donde la cadencia de cambios subió por vía de inteligencia artificial, es esta segunda métrica la que separa a quien absorbe el coste de la inestabilidad de quien lo sufre. Entregar cinco veces más rápido solo es una ganancia si revertir sigue tardando minutos.
Dónde entra la disciplina de operación
Nada de esto es un argumento contra adoptar inteligencia artificial en el desarrollo. Las ganancias de rendimiento están medidas y son reales.
Es un argumento sobre dónde tiene que ir la inversión siguiente. Una organización que aceleró la entrega y no reforzó la plataforma que la sostiene compró velocidad a crédito, y la factura llega en incidentes.
El trabajo concreto suele ser este, por orden de retorno:
- Instrumentar la distinción entre fallo de modelo y fallo de capacidad. Sin eso, todos los fallos parecen problemas de modelo, y la respuesta es siempre la equivocada.
- Definir y probar la degradación controlada. Qué ocurre cuando la cuota se agota a media tarde, y quién decide qué queda fuera.
- Medir el tiempo de recuperación de despliegue fallido, y no solo la frecuencia de despliegue. La primera métrica es la que protege; la segunda es la que impresiona.
- Aislar servicios que comparten proveedor. Tres modelos en paralelo con el mismo límite de cuenta no son tres caminos independientes.
Cuándo esto todavía no es prioridad
Conviene decir también cuándo este asunto no es el más urgente, para no convertirlo todo en prioridad.
Si el uso de inteligencia artificial en la operación es residual, o si todavía no está en producción con tráfico real de clientes, el riesgo descrito arriba es teórico. En ese caso, la prioridad sigue siendo la fiabilidad de la operación existente: recuperación probada, propiedad clara de los sistemas críticos y objetivos de servicio definidos.
El problema descrito en este artículo aparece cuando la cadencia de entrega ya subió y la plataforma sigue dimensionada para la cadencia anterior.
Preguntas frecuentes
¿La inteligencia artificial hace la entrega menos fiable por naturaleza? No. La investigación muestra correlación entre adopción e inestabilidad, no causalidad directa del modelo. El mecanismo observado es de volumen: más cambios, más rápido, sobre plataformas dimensionadas para el ritmo anterior.
¿Qué es la nueva métrica de recuperación de DORA? El antiguo tiempo medio de reposición fue reposicionado como tiempo de recuperación de despliegue fallido. Mide específicamente cuánto se tarda en deshacer un cambio que salió mal, y no el tiempo de reposición de cualquier avería.
¿Cómo se distingue un fallo de capacidad de un fallo de modelo? Por la instrumentación. Códigos de error de límite de tasa, tiempo de espera en cola y tasa de rechazo por cuota son señales de capacidad. Respuestas fuera de formato o incorrectas son señales de modelo. Sin separar ambos en la observabilidad, todo se lee como problema de modelo.
¿Sigue teniendo sentido citar los niveles de desempeño de DORA? No, a partir de 2025. Los cuatro niveles fueron sustituidos por siete arquetipos construidos sobre ocho medidas. Citar "elite" con datos recientes es citar una categoría que ya no existe en el informe.
¿Esto exige un equipo dedicado? Exige competencia dedicada, que no es lo mismo que plantilla fija. El trabajo es de ingeniería de plataforma y fiabilidad, y puede ser interno, reforzado, o gestionado en régimen de capacidad dedicada.
Conclusión
La pregunta que abre este artículo tiene respuesta. La inteligencia artificial hace entregar más rápido, y eso está medido. Lo que también está medido es que la estabilidad no acompaña sola, y que la mayor parte de los fallos en producción viene de límites de capacidad y no del modelo.
Quien responde por una plataforma tiene aquí un argumento poco común: una inversión de fiabilidad que no compite con la agenda de inteligencia artificial, la sostiene. Sobre qué hacer cuando la función de fiabilidad no tiene dueño, vale la pena leer también cuándo compensa construir un equipo de fiabilidad interno y cuándo compensa contratar capacidad, y por qué tener copias de los datos no es lo mismo que poder volver a operar.
Para entender dónde la plataforma actual absorbe el aumento de cadencia y dónde se rompe, xGrowth empieza por una reunión breve, sin compromiso, sobre fiabilidad y operación: Reservar una Sesión de Orientación.