Faros AI: los agentes de IA elevaron un 98% los pull request, pero la revisión tarda un 91% más

Los equipos con agentes de IA escriben código más rápido, pero este no llega a main más deprisa y, en algunos casos, tarda incluso más. Habr ha analizado esta paradoja con datos de Faros AI, CircleCI y DORA. La cifra más citada del informe de Faros AI, basado en telemetría de más de 10 mil desarrolladores, es la siguiente: quienes usan IA de forma activa cierran un 21% más de tareas y fusionan un 98% más de pull request. Al mismo tiempo, el tiempo de revisión aumenta un 91%.

La lógica es sencilla. Generar código se ha abaratado casi hasta cero, pero la verificación sigue siendo trabajo humano. Si a la entrada del pipeline llega el doble de material y a la salida sigue el mismo revisor, la cola crece.

Dónde se atasca el código

El problema no es la cantidad de PR, sino su tamaño. Según Faros AI, el pull request medio en los equipos con un alto nivel de adopción de IA ha crecido aproximadamente un 154%. El agente hace de buena gana grandes refactorizaciones, añade tests y toca módulos vecinos. El revisor tiene que mantener más contexto en la cabeza, y revisar con atención un diff de 800 líneas no lleva el mismo tiempo que uno de 300.

El segundo punto de pérdida está en el QA. Faros AI registró un aumento de alrededor del 9% en el número de bugs por desarrollador. Cada defecto adicional devuelve la tarea al ciclo: comentarios, correcciones, nueva ejecución de CI y nueva revisión. La métrica de «tareas cerradas» sube, mientras que el lead time hasta producción se queda igual o aumenta.

Los datos de DORA muestran el mismo cuadro desde otro ángulo. En el informe de 2024, un aumento del 25% en la adopción de IA se correlacionaba con una reducción del 1,5% en el rendimiento de la entrega y una caída del 7,2% en la estabilidad. Más tarde, DORA describió la IA como un amplificador: acelera los buenos procesos y deja al descubierto los débiles. CircleCI aborda el problema desde los pipelines de CI. Ahí se ve dónde se acumulan las compilaciones fallidas y las ejecuciones largas, es decir, dónde la velocidad de escritura choca con la velocidad de verificación.

Métricas que conviene vigilar

Para encontrar el cuello de botella no basta con las estadísticas de commits. Hace falta una visión de extremo a extremo, desde el primer commit hasta el despliegue:

• Tiempo hasta la primera revisión: cuánto espera un PR hasta que alguien lo mira.
• Tiempo total de revisión: desde la apertura hasta el approve.
• Tamaño del PR en líneas y archivos, junto con la mediana y el percentil 90.
• Proporción de PR que vuelven a corrección tras la revisión o el QA.
• Change failure rate y tiempo de recuperación tras un incidente.
• Lead time for changes: del commit a producción.

Si los dos primeros indicadores crecen al ritmo del número de PR, el problema está en la revisión. Si aumentan la proporción de devoluciones y el change failure rate, el límite lo marca la calidad del propio código generado y de sus tests.

Qué pueden hacer los equipos

Primero: limitar el tamaño de los cambios. Muchos equipos fijan un límite estricto por PR y piden a los agentes que dividan el trabajo en piezas pequeñas y atómicas. Es más barato que contratar a dos revisores más.

Segundo: incorporar la IA también en la verificación. La primera revisión automática, los linters, el análisis estático y la generación de tests quitan al humano la parte rutinaria y le dejan las cuestiones de arquitectura. Pero la calidad de esa revisión también hay que medirla; de lo contrario, el cuello de botella simplemente se mudará a otro sitio.

Tercero: revisar las métricas de productividad. En la era de los agentes, el número de PR y de tareas cerradas por persona dice casi nada. Son más reveladores el lead time y la estabilidad de las versiones, es decir, las métricas que DORA utiliza desde hace años.

Cuarto: reforzar las comprobaciones automáticas previas a la revisión. Cuanto más fiable sea el CI y mayor la cobertura de tests, menos trabajo queda para las personas. Una prueba práctica para cualquier tech lead: tome los últimos 100 PR fusionados y compruebe cuánto tiempo pasó cada uno esperando revisión, y no en desarrollo. Lo más probable es que ahí esté la ganancia que le prometieron los agentes.