Agente de IA: dónde está realmente tu cuello de botella

Agente de codificación IA: dónde está realmente tu cuello de botella

Nuestra cola de soporte resolvía tickets en nueve minutos, luego pasaban cuatro horas esperando a que un agente los tocara. La misma historia sucede ahora en equipos de ingeniería con un agente de codificación IA: el código se escribe en minutos, luego queda en cola. Si acabas de desplegar un agente de codificación IA y el throughput de tu equipo apenas se movió, no encontraste una herramienta defectuosa. Encontraste tu verdadera restricción, y no es donde creías que estaba.

Así es como tiene sentido leer lo que está pasando en las organizaciones de ingeniería en 2026. Un agente de codificación IA (software que planifica, escribe y a menudo prueba cambios de código con mínimo input humano, a diferencia de un asistente de autocompletado) elimina fricción en la etapa de escritura. Pero la escritura raramente fue el poste limitante (el paso que dicta el throughput de toda la línea) en un pipeline de software. Revisión, CI y despliegue casi siempre lo fueron. Acelera lo que no es una restricción y no obtienes más trabajo terminado. Obtienes una cola más grande frente a lo que viene después.

¿Dónde fue el cuello de botella después de agregar un agente de codificación IA?

Dos conjuntos de datos industriales de 2026 apuntan en la misma dirección. En el reporte State of Software Delivery de CircleCI, el throughput de ramas de feature en el equipo promedio subió un 15% interanual, pero el throughput de la rama main (cambios realmente llegando a producción) bajó un 7% en el mismo período (CircleCI, 2026 State of Software Delivery). Más trabajo entrando por la parte delantera, menos saliendo por la trasera.

Por separado, en investigaciones de desarrolladores de GitLab cubiertas por InfoQ, el 85% de los encuestados acordó que la IA ha desplazado el cuello de botella de escribir código a revisarlo y validarlo, y el 79% dijo que el proceso general de entrega no ha mantenido el ritmo con la velocidad de codificación (InfoQ, AI coding outpaces governance). Eso no es una brecha de herramientas. Es una restricción que se movió y nadie volvió a medir la línea.

La Ley de Little no le importa que el código se escriba más rápido

La Ley de Little te explica por qué sucede esto, y no es específica del software. Es la misma matemática detrás de la cola de picking en un centro de distribución o del proceso de alta en un hospital:

WIP = Throughput × Cycle Time

WIP es work-in-process, todo lo que está en tu pipeline en este momento (PRs abiertos, tickets en revisión, órdenes recogidas pero no empaquetadas). Throughput es unidades completadas por unidad de tiempo. Cycle Time es cuánto tarda una unidad de inicio a fin.

Acelera la generación de código sin tocar la capacidad de revisión, y estás empujando más unidades por hora a una etapa cuyo throughput no cambió. El WIP tiene que ir a algún lado. Se acumula como un backlog de PRs abiertos, una cola de merge creciente, o revisores leyendo diffs más rápido y perdiendo más. Ninguno de esos es gratis. Un pull request sentado tres días extra no cuesta nada, cuesta contexto: el autor se movió adelante, el revisor tiene que recargar todo el cambio, y el rework se vuelve más caro cuanto más espera.

El paso de codificación no es el único lugar donde aparece "agente IA" ahora

Vale la pena separar dos cosas que se agrupan bajo "agente de codificación IA". Algunas herramientas están construidas para escribir y modificar código fuente dentro de un repo. Otras son agentes de propósito general que incluyen un modo de escritura de código junto con investigación, navegación y generación de documentos.

Genspark es del segundo tipo: un "Super Agent" sin código que puede navegar por la web, generar diapositivas o documentos y escribir y ejecutar código desde un único prompt. Esa amplitud es útil para un generalista, pero es una herramienta diferente para un trabajo diferente que algo construido específicamente para vivir dentro de tu pipeline de CI y abrir pull requests contra tu codebase real. Empareja el diseño de la herramienta con la etapa del pipeline que intentas desbloquear, no al revés.

Manus va aún más lejos, operando dentro de una computadora virtual completa (navegador, terminal, sistema de archivos) para planificar y ejecutar tareas de múltiples pasos de principio a fin y entregar un resultado terminado. Para un equipo de ops, ese es un modelo mental útil incluso fuera del código: un agente que termina una unidad completa de trabajo, no solo el sub-paso más rápido, es el que realmente mueve el throughput.

PCE: el único número que te dice si el agente está ayudando

Process Cycle Efficiency (PCE) es la relación entre tiempo con valor agregado y tiempo de ciclo total, y es la forma más honesta de verificar si un agente de codificación IA mejoró tu pipeline o solo movió el cuello de botella:

PCE = Valor Agregado / Tiempo de Ciclo Total

Antes de adoptar un agente de codificación IA, mide la división actual: cuánto del ciclo de vida típico de un cambio, desde el primer commit hasta fusionarse en producción, se gasta realmente escribiendo o revisando código, versus esperando en cola. La mayoría de equipos nunca han sacado este número y se sorprenden. PCE por debajo del 25% es común en pipelines de software, lo que significa que tres cuartas partes de la vida total de un cambio están esperando, no siendo trabajadas.

Ejecuta la misma medición 30 a 60 días después del despliegue. Si PCE subió, el agente liberó capacidad real y tu equipo la está usando. Si PCE se mantuvo igual o bajó, el agente aceleró un paso que ya era rápido y la salida extra está en cola, invisible hasta que alguien cuente PRs abiertas un viernes. Este es exactamente el tipo de lectura donde una capa de análisis IA se gana su lugar: no es suficiente saber que PCE se movió, necesitas el veredicto sobre cuál etapa absorbió la diferencia, y eso se lee más rápido desde un desglose automatizado que desde eyeballing un tablero Kanban.

Tres señales de que revisión, no el agente, es tu paso limitante

Algunos patrones aparecen consistentemente una vez que los equipos comienzan a medir en lugar de asumir:

• El número de PR abiertos tiende al alza mientras el número de fusiones se mantiene plano. Más unidades entrando por la línea, la misma cantidad saliendo. Acumulación clásica de WIP frente a una restricción sin cambios.

• El tamaño promedio de PR crece. Un agente de codificación IA que genera una feature completa en un pase produce diffs más grandes que un humano escribiendo incrementalmente. Diffs más grandes tardan más en revisar por PR, lo que reduce el throughput del revisor incluso si headcount y velocidad de revisión por línea permanecen constantes.

• El tiempo hasta la primera revisión sube más rápido que el tiempo para fusionar después de la aprobación. Si la espera es principalmente antes de que alguien comience a mirar, ese es un problema de queueing (capacidad de revisión insuficiente, o revisiones no son priorizadas), no un problema de calidad de revisión.

Ninguno de estos requiere herramientas exóticas para rastrear. Un pull semanal desde la API de tu host de git, trazado contra la semana que implementaste el agente, es suficiente para ver la forma del cambio.

Lo que una cola de soporte hace bien que los pipelines de ingeniería usualmente pierden

Operaciones de soporte y fulfillment han estado lidiando con este exacto problema más tiempo que los agentes de codificación IA han existido, y la solución se generaliza limpiamente. Una cola que resuelve tickets de primer contacto en nueve minutos pero toma cuatro horas llegar a un nivel especialista no es una historia de recursos sobre los especialistas siendo lentos. Es una señal de que el nivel rápido está sobre-recursos en relación con lo que viene después, y que atraer más tickets hacia la parte delantera no ayuda hasta que la capacidad de la parte trasera cambie.

Los equipos de ingeniería saltan este paso constantemente porque la revisión de código no se parece a una cola en un dashboard de la manera que lo hace un recuento de tickets. Son PRs sentadas tranquilamente en un estado "esperando revisión", fácil de no notar hasta que alguien pregunta por qué una feature de dos semanas aún no ha salido. Theory of Constraints (la idea de que la salida general de un sistema es limitada por su único paso limitante, no por la suma de velocidad de cada paso) dice que la solución nunca es "haz la parte rápida más rápida". Es encontrar el paso limitante actual, proteger su capacidad, y solo entonces decidir si la parte rápida necesita más velocidad en absoluto.

Hay una segunda restricción, más callada, que aparece unos meses después de que un agente de codificación IA envía más código, más rápido: drift de documentación. Nadie se da cuenta hasta que el onboarding de un nuevo ingeniero toma el doble porque los docs describen un sistema que cambió hace tres sprints. Una plataforma docs-as-code como GitBook, que se sincroniza con el mismo repo donde el agente está haciendo commits, al menos mantiene el registro de la pista de no caerse más atrás que el código mismo. No arregla el cuello de botella de revisión, pero evita que uno segundo se forme en la oscuridad.

¿Deberías ralentizar tu agente de codificación IA a propósito?

A veces, sí, y ese no es algo popular de decir sobre una herramienta que todos están entusiasmados. Si tu capacidad de revisión es fija durante los próximos dos trimestres (headcount congelado, revisores ya a capacidad), dejar que un agente triplique la tasa de PRs entrantes no crea más features terminadas, desplegadas. Crea una cola más larga y, per los datos de CircleCI arriba, una tasa de éxito de main-branch más baja, porque revisores bajo presión de volumen pierden más.

El movimiento honesto en esa situación es limitar cuánto genera un agente por ciclo, o meter su salida detrás de un pase de pre-revisión (linting, pruebas de cobertura automática, política de diff más pequeño) antes de que llegue a un revisor humano. Eso no es una posición anti-IA. Es la misma lógica que no programar más unidades en una línea que tu estación más lenta puede absorber.

Si la restricción actual resulta ser atención del revisor en lugar de headcount del revisor, agentes de workflow construidos para triage y routing, como Lindy AI manejando inbox y sobrecarga de notificaciones alrededor del día de un equipo, pueden liberar horas de revisión real sin tocar tu codebase directamente. Vale la pena probar antes de asumir que la solución debe ser "contratar más revisores" o "comprar más asientos de agente".

Dónde invertir realmente después

Ejecuta el cálculo de PCE antes de expandir el uso de agentes más, no después. Si el tiempo con valor agregado como porcentaje del tiempo de ciclo total no se ha movido desde el despliegue, no compres más asientos de agente todavía. Pon la siguiente línea de presupuesto en capacidad de revisión, throughput de CI, o automatización de merge-queue en su lugar, cualquiera que los datos señalen, y re-ejecuta el número en 30 días.

Si PCE mejoró y la revisión está al ritmo, esa es la señal para expandir el alcance del agente, no antes. Mide primero. Los equipos que obtienen ganancias reales de throughput de un agente de codificación IA no son los que lo adoptaron más rápido. Son los que encontraron su paso limitante actual y arreglaron la capacidad allí antes de dejar que la parte rápida corra más rápido.