El ingeniero lineal Mufeez Amjad ha publicado un relato detallado de cómo la compañía reelaboró su proceso de integración continua después de que los agentes de codificación de IA convirtieron la CI en su peor cuello de botella: redujeron el tiempo de espera de las solicitudes de extracción de más de seis minutos a poco más de cinco, mientras que sus conjuntos de pruebas casi se cuadruplicaron desde principios de año.
La publicación, publicada en el blog de ingeniería de Linear el 21 de septiembre, comenzó, como suele suceder con estas cosas, con un breve comentario desde arriba. A principios de este año, Amjad abrió Linear y descubrió que Tuomas, el CTO de la empresa, le había asignado un problema titulado "Los costos de CI son altos" y le pidió que hiciera CI más rápido mientras estaba en ello. Para obtener más contexto sobre esta historia, consulte nuestra cobertura de la industria de la IA en curso.
Cuando los agentes superan la validación
El problema es estructural, no incidental. "Los agentes han hecho que el envío de código sea exponencialmente más rápido", escribió Amjad, "pero la validación de esos cambios no se ha mantenido al mismo ritmo". Cada solicitud de extracción aún tiene que pasar por la CI, por lo que a medida que se acelera el desarrollo, la CI se convierte en el punto de estrangulamiento, lo que aumenta los costos de infraestructura y deja a los desarrolladores y sus agentes esperando más tiempo para recibir comentarios.
Optimización lineal para dos métricas: cuánto tiempo espera un PR en CI y cuánto tiempo de ejecución consume. Los resultados después de meses de trabajo: a pesar de que los conjuntos de pruebas casi se cuadruplicaron desde enero, el tiempo de espera de las solicitudes de extracción se redujo de más de seis minutos a poco más de cinco, y el tiempo de ejecución por prueba se redujo aproximadamente a la mitad.
En términos generales, el trabajo se dividió en cuatro categorías: infraestructura y herramientas mejoradas, optimización de los trabajos que acompañan a otros trabajos, reducción de la configuración repetida y mayor eficiencia de la ejecución de las pruebas. El código base de Linear es principalmente TypeScript, pero muchas de las optimizaciones se aplican en todos los lenguajes y cadenas de herramientas.
Máquinas más rápidas y un compilador nativo
Algunas de las primeras ganancias casi no requirieron optimización de la CI en sí. Mover cargas de trabajo de GitHub Actions a ejecutores de terceros con CPU más rápidas, almacenamiento de mayor rendimiento y mejor infraestructura de caché dio sus frutos de inmediato: en una comparación comparable de los dos días a ambos lados del cambio, los trabajos se ejecutaron un 34 % más rápido en promedio, y algunas cargas de trabajo como `tsc` cayeron un 52 %.
La modernización de la cadena de herramientas agravó la victoria. Cambiar a `tsgo`, el compilador nativo de TypeScript, redujo la mediana semanal de la verificación de tipo en un 73 %, lo suficientemente grande como para eliminar por completo el cuello de botella de la verificación de tipo.
Linting sin el gráfico de tipo
Linting fue otro de los primeros objetivos. Un puñado de reglas ESLint personalizadas de Linear dependían de la información de tipo TypeScript, lo que obligaba a cada ejecución de lint a construir el gráfico de tipo completo antes de evaluarlos, lo que hacía que linting fuera uno de los trabajos de CI que consume más memoria.
El equipo reescribió las reglas para utilizar análisis estático sobre el árbol de sintaxis abstracta, identificando construcciones similares a funciones y patrones de protección sin ningún tipo de información. Eso permitió a ESLint eliminar TypeScript por completo, reduciendo el tiempo de pelusa de API en un 68% y el tiempo de pelusa del repositorio completo en un 55%, con una caída sustancial del uso de memoria. También facilitó la migración posterior a Oxlint, lo que redujo aún más los minutos de corredor de CI dedicados a la eliminación de pelusa.
Reducir la ruta crítica
Con comprobaciones individuales más rápidas, Linear se alejó y trató a CI como un sistema. Eso llamó la atención sobre los pequeños trabajos que se encuentran delante de todo lo demás: la detección de cambios de ruta y las comprobaciones de caché de resultados de pruebas que se activan en el nivel de trabajo, lo que significa que ninguno de los ocho fragmentos de prueba de API puede comenzar hasta terminar.
Las correcciones fueron granulares pero aditivas. Limitar la profundidad de recuperación llevó la puerta más lenta de 94 segundos a 20. Eliminar el pago por completo de los trabajos que nunca necesitaron un árbol funcional los redujo de 27 segundos a 7. Un pago escaso y sin errores con un historial limitado ahorró otros 11 segundos y pico para eventos de inserción y cola de fusión. En conjunto, la duración media del trabajo de detección de cambios cayó de 26 segundos a 8, su p90 de 31 a 12 y su ejecución más lenta de 138 segundos a 37.
La confiabilidad del proceso de pago también necesitaba mejorar: debido a que los corredores de terceros se encuentran fuera de la red de GitHub y dependen de un enlace IP directo, la degradación intermitente del enlace ocasionalmente detenía las recuperaciones. Linear reemplazó `actions/checkout` con su propia acción compuesta que reintenta con retroceso, establece `GIT_HTTP_LOW_SPEED_LIMIT` y `GIT_HTTP_LOW_SPEED_TIME` para que una conexión bloqueada se cancele después de unos 30 segundos en lugar de colgarse, y utiliza un caché de checkout que mantiene un espejo git persistente en un disco adhesivo.
Una solución sutil eliminó el tiempo perdido en la cola de fusión: los marcadores de caché se escribían como parte de la verificación final antes de la fusión, por lo que un RP podía permanecer en la cola incluso después de pasar las pruebas. Mover esa escritura a un trabajo sin puerta redujo 42 segundos de la ruta de fusión para cada solicitud de extracción de API y entrada de cola de fusión. En conjunto, estos cambios quitaron aproximadamente un minuto de las comprobaciones requeridas para las PR de API en errores de caché y al mismo tiempo redujeron los inicios de los ejecutores.
Menos segundos desperdiciados por trabajo
La última categoría atacó el costo de preparación que se repitió en todos los trabajos. Cada fragmento de prueba de API dedicó de 7 a 8 segundos a instalar el mismo cliente Postgres con apt en cada ejecución; moverlo a una pequeña imagen base de CI junto con Node significó que los fragmentos podrían comenzar a estar listos para ejecutarse. Posteriormente, el equipo agregó encabezados de compilación nativos a la imagen después de descubrir que, en ocasiones, la descarga durante la configuración podía bloquearse.
Por qué resonó
La publicación conmovió a los desarrolladores: llegó a la portada de Hacker News, obteniendo aproximadamente 250 puntos y alrededor de 280 comentarios en un día. La reacción es fácil de explicar: la experiencia de Linear menciona un costo del desarrollo asistido por IA que la mayoría de las organizaciones de ingeniería recién ahora están enfrentando. Los agentes que generan solicitudes de extracción en minutos aún esperan en canales de validación diseñados para la cadencia humana, y cada minuto de esa espera se multiplica entre todos los agentes que trabajan en paralelo.
La lección de la reelaboración de Linear es que el cuello de botella es móvil, pero sólo a través de la poco glamorosa acumulación de muchas pequeñas correcciones (corredores más rápidos, comprobaciones de tipos más baratas, reglas de pelusa a nivel de sintaxis, recuperaciones limitadas, comprobaciones resilientes, imágenes prediseñadas) en lugar de una solución milagrosa única.
---
Manténgase a la vanguardia de la IAObtenga las últimas noticias, análisis y avances en IA, todo en un solo lugar.
Leer más noticias sobre IA →
