Cuello de botella de CI en la era de la IA: lo que cambió Linear

Tu agente escribe un PR en 4 minutos y el CI tarda 25 en decir si sirve. Esa cuenta no cierra. Linear publicó un texto contando justo eso: después de que la IA entró en el flujo de código del equipo, apareció el cuello de botella de CI, y tuvieron que rehacer el pipeline para seguirle el ritmo.

El texto merece una lectura completa por los detalles. Aquí quiero hablar de lo que esto significa para quien no es Linear: tú, yo y el equipo de cinco personas con un monorepo que creció sin pedir permiso.

Lo que pasó en Linear

La tesis es simple. Durante años, escribir código era el paso más lento del ciclo. El CI corría mientras ibas por un café, y nadie se quejaba mucho.

Luego llegaron los agentes de código. El volumen de PRs subió. Los PRs se volvieron más pequeños y más frecuentes. Hay devs abriendo tres o cuatro branches en paralelo, cada una con un agente trabajando. Y cada push dispara el pipeline completo.

El resultado es previsible: la cola de CI se convirtió en el lugar donde el trabajo espera. Linear miró esto y trató el CI como producto, no como fontanería. Cambió cómo se eligen los tests, cómo se paraleliza el trabajo y cuánto se reaprovecha entre ejecuciones.

Por qué la IA convirtió el CI en un cuello de botella

Piensa en el ciclo como una cinta con tres etapas: escribir, validar, revisar. Si una etapa se vuelve diez veces más rápida, la más lenta pasa a marcar el ritmo. Es la ley de Amdahl aplicada a tu día.

Antes de la IA, un dev abría quizá dos o tres PRs por día. Hoy, con un agente, ese número puede triplicarse sin esfuerzo. Si cada ejecución cuesta 20 minutos de runner, no tienes solo más espera. Tienes más costo, más cola y más cambio de contexto.

Y hay un detalle que poca gente comenta: el agente depende del CI más que tú. Tú sabes que solo cambiaste un CSS. El agente no tiene ese instinto, o al menos no deberías confiar en él. Necesita la señal verde o roja para saber si terminó. Un CI lento también vuelve lento al agente.

Cuando escribir código sale barato, verificar código se vuelve el trabajo caro.

Qué cambia en el pipeline en la práctica

No puedes copiar la infraestructura de Linear, pero los principios sirven para cualquier proyecto. Estos son los que yo aplicaría primero, en orden de esfuerzo.

Cancelar ejecuciones que nadie va a leer

Si hiciste push tres veces en dos minutos, solo importa el último resultado. En GitHub Actions esto es una línea de configuración, y muchos proyectos todavía no la tienen:

concurrency:
  group: ci-${{ github.ref }}
  cancel-in-progress: true

Con un agente haciendo push en cada ajuste, esto solo ya recorta una buena parte de la cola.

Ejecutar solo lo afectado

En un monorepo, correr todos los tests de todas las apps en cada PR es quemar dinero. Turborepo y Nx ya saben calcular qué cambió a partir del grafo de dependencias:

bunx turbo run test lint type-check --filter='...[origin/main]'

¿Solo cambió la app de marketing? No hay por qué testear la API de pagos. Aquí suele estar la mayor ganancia de todas, y el costo es tener el grafo de dependencias bien declarado. Si no lo está, este es el momento de arreglarlo.

Paralelizar con shards

Una suite grande que no se puede recortar sí se puede dividir. Vitest y Playwright aceptan shards de forma nativa:

strategy:
  matrix:
    shard: [1, 2, 3, 4]
steps:
  - run: bunx vitest run --shard=${{ matrix.shard }}/4

Cuatro runners de 5 minutos responden mucho antes que un runner de 20. El costo total en minutos queda parecido, pero el tiempo hasta el feedback baja mucho. Y es el tiempo hasta el feedback lo que frena al equipo.

Caché de verdad

Caché de dependencias tiene todo el mundo. Lo que marca la diferencia es el caché de resultados de tareas: si el paquete @repo/utils no cambió, el resultado de su test de ayer sigue siendo válido. El remote cache de Turborepo o de Nx resuelve esto entre máquinas, incluso entre tu laptop y el runner.

¿Y la calidad no baja?

Esta es la objeción que más escucho. "Si corres menos tests, se te va a escapar un bug."

Depende de dónde pongas la vara. Lo que funciona es separar dos momentos:

• En el PR: feedback rápido, solo lo afectado, fallar pronto. El objetivo es responder en pocos minutos.
• Antes del merge o en main: suite completa, tests lentos, E2E pesado. Una merge queue resuelve bien esto, porque valida el resultado combinado y no cada branch por separado.

Así no cambias seguridad por velocidad. Solo cambias cuándo pagas cada costo. El PR queda rápido para que el humano y el agente iteren, y main sigue protegida.

Otro punto honesto: un test flaky salió mucho más caro. Antes, un test inestable molestaba una vez al día. Con diez veces más ejecuciones, molesta diez veces más y además confunde al agente, que va a intentar "arreglar" un código que no tenía ningún problema. Ya vi a un agente reescribir una función entera por culpa de un timeout aleatorio en un test E2E. La cuarentena de tests flaky dejó de ser un lujo.

Cómo medir si tu CI ya es el cuello de botella

Antes de salir a optimizar, mira los números. Bastan tres preguntas:

1. ¿Cuánto tarda, en promedio, desde el push hasta el resultado del CI? Si pasa de 10 minutos, tienes un problema.
2. ¿Cuántas ejecuciones al día se cancelan o quedan reemplazadas por un push más nuevo? Si son muchas, falta cancel-in-progress.
3. ¿Qué porcentaje de los jobs corre sobre código que no se tocó en el PR? En un monorepo sin filtro, la respuesta suele asustar.

La API de GitHub te da todo esto sin herramientas extra:

gh run list --limit 100 --json conclusion,createdAt,updatedAt,headBranch

Pásalo a una hoja de cálculo y ya tienes un retrato mejor que muchas reuniones de "tenemos que mejorar el CI".

También está el lado del bolsillo. En un plan gratuito, sea de GitHub Actions o de deploy en Vercel, la cuota se acaba rápido cuando cada push se convierte en cinco jobs y tres deploys de preview. Yo mismo tuve que poner filtros por carpeta en mis proyectos porque el agente hacía demasiados push y se comía el límite diario antes del almuerzo.

Mi opinión

Lo que más me gustó del texto de Linear es que no trata la IA como magia. Aceleró una parte del trabajo y dejó expuesto el resto. Eso es ingeniería normal: resuelves un cuello de botella y aparece el siguiente.

Lo que me molesta de todo este debate es el discurso de que "la IA va a hacer que el equipo entregue 10x más". Va a escribir 10x más, tal vez. Entregar depende de validar, revisar y poner en producción, y esas etapas no se aceleraron solas. Si tu pipeline se diseñó para un humano que abre dos PRs al día, no aguanta un equipo de agentes. De nada sirve tener un Ferrari si el garaje tiene entrada con torniquete.

Mi recomendación es empezar por lo barato: cancel-in-progress, filtro de afectados y cuarentena de flaky. Eso resuelve la mayor parte del problema en una tarde. Shards, remote cache y merge queue vienen después, cuando los números lo pidan.

Si quieres ver cómo organizo pipelines en monorepos reales, échale un vistazo a mis proyectos.

Mi agente escribe un PR en 4 minutos. El CI tarda 25 en decir si sirve.

Linear contó que, cuando la IA entró en el flujo del equipo, el cuello de botella dejó de ser escribir código y pasó a ser validarlo.

Cuando escribir código sale barato, verificarlo se vuelve el trabajo caro. Y un CI lento también vuelve lento al agente.

Lo que yo haría primero en una tarde: cancel-in-progress, ejecutar solo lo afectado y poner en cuarentena los tests flaky.

La IA puede hacer que el equipo escriba 10x más. Entregar 10x más depende de que el pipeline aguante.

Escribí en el blog cómo aplicar esto en cualquier monorepo, link en los comentarios.

#DevOps #CICD #IA #Monorepo #IngenieríaDeSoftware