La IA ya escribe una parte enorme del código. En muchos equipos, cerca de la mitad de los commits. Y aun así, el tiempo que tarda una funcionalidad en llegar a producción casi no se movió.

Eso debería ser raro. Si la parte más visible del trabajo se volvió diez veces más rápida, ¿por qué el reloj total sigue igual?

La tesis de este post en una línea: resolvimos la escritura de código, pero la cadena que viene después no creció con ella. La IA amplifica el sistema por el que corre. Si tu cadena de entrega está desordenada, lo único que logras es enviar el desorden más rápido. El cuello de botella no desapareció. Se corrió aguas abajo, y la mayoría de los equipos sigue optimizando el paso que ya dejó de ser el límite.

El código se volvió barato. La entrega no.

Priyanka Vergadia lo planteó esta semana con una claridad que vale repetir: la IA escribe casi la mitad de los commits en la mayoría de los equipos, y el tiempo a producción no cambió ni un poco. El ahorro al escribir se evapora aguas abajo, en esperas, reprocesos y coordinación.

Los datos acompañan la observación. Según un reporte que recoge TechRadar, el 69% de los usuarios intensivos de herramientas de IA reporta problemas frecuentes de despliegue con el código generado, casi la mitad dice que el trabajo manual de aseguramiento de calidad, remediación y validación aumentó, y solo el 21% de los equipos logra armar sus flujos de compilación y despliegue con rapidez. El código entra más rápido. Todo lo que viene después se atascó.

Llevo décadas enviando software, y si algo he visto en cada salto de productividad es que el límite no se elimina, se muda. Acelerar una parte de la cadena no acelera el todo: solo deja al descubierto el eslabón que no tocaste. Esta vez ese eslabón es la entrega.

Una prueba inestable ya no falla una vez por semana, falla a diario

El mecanismo es concreto, y cualquiera que tenga un CI lo reconoce. Más commits hacen correr la suite completa de pruebas con mucha más frecuencia. Una prueba inestable, de esas que a veces pasan y a veces fallan sin que nadie haya tocado nada, deja de ser una molestia semanal y empieza a fallar todos los días. Y una sola prueba mala alcanza para bloquear todas las fusiones que esperan en fila detrás.

A eso se suma el costo invisible: cada reejecución del flujo por una falla que no era real quema tiempo de cómputo y, peor, quema la paciencia del equipo. La revisión de PR se vuelve el nuevo embudo, porque ahora hay que revisar el doble de cambios y cada uno trae código que el revisor no puede aprobar de un vistazo.

Ninguno de estos problemas es nuevo. Lo nuevo es el volumen. Una grieta en la entrega que aguantaba bien con cincuenta commits al día se convierte en una represa con doscientos. La IA no creó el problema. Lo amplificó hasta que dejó de poder ignorarse.

La IA amplifica el sistema, incluido el malo

Hay una estadística que resume todo el asunto. El 93% de los desarrolladores usa IA, pero la ganancia de productividad medida ronda apenas el 10%. La brecha entre esos dos números es exactamente el desorden de la cadena de entrega.

Porque la IA no es un acelerador selectivo que solo mejora lo bueno. Es un amplificador. Le sube el volumen a todo el sistema por el que pasa. Si tu proceso de pruebas es sólido, lo hace volar. Si es frágil, multiplica las fallas. Si tu revisión ya estaba saturada, la ahoga. Acelerar la entrada de un sistema desordenado no te da un sistema rápido. Te da un sistema que produce desorden más rápido.

Ya escribí antes que el cuello de botella se movió y que construir se volvió barato mientras decidir qué construir no. Este post es una cara distinta del mismo cambio, una más concreta y más fácil de ignorar: no se trata solo de decidir qué construir, sino de qué pasa con todo lo construido cuando entra a la cadena de entrega a diez veces la velocidad de antes. Decidir bien y aun así atascarte en un CI frágil es perfectamente posible. Lo veo todo el tiempo.

Lo que hacemos en IQ Source con esto

Cuando una empresa nos pide acelerar su desarrollo con IA, no miramos solo el paso de escribir código. Miramos la cadena completa: escribir, probar, revisar, entregar. Porque multiplicar la entrada de una cadena sin saber dónde está su eslabón más débil es la forma más cara de descubrir ese eslabón.

AI Maestro es el discovery donde se mapea esa cadena de valor entera antes de tocar el acelerador. Identificamos dónde se va a romper la entrega cuando el volumen de commits se dispare: las pruebas inestables que hoy aguantan, la suite que ya tarda demasiado, la revisión que depende de dos personas. Y reforzamos ese eslabón antes de subir la velocidad, no después del primer atasco en producción. Es el mismo principio que ya escribí cuando una falla parecía del agente y era de la arquitectura: el problema casi nunca está donde más se mira.

La próxima vez que alguien celebre que la IA ya escribe la mitad del código del equipo, haz una sola pregunta antes de festejar: ¿esa mitad llega a producción más rápido, o solo se acumula en una cola de revisión y pruebas que nadie agrandó? Si es lo segundo, no aceleraste la entrega. Solo le pusiste más presión a la misma puerta angosta.

Encuentra el eslabón débil de tu entrega antes de acelerar