A geração de código orientada por IA transformou a integração contínua em um gargalo na Linear, forçando a empresa a reformular todo o seu pipeline de CI para acompanhar o volume de mudanças que os agentes agora produzem. O time de engenharia reduziu o tempo de espera de pull request de mais de 6 minutos para pouco mais de 5 minutos enquanto reduzia pela metade o tempo de runner por teste, apesar da suite de testes ter quase quadruplicado de tamanho desde o início de 2026.
O problema surgiu conforme agentes aceleraram o envio de código, mas a infraestrutura de validação não escalou com isso. Cada PR ainda passa por CI, então conforme a velocidade de desenvolvimento aumentou, o pipeline se tornou um gargalo tanto para loops de feedback de desenvolvedores quanto de agentes, elevando custos de infraestrutura. A resposta da Linear foi sistemática: otimizaram duas métricas — quanto tempo um PR espera em CI e quanto tempo de runner cada teste consome — em quatro categorias de trabalho.
Mudanças de infraestrutura sozinhas geraram ganhos imediatos. Mover workloads do GitHub Actions para runners de terceiros com CPUs mais rápidas e melhor infraestrutura de cache fez jobs rodarem 34% mais rápido em média, com alguns workloads como compilação TypeScript caindo 52%. Separadamente, mudar para tsgo, um compilador TypeScript nativo, reduziu a mediana semanal da verificação tsc em 73%, movendo o gargalo completamente da verificação de tipos. Linting foi outro alvo inicial: Linear reescreveu regras de lint customizadas para usar análise estática sobre a árvore de sintaxe abstrata em vez de construir o grafo de tipos completo, reduzindo tempo de lint de API em 68% e tempo de lint de repositório completo em 55%.
O time então otimizou jobs no caminho crítico. Jobs de detecção de mudanças que decidem o que roda depois estavam fazendo checkout da árvore de trabalho completa mesmo quando precisavam apenas de um subconjunto. Limitar profundidade de fetch levou o mais lento desses gates de 94 segundos para 20 segundos, e remover checkout completamente de jobs que nunca precisavam de uma árvore de trabalho reduziu tempo de 27 segundos para 7 segundos. A duração mediana do job de detecção de mudanças caiu de 26 para 8 segundos. Depois de mudar infraestrutura de runner, tempos de checkout cresceram e às vezes travavam devido a instabilidade de rede entre runners de terceiros e GitHub. Linear substituiu a ação de checkout padrão por uma ação composta que tentava novamente com backoff e definia timeouts de conexão para abortar após cerca de 30 segundos em vez de travar indefinidamente.
Overhead de setup consumia recursos desproporcionais. Cada shard de teste de API da Linear gastava 7 a 8 segundos instalando o mesmo cliente Postgres a cada execução; movê-lo para uma imagem base de CI eliminou esse custo. O workflow de teste de API estava instalando todo o workspace pnpm apesar de precisar apenas do pacote de API e suas dependências; restringir a instalação reduziu pnpm install de 44-73 segundos para 16-18 segundos. Testes mostraram que fazer cache de node_modules era mais lento que reconstruir: um cache hit levava cerca de 28 segundos para restaurar versus aproximadamente 7,5 segundos para uma instalação filtrada. Juntas, essas mudanças reduziram tempo de setup por shard em aproximadamente 44%, de 110-140 segundos para 67-73 segundos. Sete verificações independentes que cada uma iniciava um runner, fazia checkout do repositório e instalava dependências antes de fazer apenas segundos de trabalho útil foram consolidadas em dois jobs rodando sete tarefas concorrentemente dentro deles, economizando aproximadamente 87.000 runner-minutos por mês, equivalente a 11.8% do uso total de CI.
A maior otimização única veio da execução de testes. Vitest, o test runner TypeScript da Linear, distribui trabalho por arquivo em vez de por duração de teste, significando que alguns arquivos de teste grandes poderiam dominar um shard e atrasar toda a suite. Linear dividiu esses arquivos em menores, mais focados, e mudou de quatro para oito shards, tornando o job crítico aproximadamente 19% mais rápido e 19% mais barato. Mais significativamente, introduziram um projeto vitest opt-in com isolate: false, permitindo que arquivos seguros compartilhassem um registro de módulo dentro de cada worker em vez de reconstruir o grafo de entidade, GraphQL e decorator em cada shard. Essa mudança única valeu aproximadamente 17% em economia mensal, reduzindo o shard mais lento de 300-379 segundos para cerca de 195 segundos e tempo total de runner de shard de API de cerca de 32.8 para 22 minutos por execução. A otimização carregava risco de correção: Linear tornou elegibilidade explícita com um comentário opt-in em cada arquivo, adicionou teardown necessário para estado compartilhado, e atualizou suas skills de agente para que testes gerados sigam as mesmas restrições por padrão.
Sem essas mudanças, a suite de testes da Linear levaria aproximadamente 11 minutos hoje, perto do dobro do que desenvolvedores esperam agora. A empresa está adicionando aproximadamente 2.000 testes por semana, então manter CI rápido conforme a base de código cresce exigirá esforço contínuo. A lição para arquitetos: quando agentes de IA mudam a forma de sua carga de trabalho de build, o gargalo se move de geração de código para validação, e a solução exige repensar infraestrutura, dependências de jobs e overhead de setup como um sistema em vez de otimizar componentes individuais isoladamente.