O engenheiro linear Mufeez Amjad publicou um relato detalhado de como a empresa reformulou seu pipeline de integração contínua depois que os agentes de codificação de IA transformaram a CI em seu pior gargalo – reduzindo o tempo de espera de solicitações pull de mais de seis minutos para pouco mais de cinco, enquanto seus conjuntos de testes quase quadruplicaram desde o início do ano.
A postagem, publicada no blog de engenharia da Linear em 21 de setembro, começou, como costuma acontecer, com um bilhete conciso vindo de cima. No início deste ano, Amjad abriu a Linear e descobriu que Tuomas, o CTO da empresa, havia atribuído a ele uma questão intitulada “Os custos de CI são altos” – e pediu-lhe que tornasse a CI mais rápida enquanto estivesse nisso. Para obter mais contexto sobre esta história, consulte nossa cobertura do setor de IA em andamento.
Quando os agentes superam a validação
O problema é estrutural e não incidental. “Os agentes tornaram o envio de código exponencialmente mais rápido”, escreveu Amjad, “mas a validação dessas mudanças não manteve o mesmo ritmo”. Cada solicitação pull ainda precisa passar pela CI, portanto, à medida que o desenvolvimento acelera, a CI se torna o ponto de estrangulamento, aumentando os custos de infraestrutura e deixando os desenvolvedores e seus agentes esperando mais tempo pelo feedback.
Linear otimizado para duas métricas: quanto tempo um PR espera no CI e quanto tempo de execução ele consome. Os resultados após meses de trabalho: apesar dos conjuntos de testes terem quase quadruplicado desde janeiro, o tempo de espera das solicitações pull caiu de mais de seis minutos para pouco mais de cinco, e o tempo do executor por teste foi reduzido aproximadamente pela metade.
O trabalho se dividiu amplamente em quatro categorias: atualização de infraestrutura e ferramentas, otimização dos trabalhos que envolvem outros trabalhos, redução de configurações repetidas e maior eficiência na execução de testes. A base de código do Linear é principalmente TypeScript, mas muitas das otimizações se aplicam a linguagens e conjuntos de ferramentas.
Máquinas mais rápidas e um compilador nativo
Alguns dos primeiros ganhos quase não exigiram otimização da própria CI. Transferir cargas de trabalho do GitHub Actions para executores de terceiros com CPUs mais rápidas, armazenamento de maior desempenho e melhor infraestrutura de cache valeu a pena imediatamente: em uma comparação igual dos dois dias de cada lado da mudança, os trabalhos foram executados 34% mais rápido em média, com algumas cargas de trabalho como `tsc` caindo 52%.
A modernização do conjunto de ferramentas agravou a vitória. Mudar para `tsgo`, o compilador TypeScript nativo, reduziu a mediana semanal da verificação de tipo em 73% - grande o suficiente para remover totalmente o gargalo da verificação de tipo.
Linting sem o gráfico de tipo
Linting foi outro alvo inicial. Algumas regras ESLint personalizadas do Linear dependiam de informações de tipo TypeScript, o que forçava cada execução de lint a construir o gráfico de tipo completo antes de avaliá-los – tornando o linting um dos trabalhos de CI que mais consome memória.
A equipe reescreveu as regras para usar análise estática na árvore de sintaxe abstrata, identificando construções semelhantes a funções e padrões de proteção sem qualquer informação de tipo. Isso permitiu que o ESLint abandonasse totalmente o TypeScript, reduzindo o tempo de lint da API em 68% e o tempo de lint do repositório completo em 55%, com o uso de memória caindo substancialmente. Também facilitou a migração posterior para Oxlint, o que reduziu ainda mais os minutos de execução de CI gastos em linting.
Reduzindo o caminho crítico
Com verificações individuais mais rápidas, o Linear diminuiu o zoom e tratou o CI como um sistema. Isso chamou a atenção para os pequenos trabalhos que estão na frente de todo o resto – detecção de mudança de caminho e verificações de cache de resultados de testes que são realizadas no nível do trabalho, o que significa que nenhum dos oito fragmentos de teste de API pode começar antes de terminar.
As correções foram granulares, mas aditivas. Limitar a profundidade de busca levou o portão mais lento de 94 segundos para 20. Remover totalmente o checkout de trabalhos que nunca precisaram de uma árvore de trabalho reduziu esses de 27 segundos para 7. Um checkout esparso e sem bolhas com histórico limitado economizou outros 11 segundos para eventos de push e fila de mesclagem. No total, a duração média do trabalho de detecção de alterações caiu de 26 segundos para 8, o p90 de 31 para 12 e a execução mais lenta de 138 segundos para 37.
A confiabilidade do checkout também precisava de melhorias: como os executores de terceiros ficam fora da rede do GitHub e dependem de um link IP direto, a degradação intermitente do link ocasionalmente paralisava as buscas. Linear substituiu `actions/checkout` por sua própria ação composta que tenta novamente com espera, define `GIT_HTTP_LOW_SPEED_LIMIT` e `GIT_HTTP_LOW_SPEED_TIME` para que uma conexão paralisada seja abortada após cerca de 30 segundos em vez de travar e use um cache de checkout que mantém um espelho git persistente em um disco adesivo.
Uma correção sutil eliminou o desperdício de tempo na fila de mesclagem: marcadores de cache estavam sendo gravados como parte da verificação final antes da mesclagem, para que um PR pudesse permanecer na fila mesmo depois de seus testes serem aprovados. Mover essa gravação para um trabalho sem bloqueio reduziu 42 segundos do caminho de mesclagem para cada solicitação pull de API e entrada na fila de mesclagem. Juntas, essas mudanças reduziram em cerca de um minuto as verificações necessárias para PRs de API em caso de falhas de cache, ao mesmo tempo que reduziram as inicializações do executor.
Menos segundos desperdiçados por trabalho
A última categoria atacou o custo de configuração repetido em todos os trabalhos. Cada fragmento de teste da API gastou de 7 a 8 segundos instalando o mesmo cliente Postgres com apt em cada execução; movê-lo para uma pequena imagem base de CI ao lado do Node significava que os fragmentos poderiam começar a ficar prontos para execução. Posteriormente, a equipe adicionou cabeçalhos de compilação nativos à imagem depois de descobrir que baixá-los durante a configuração poderia ocasionalmente travar.
Por que ressoou
A postagem tocou os desenvolvedores: chegou à primeira página do Hacker News, atraindo cerca de 250 pontos e cerca de 280 comentários em um dia. A reação é fácil de explicar: a experiência da Linear aponta um custo do desenvolvimento assistido por IA que a maioria das organizações de engenharia só agora está enfrentando. Agentes que geram pull requests em minutos ainda aguardam pipelines de validação projetados para cadência humana, e cada minuto dessa espera é multiplicado por cada agente trabalhando em paralelo.
A lição do retrabalho do Linear é que o gargalo é móvel, mas apenas por meio do acúmulo nada glamoroso de muitas pequenas correções – executores mais rápidos, verificações de tipo mais baratas, regras de lint em nível de sintaxe, buscas limitadas, checkouts resilientes, imagens pré-construídas – em vez de qualquer solução mágica única.
---
Fique à frente da IAReceba as últimas notícias, análises e avanços sobre IA — tudo em um só lugar.
Leia mais notícias sobre IA →
