Linear afirma que la programación asistida por IA hizo que la validación de sus solicitudes de cambios se quedara rezagada respecto de la producción de código. Según el relato de la propia empresa, su conjunto de pruebas casi se cuadruplicó, mientras que el tiempo medio de espera de las solicitudes de cambios bajó de más de seis minutos a poco más de cinco, y el tiempo de ejecución por prueba disminuyó aproximadamente a la mitad. Estas son mediciones comunicadas por la propia Linear, no una evaluación independiente.

La principal lección de la empresa es que la velocidad de la CI es un problema sistémico. Los ejecutores más rápidos ayudaron: Linear afirma que los trabajos fueron de media un 34 % más rápidos después de trasladar las cargas de trabajo a una infraestructura con CPU, almacenamiento y caché más veloces. Pero también acortó los pasos de descarga del código, eliminó tareas innecesarias de la ruta de integración, preinstaló dependencias compartidas y instaló únicamente los paquetes que necesitaba cada trabajo. La configuración por fragmento cayó aproximadamente un 44 %, de 110–140 segundos a 67–73 segundos.

Tiempos de un flujo de trabajo de GitHub Actions que comparan dos ejecuciones de CI de test-api
La comparación de GitHub Actions de Linear muestra que la ejecución de test-api bajó de 4 min 57 s a 3 min 14 s.linear.app

Los tiempos paso a paso hacen concretas las mejoras de velocidad de la canalización después del análisis de ejecutores más rápidos, una configuración más breve y una reducción del trabajo de la ruta crítica.

Las mayores mejoras provinieron de cambiar cómo se ejecutaban las pruebas, no solo dónde se ejecutaban. Linear dividió archivos de pruebas grandes, pasó de cuatro fragmentos de API a ocho e introdujo un registro compartido y optativo de módulos de Vitest para los archivos que podían utilizarlo de forma segura. La empresa afirma que el fragmento más lento bajó de aproximadamente 300–379 segundos a unos 195 segundos, mientras que el tiempo de ejecución de los fragmentos de API cayó de unos 32,8 a 22 minutos por ejecución.

Flujo de trabajo de lotes de CI antes y después, con tiempos de ejecución
Una vista del flujo de trabajo antes y después ilustra cómo el trabajo por lotes y los cambios en las dependencias acortaron las fases de la CI.linear.app

Esta figura respalda la explicación del artículo de que la reorganización del trabajo y de las dependencias, y no solo el cambio de hardware, contribuyó a una validación más rápida.

Diagrama de caché del estado de los módulos que compara el estado individual y el compartido
El diagrama del estado compartido ilustra la optimización que sustenta el registro de módulos de Vitest de Linear.linear.app

La estructura antes y después aclara cómo compartir un único estado redujo las reconstrucciones redundantes, mientras que el artículo también señala los requisitos de aislamiento para los archivos no seguros.

Esa optimización conlleva un coste en materia de corrección. El estado compartido de los módulos puede dejar al descubierto temporizadores simulados u otras interacciones de estado, así que Linear mantuvo aislados los archivos no seguros, añadió operaciones de limpieza y actualizó las recomendaciones para las pruebas generadas. La conclusión práctica es más específica que «comprar ejecutores más rápidos»: cuando la IA aumenta el volumen de cambios, las mejoras de la CI suelen provenir de reducir la configuración repetida, acortar los trabajos de la ruta crítica y paralelizar solo allí donde sigan cumpliéndose las reglas de aislamiento.