Linear bajó el CI de 6 a 5 minutos con tests cuadruplicados

¿Cómo logró Linear bajar la espera de CI mientras cuadruplicaba sus tests?

Linear casi cuadruplicó su suite de tests desde enero y aun así bajó el tiempo medio de espera de un pull request de más de 6 minutos a poco más de 5, según un post de ingeniería publicado esta semana. El movimiento no fue acelerar los tests, sino tratar la CI como un sistema cuyo cuello de botella se mueve cada vez que un agente de IA envía código más rápido.

El CTO Tuomas le asignó al equipo un ticket titulado "los costos de CI son altos", con una segunda línea igual de imperiosa: "y, de paso, hazla más rápida". Lo que siguió fue una reescritura en cuatro frentes —infraestructura, trabajos críticos, setup repetido y ejecución de tests— que dejó a la suite corriendo a casi la mitad del tiempo de runner por test.

¿Por qué la CI se volvió el cuello de botella del desarrollo con IA?

El caso de Linear no es aislado. CircleCI presentó en junio de 2026 su funcionalidad Chunk Sidecars, pensada para llevar la validación al "inner loop" del agente, antes de que el código llegue siquiera a la pipeline tradicional. Según la propia CircleCI, la actividad en feature branches ha crecido notablemente con la adopción de herramientas de IA, mientras que los despliegues a producción no han seguido el mismo ritmo. La validación, no la generación de código, se está convirtiendo en el factor limitante.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

El fenómeno tiene una arista operativa. Snyk, en el lanzamiento de Evo Agentic Development Security también en junio de 2026, reportó que el 43% de los desarrolladores corren dos o más entornos de coding con IA en paralelo, y que más de la mitad tienen servidores MCP instalados. Uno de cada doce desarrolladores con servidores MCP activos tenía al menos un hallazgo de severidad alta o crítica en su entorno.

Para founders, el mensaje es directo: escribir código dejó de ser el cuello de botella. Validarlo, sí.

¿Qué cambió exactamente en la pipeline de Linear?

Linear trabajó en cuatro frentes durante la primera mitad de 2026.

Infraestructura y tooling. El primer salto no tocó la pipeline en sí: mover las cargas de GitHub Actions a runners de terceros con CPUs más rápidas, mejor storage y caché más eficiente dio un 34% de aceleración promedio, y el typecheck con tsc cayó 52%. Migrar a tsgo, el compilador nativo de TypeScript, redujo la mediana semanal del typecheck un 73%.

Trabajos que frenan al resto. Linear detectó que pequeños jobs de detección de cambios estaban en el camino crítico de los ocho shards de tests de API. Limitar la profundidad de fetch llevó al más lento de 94 a 20 segundos. Eliminar el checkout en los jobs que no necesitaban working tree bajó esos jobs de 27 a 7 segundos. Sustituir actions/checkout por una acción compuesta con reintentos y caché persistente eliminó los hangs por latencia con GitHub. Mover la escritura de cache markers fuera del path crítico ahorró 42 segundos por cada PR de API.

Setup repetido. Instalar Postgres en cada shard costaba 7-8 segundos; moverlo a una imagen base lo eliminó. Cambiar el install de pnpm para que cada job solo traiga sus dependencias —en lugar del workspace completo— bajó el install de 44-73 segundos a 16-18. Dejar de cachear node_modules porque el install filtrado era más rápido (7,5s vs 28s de restore) terminó de cerrar el frente. En conjunto, el setup por shard cayó de 110-140s a 67-73s, una mejora del 44%.

Ejecución de tests. Vitest distribuye trabajo por archivo, así que unos pocos archivos muy grandes dominaban el shard más lento. Linear los partió, subió el sharding de 4 a 8 y creó un proyecto opt-in con isolate: false para que los archivos seguros compartan registro de módulos dentro de cada worker. El shard más lento bajó de 300-379s a 195s, y el tiempo total de los shards de API por run cayó de 32,8 a 22 minutos: 17% de ahorro mensual.

Como remate, consolidar siete checks cortos en dos jobs concurrentes ahorró, según datos de junio, unas 87.000 runner-minutes al mes, equivalentes al 11,8% del uso total de CI.

¿Qué significa esto para tu startup?

Linear opera con un stack de TypeScript en monorepo y un negocio que, según Business Insider, vale US$2.500M tras duplicar su valoración en agosto de 2026. La empresa declaró más de US$100M de ARR y unos 40.000 clientes pagos, incluyendo OpenAI, Salesforce, Cursor y Coinbase, según el mismo reporte.

La diferencia con la mayoría de equipos en LATAM y España: Linear añade unas 2.000 tests por semana y la cifra sigue subiendo. Si tu pipeline actual depende de que un humano escriba el código, el cuello de botella todavía no se ha movido. Cuando un agente de IA empiece a proponer el grueso de tus PRs, se moverá, y rápido.

Tres acciones concretas que puedes aplicar mañana:

Audita qué hay en tu camino crítico. En Linear, mover un solo job de escritura de caché fuera del merge path ahorró 42 segundos por PR. Revisa qué se ejecuta antes de tus shards y pregúntate si realmente necesita estar ahí.
Mide antes de cachear. Linear descubrió que su caché de node_modules era unos 20 segundos más lenta que un install filtrado de pnpm. Antes de añadir una capa de caché, mide el restore contra un install limpio: a veces la caché es peor que la falta de ella.
Consolida checks cortos. Cada runner que arranca paga setup aunque solo haga segundos de trabajo útil. En Linear, fusionar siete checks en dos jobs concurrentes ahorró el 11,8% del uso mensual de CI. Mapear tus jobs más cortos puede devolver más que cualquier optimización del test runner.

Linear estima que, sin estos cambios, su suite tardaría hoy cerca de 11 minutos por PR, casi el doble de lo que esperan ahora sus desarrolladores. La pregunta para tu equipo no es si la IA va a acelerar tu generación de código. Es si tu pipeline va a poder seguirle el paso cuando lo haga.