Por qué AI-DLC te hace más lento primero

El agente quita el cuello de botella que podías ver. El que no veías siempre fue el review, y ahora es el único que queda.

Todos los squads piloto del rollout que seguí dibujaron la misma curva. La cantidad de cambios mergeados por dev subió desde la primera semana. El tiempo entre el primer commit y el despliegue también subió, que es la dirección equivocada, y se quedó ahí un tiempo antes de bajar.

Eso es una curva en J: las cosas empeoran antes de mejorar. La gente de gestión del cambio dibuja esa curva hace décadas, para todo cambio de proceso serio. Lo que hace que la versión de AI-DLC merezca un artículo es que las dos curvas se separan. Una métrica se ve muy bien desde el primer día. La otra se ve pésima. Si miras solo la primera, declaras la victoria demasiado pronto. Si miras solo la segunda, matas el piloto justo en el fondo de la caída, que es el momento más caro para abandonar.

Este artículo trata de qué causa la caída, por qué cae sobre el code review, y cómo distinguir un equipo que está aprendiendo de un equipo que está trabado.

Dos métricas, dos curvas

Empieza por las definiciones, porque todo el argumento depende de ellas.

Throughput es cuánto se mergea: merge requests por dev por mes, por ejemplo. Mide salida. Cycle time es cuánto tarda un cambio desde el primer commit hasta el inicio del despliegue. Mide flujo, qué tan rápido se mueve una pieza de trabajo por el sistema.

En un equipo normal, las dos se mueven juntas. Escribes más código, entregas más código. En un rollout de AI-DLC se separan, porque el método vuelve casi gratis una parte del trabajo y deja la otra exactamente igual de cara que antes.

La forma de una adopción de AI-DLC

1. Primeras semanasEl throughput se dispara, el cycle time sube

   El agente genera código al instante, así que se abren y se mergean más cambios. El proceso nuevo es lento: sesiones largas de Mob Elaboration, agentes adivinando en repositorios que nadie preparó para ellos, Inceptions reiniciadas desde cero.

2. La caídaSe forma una fila delante del review

   Llegan más merge requests, y más grandes, a las mismas personas que ya revisaban antes. Los cambios esperan. El cycle time llega a su peor punto mientras el throughput todavía parece un éxito.

3. RecuperaciónUnits más chicas, gates con fluidez, repositorios preparados

   El equipo limita el tamaño de cada Unit, el repo gana un mapa legible para el agente, la gente aprende qué preguntas responder en el mob. El cycle time empieza a bajar y sigue bajando.

4. DespuésLas dos curvas apuntan hacia el lado correcto

   La salida sigue alta y cada cambio se mueve más rápido que antes del método. Es el estado al que se suponía que llegaba el piloto.

Por qué cae la curva

Tres cosas vuelven más lento a un equipo al principio, y ninguna es que el agente sea lento.

Qué vuelve más lento primero a un equipo de AI-DLC

Las dos primeras se desvanecen con la práctica. La tercera es estructural, y es la que mata pilotos.

Causa	Cómo se ve	Cuándo se va
Choque de proceso	Un Mob Elaboration sincrónico reemplaza el refinamiento asincrónico. Todos en una sesión durante horas, más discusión que antes.	Cuando el equipo aprende qué preguntas necesitan a todos y cuáles no.
Repositorios sin preparar	El agente hace preguntas triviales, adivina patrones equivocados, y el equipo reinicia la Inception.	Cuando el repo tiene un mapa corto, legible para el agente, del stack y los patrones.
La fila de review	Llega más código, en merge requests más grandes, a los mismos revisores.	Solo cuando alguien cambia el tamaño del trabajo. No se arregla sola.

Las dos primeras son una curva de aprendizaje en sentido literal. Las personas y los repositorios mejoran en el método, y el costo baja. Puedes esperar a que pasen.

La tercera no puedes esperar a que pase. Es la razón por la que la curva tiene esa forma.

El review es el nuevo cuello de botella

El mecanismo, en palabras de un ingeniero que lo vivió en uno de los pilotos. Al principio el cycle time subió por la adopción en sí. Después el throughput se disparó, pero el cycle time no bajaba, porque el equipo había caído en una trampa simple: el agente escribe código muy rápido, la gente abre muchos merge requests, y todo se traba en el review.

Empeoró cuando el equipo paralelizó. Varios ingenieros corrían sus propias Units al mismo tiempo, cada uno produciendo merge requests grandes, y el repositorio se volvió un caos. Una o dos Units que debían ser chicas terminaron siendo merge requests que nadie podía revisar de una sentada.

Piensa en una autopista que gana dos carriles extra justo hasta una caseta de peaje que sigue con una sola cabina abierta. Llegan más autos, más rápido. La fila en el peaje se alarga. El viaje toma más tiempo, no menos.

Eso es lo que pasa cuando generar se vuelve barato y revisar no. El agente no hizo a tu equipo más rápido en el paso más lento. Hizo más rápido cada paso antes del más lento, lo que solo alarga la fila delante de él. Escribí sobre el mismo cambio para equipos que usan Spec-Driven Development: cuando todos tienen un agente, producir código deja de ser lo escaso e integrarlo se vuelve el trabajo.

Limita el tamaño de la Unit, no la velocidad del agente

No arreglas un cuello de botella de review revisando más rápido. Los revisores apurados son la forma en que el código malo llega a producción. Lo arreglas cambiando lo que llega al review.

AI-DLC te da la palanca en el momento justo. Antes de que empiece la Construction, el agente propone cómo dividir el trabajo en Units, y tú apruebas ese plan. Ese es el punto para imponer un límite de tamaño, no después de que los merge requests están abiertos. Los equipos que se recuperaron hicieron dos cosas: le pidieron al agente que estimara el tamaño de cada Unit antes de aprobar el plan, y acordaron como equipo el merge request más grande que una persona puede revisar con cuidado de una sentada.

Cómo mantener las Units revisables

1. 01

   Pide el tamaño antes de aprobar el plan.

   El plan es el lugar más barato para dividir el trabajo. Cuando el código ya existe, dividirlo es rehacerlo.

   Escribe esto

   Before I approve these Units, estimate the files and lines each one will change, and flag any Unit that touches more than one layer.

2. 02

   Divide lo que pase el límite del equipo.

   Un merge request con cientos de cambios se lee por encima, no se revisa. Hasta una tarea que suena chica puede tocar migration, entidad, API y pruebas a la vez.

   Escribe esto

   Unit 3 is too big to review in one sitting. Split it by endpoint, and put the database migration in its own Unit.

3. 03

   Convierte el límite en una regla, no en un recuerdo.

   Un límite que vive en la cabeza de un revisor se olvida en la próxima sesión. En AI-DLC 2 una regla de proyecto se carga al inicio de cada workflow.

   Escribe esto

   Add to the project rules: no Unit may produce a merge request a reviewer cannot read carefully in one sitting. Estimate size before proposing Units.

El límite exacto es una decisión del equipo. Lo que importa es que exista, que se aplique en el plan y que el agente lo conozca antes de proponer nada.

La evidencia pública dice lo mismo

Nada de esto es exclusivo de la organización que seguí. La investigación pública apunta en la misma dirección, desde distintos ángulos.

El ensayo aleatorizado de METR es el más filoso. Desarrolladores experimentados de open source, trabajando en código que conocían bien, tardaron cerca de un 19% más con herramientas de IA, mientras creían que habían sido cerca de un 20% más rápidos. La lección para un rollout de AI-DLC no es que la IA vuelve lenta a la gente. Es que sentirse más rápido y ser más rápido son mediciones distintas, y la sensación es lo que todos reportan en la retro. Mide el cycle time. No le preguntes a la gente cómo se siente.

La investigación de DORA defiende lo mismo hace años desde el otro lado: lead time, frecuencia de despliegue, tasa de fallas en cambios y tiempo de recuperación son lo que predice el desempeño de entrega. El volumen de salida no está en esa lista. El análisis de AIDLC de Augment Code resume el estado actual sin vueltas: la adopción de IA entre desarrolladores es casi universal, y las métricas de entrega apenas se movieron, porque las herramientas atadas a un ingeniero optimizan teclas y nada coordina el resto.

El estudio de Microsoft sobre su propio rollout de Claude Code y Copilot CLI, a principios de 2026, a decenas de miles de ingenieros (arXiv 2607.01418), encontró que quienes lo adoptaron mergearon cerca de un 24% más de pull requests de lo que habrían mergeado sin él. Los autores tienen cuidado de decir lo que eso no significa: un pull request mergeado no es lo mismo que el valor que entrega. Es la curva de throughput, bien medida y etiquetada con honestidad. Todavía no te dice nada sobre la fila.

¿Curva de aprendizaje o problema real?

La caída es esperable. Eso no significa que toda caída sea la curva en J. A veces el método de verdad no encaja con el trabajo, y esperar más solo agranda la cuenta.

Fija un punto de decisión en unas cuatro semanas, y dilo en voz alta antes de que empiece el piloto. Si el cycle time no empezó a girar para entonces, deja de preguntar “¿es la curva?” y empieza a preguntar “¿qué está estructuralmente mal?”

Sigue siendo la curva en J

1. 01El cycle time está alto, pero ya empezó a girar
2. 02Las sesiones de mob se acortan cada semana
3. 03El agente hace menos preguntas triviales sobre el repo
4. 04Los merge requests se achican desde la regla de tamaño
5. 05Los revisores van atrasados, pero la fila se achica

Un problema estructural

1. 01El cycle time está plano o sigue subiendo después de un mes
2. 02El trabajo es casi todo correcciones de una línea, para las que el método nunca se pensó
3. 03El repo todavía no tiene un mapa de sí mismo legible para el agente
4. 04Nadie en el mob conoce el dominio lo suficiente para juzgar los artefactos
5. 05Los gates se aprueban sin preguntas, y el retrabajo aparece en el review

Cada problema estructural tiene un arreglo, y la mayoría está en otras partes de esta serie. Un repositorio sin preparar es un problema de brownfield. Los gates sellados sin leer son un problema de diseño de gates. Usar un ciclo de 33 etapas en un cambio de una línea es un problema de perfil: AI-DLC 2 trae un perfil Bugfix de 9 etapas por algo, y a veces el perfil correcto es ninguno.

El trabajo del manager durante la caída

La curva en J es un problema de gestión antes que un problema técnico, porque quien decide si el piloto sobrevive suele ser quien está mirando el peor número.

La recomendación que salió del rollout fue aburrida y específica. Antes de que empiece el piloto, el manager le avisa al equipo que las primeras semanas van a ser más lentas y que eso es esperable, no un fracaso. Después el manager participa en los dos o tres primeros mobs, no como observador, sino como la persona con autoridad para decir “cortamos aquí y seguimos mañana”. Un tech lead tiene autoridad técnica para cuestionar un artefacto. El manager tiene autoridad organizacional para frenar toda la sesión sin que nadie lo lea como un fracaso individual.

Lee el throughput solo junto al cycle time

La regla práctica que sale de todo esto cabe en una frase: nunca mires el throughput solo.

Pon tres números en la misma pantalla. Throughput, para saber que la salida sube. Cycle time, para saber si un cambio se mueve más rápido o solo espera más. Y retrabajo, la proporción de artefactos y merge requests devueltos con cambios pedidos, para saber si la velocidad es real o prestada del próximo sprint. La guía de métricas repasa qué reemplaza a los story points y la velocity cuando AI-DLC está en marcha.

Preguntas frecuentes

¿La curva en J es normal al adoptar agentes de IA para código?+

Sí. Todo cambio de proceso serio produce una caída inicial antes de las ganancias, y AI-DLC es un cambio de proceso, no la instalación de una herramienta.

Lo específico de AI-DLC es que la caída aparece en el cycle time mientras el throughput sube desde el primer día. Generar se vuelve barato al instante. Revisar y validar no.

¿Cuánto dura la curva en J de AI-DLC?+

Lo suficiente para asustar a un manager y lo bastante corta para que valga la pena, si las causas son del tipo aprendizaje. Fija un punto de decisión en unas cuatro semanas: si el cycle time no empezó a girar para entonces, busca una causa estructural en lugar de esperar más.

¿Por qué empeora el cycle time con agentes de IA?+

Porque el agente produce más cambios, y más grandes, de los que la capacidad de review del equipo puede absorber. Los cambios esperan en una fila delante de los mismos revisores humanos, así que cada uno tarda más desde el primer commit hasta el despliegue, aunque el código se haya escrito más rápido.

¿Un modelo más rápido o más inteligente arregla la caída?+

No. Un modelo más rápido escribe código más rápido, lo que alarga la fila de review. El arreglo está del lado humano: Units más chicas, un límite de tamaño aplicado en el plan, repositorios preparados y un ritmo que mantenga a los gates con sentido.

¿Deberíamos detener el piloto si el cycle time empeora?+

No en las primeras semanas. Espéralo, y avísale al equipo que lo espere. Fija un punto de decisión alrededor de las cuatro semanas, y úsalo para separar una curva de aprendizaje de un problema estructural, como repositorios sin preparar, trabajo demasiado chico para el método o gates que nadie puede juzgar.

¿Qué medir en lugar de solo throughput?+

Throughput junto al cycle time, más retrabajo: con qué frecuencia los artefactos y los merge requests vuelven con cambios pedidos. El throughput solo muestra una fila que crece y la llama éxito.

A dónde ir ahora

La curva en J es lo más predecible de un rollout de AI-DLC, y la razón más común por la que los pilotos mueren temprano. Espérala, explícala antes de empezar, limita el tamaño del trabajo en el plan y pon el cycle time junto a cada gráfico de throughput que muestres. Después decide con datos en la cuarta semana, y no con nervios en la segunda.