La generación de código impulsada por IA ha convertido la integración continua en un cuello de botella en Linear, obligando a la empresa a rediseñar toda su canalización de CI para mantenerse al ritmo del volumen de cambios que ahora producen los agentes. El equipo de ingeniería redujo el tiempo de espera de las solicitudes de extracción de más de 6 minutos a poco más de 5 minutos mientras reducía a la mitad el tiempo del runner por prueba, a pesar de que la suite de pruebas se cuadruplicara casi desde el inicio de 2026.

El problema surgió cuando los agentes aceleraron el envío de código pero la infraestructura de validación no se escaló con él. Cada PR sigue pasando por CI, así que conforme aumentó la velocidad de desarrollo, la canalización se convirtió en una restricción tanto para los bucles de retroalimentación del desarrollador como del agente, aumentando los costos de infraestructura. La respuesta de Linear fue sistemática: optimizaron dos métricas —cuánto tiempo espera un PR en CI y cuánto tiempo de runner consume cada prueba— en cuatro categorías de trabajo.

Los cambios de infraestructura por sí solos produjeron ganancias inmediatas. Mover cargas de trabajo de GitHub Actions a runners de terceros con CPUs más rápidas e infraestructura de caché mejorada hizo que los trabajos se ejecutaran 34% más rápido en promedio, con algunas cargas de trabajo como la compilación de TypeScript cayendo 52%. Por separado, cambiar a tsgo, un compilador TypeScript nativo, redujo la mediana semanal de la verificación de tsc en 73%, moviendo el cuello de botella completamente fuera de la verificación de tipos. El linting fue otro objetivo temprano: Linear reescribió reglas de linting personalizadas para usar análisis estática sobre el árbol de sintaxis abstracta en lugar de construir el gráfico de tipos completo, reduciendo el tiempo de linting de API en 68% y el tiempo de linting de repositorio completo en 55%.

El equipo luego optimizó trabajos en la ruta crítica. Los trabajos de detección de cambios que deciden qué se ejecuta después estaban verificando el árbol de trabajo completo incluso cuando necesitaban solo un subconjunto. Limitar la profundidad de búsqueda llevó la más lenta de estas compuertas de 94 segundos a 20 segundos, y eliminar completamente la verificación de trabajos que nunca necesitaban un árbol de trabajo redujo el tiempo de 27 segundos a 7 segundos. La duración mediana del trabajo de detección de cambios cayó de 26 a 8 segundos. Después de cambiar la infraestructura del runner, los tiempos de verificación habían crecido y a veces se colgaban debido a inestabilidad de red entre runners de terceros y GitHub. Linear reemplazó la acción de verificación estándar con una acción compuesta que reintentaba con retroceso y establecía tiempos de espera de conexión para abortar después de aproximadamente 30 segundos en lugar de colgarse indefinidamente.

La sobrecarga de configuración consumía recursos desproporcionados. Cada fragmento de prueba de API de Linear pasaba 7 a 8 segundos instalando el mismo cliente de Postgres en cada ejecución; moverlo a una imagen base de CI eliminó ese costo. El flujo de trabajo de prueba de API estaba instalando todo el espacio de trabajo de pnpm aunque solo necesitaba el paquete de API y sus dependencias; restringir la instalación redujo pnpm install de 44-73 segundos a 16-18 segundos. Las pruebas mostraron que almacenar en caché node_modules era más lento que reconstruir: un acierto de caché tomó aproximadamente 28 segundos para restaurar versus aproximadamente 7.5 segundos para una instalación filtrada. Juntos, estos cambios redujeron el tiempo de configuración por fragmento en aproximadamente 44%, de 110-140 segundos a 67-73 segundos. Siete verificaciones independientes que cada una iniciaba un runner, verificaba el repositorio e instalaba dependencias antes de hacer solo segundos de trabajo útil se consolidaron en dos trabajos ejecutando siete tareas concurrentemente dentro de ellos, ahorrando aproximadamente 87,000 minutos de runner por mes, equivalente a 11.8% del uso total de CI.

La optimización individual más grande provino de la ejecución de pruebas. Vitest, el ejecutor de pruebas de TypeScript de Linear, distribuye el trabajo por archivo en lugar de por duración de prueba, lo que significa que algunos archivos de prueba grandes podrían dominar un fragmento y retener toda la suite. Linear dividió esos archivos en otros más pequeños y enfocados y pasó de cuatro a ocho fragmentos, haciendo el trabajo crítico aproximadamente 19% más rápido y 19% más barato. Más significativamente, introdujeron un proyecto vitest opcional con isolate: false, permitiendo que archivos seguros compartan un registro de módulos dentro de cada worker en lugar de reconstruir el gráfico de entidad, GraphQL y decorador en cada fragmento. Este único cambio valió aproximadamente 17% en ahorros mensuales, reduciendo el fragmento más lento de 300-379 segundos a aproximadamente 195 segundos y el tiempo total de runner de fragmento de API de aproximadamente 32.8 a 22 minutos por ejecución. La optimización conllevaba riesgo de corrección: Linear hizo la elegibilidad explícita con un comentario opcional en cada archivo, agregó la limpieza necesaria para estado compartido, y actualizó sus habilidades de agente para que las pruebas generadas sigan las mismas restricciones por defecto.

Sin estos cambios, la suite de pruebas de Linear tomaría aproximadamente 11 minutos hoy, cerca del doble de lo que los desarrolladores esperan ahora. La empresa está agregando aproximadamente 2,000 pruebas por semana, así que mantener CI rápido conforme crece la base de código requerirá esfuerzo continuo. La lección para arquitectos: cuando los agentes de IA cambian la forma de tu carga de trabajo de compilación, el cuello de botella se mueve de la generación de código a la validación, y la solución requiere repensar la infraestructura, las dependencias de trabajos y la sobrecarga de configuración como un sistema en lugar de optimizar componentes individuales de forma aislada.