Acelerar la producción de código sin cambiar el resto del proceso no acelera la entrega: acelera la llegada de los problemas a producción. La velocidad de un equipo de desarrollo no la marca lo rápido que escribe, sino lo rápido que puede cambiar algo con seguridad, y esas dos cosas se han desacoplado en los últimos dos años.
Es un fenómeno medido, no una sospecha.
El informe DORA de 2024 de Google Cloud, con unos 39.000 profesionales encuestados, encontró que un aumento del 25% en la adopción de IA correlacionaba con una caída del 1,5% en el throughput de entrega y del 7,2% en la estabilidad. La explicación que ofrecen los propios autores no es que el código sea peor, sino que crece el tamaño de los lotes de cambio: se envía más de golpe, se revisa peor y se despliega con más riesgo.
El estudio de METR de julio de 2025 añadió una capa distinta. En un ensayo controlado con 16 desarrolladores experimentados sobre 246 tareas reales, los participantes tardaron un 19% más usando asistencia de IA, aunque esperaban ir un 24% más rápido y, tras la prueba, seguían creyendo que habían ido un 20% más rápido. Conviene decir que la propia METR revisó ese diseño en 2026 por posibles sesgos de selección y que una cohorte mayor mostró una diferencia mucho menor: el resultado exacto está en discusión.
Lo que no está en discusión es el hallazgo secundario, y es el importante para cualquier dirección: la percepción de velocidad y la velocidad real se separan. Un equipo puede sentir que va mucho más rápido mientras el sistema tarda más en llegar a producción.
El tamaño del cambio es la variable oculta detrás de la mayoría de los problemas de entrega. Un cambio pequeño se revisa bien, se prueba entero, se despliega rápido y, si falla, se identifica en minutos qué lo causó. Un cambio grande no permite nada de eso.
Variable | Cambio pequeño | Cambio grande |
|---|---|---|
Calidad de la revisión | Se entiende completo | «Parece razonable» |
Cobertura de pruebas | Verificable | Parcial en la práctica |
Tiempo de diagnóstico si falla | Minutos | Horas o días |
Coste de revertir | Bajo | Alto: arrastra otras cosas |
Riesgo por despliegue | Acotado | Acumulado |
Hasta hace poco, el esfuerzo de escribir el código actuaba como freno natural del tamaño del lote. Al desaparecer ese freno, el tamaño crece salvo que alguien decida limitarlo explícitamente. Esa decisión —limitar el tamaño de los cambios— es probablemente la intervención con mejor relación coste-beneficio disponible hoy en un equipo de desarrollo.
Medir líneas de código, tareas cerradas o «productividad por desarrollador» empeora activamente las cosas, porque premia exactamente el comportamiento que causa el problema. Las cuatro métricas de DORA siguen siendo el estándar razonable:
Frecuencia de despliegue. Cuántas veces se lleva algo a producción. Alta frecuencia implica lotes pequeños.
Tiempo de entrega del cambio. Desde que se escribe hasta que está en producción. Mide el proceso completo, no la escritura.
Tasa de fallos en cambios. Qué porcentaje de despliegues provoca una incidencia. Es el contrapeso de la velocidad.
Tiempo de restauración del servicio. Cuánto se tarda en recuperarse. Mide la capacidad real de operar.
Las dos primeras miden velocidad, las dos últimas estabilidad, y hay que mirarlas juntas. Un equipo que mejora las dos primeras y empeora las dos últimas no ha mejorado: ha trasladado el trabajo al futuro y al equipo de soporte.
Limitar el tamaño de los cambios. La medida más simple y la más eficaz. Obliga a partir el trabajo en unidades comprensibles y devuelve calidad a la revisión.
Invertir en pruebas antes que en velocidad. Cuando se genera más código, la red de seguridad importa más, no menos. Sin pruebas fiables, la aceleración es una apuesta repetida.
Automatizar el despliegue y la reversión. Si desplegar es caro, el equipo acumulará cambios hasta que merezca la pena, y volverá el lote grande.
Medir estabilidad con la misma visibilidad que velocidad. Si el panel del comité solo muestra entregas, el equipo optimizará entregas.
No premiar la velocidad aislada. El incentivo produce el comportamiento. Si se celebra lo que se envía y no lo que aguanta, se envía más y aguanta menos.
La expectativa instalada en muchos comités es que la asistencia de IA debería traducirse en entregar el doble en el mismo plazo. Esa expectativa es la que genera la presión que degrada la estabilidad.
La conversación honesta tiene dos partes. La primera: la generación de código sí se ha acelerado de forma real y medible. La segunda: la entrega es un proceso más amplio —comprender, revisar, probar, integrar, desplegar, operar— y solo se acelera si se trabaja en el conjunto.
Traducido a una frase que funciona en un consejo: hemos abaratado una parte del proceso, no el proceso. Aprovechar esa mejora exige invertir en el resto, no exigir el doble de lo mismo.
Es la misma conclusión a la que se llega desde el lado de la arquitectura, y por eso el debate ha vuelto al diseño en lugar de a la ejecución, como desarrollamos en el cuello de botella vuelve a ser la arquitectura
Acelera la generación de código, pero no necesariamente la entrega. El informe DORA de 2024 encontró que un aumento del 25% en adopción de IA correlacionaba con una caída del 1,5% en throughput y del 7,2% en estabilidad, atribuida al crecimiento del tamaño de los lotes de cambio.
Porque determina la calidad de la revisión, la cobertura real de las pruebas, el tiempo de diagnóstico cuando algo falla y el coste de revertir. El esfuerzo de escribir código actuaba como freno natural del tamaño; al desaparecer ese freno, hay que limitarlo explícitamente.
Las cuatro métricas DORA: frecuencia de despliegue, tiempo de entrega del cambio, tasa de fallos en cambios y tiempo de restauración del servicio. Las dos primeras miden velocidad y las dos últimas estabilidad; deben leerse juntas.
Un ensayo de METR de 2025 midió un 19% de retraso en desarrolladores experimentados que esperaban acelerar un 24%. La propia METR revisó después el diseño por posibles sesgos y una cohorte mayor mostró una diferencia menor. Lo consistente es que la percepción de velocidad y la velocidad real se separan.
Pruebas automatizadas fiables, despliegue y reversión automatizados, y un límite explícito al tamaño de los cambios. Cuando aumenta el volumen de cambio, la red de seguridad y la capacidad de revertir importan más, no menos.
Porque premian el comportamiento que causa el problema: producir más volumen sin garantizar que llegue a producción de forma estable. El incentivo determina la conducta, y medir salida en lugar de resultado desplaza el coste al soporte y al futuro.
¿Tu equipo entrega más rápido o solo produce más? Analizamos el proceso completo de entrega —revisión, pruebas, despliegue y operación— y te decimos dónde está el freno real. Hablemos →
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
