A IA acelerou o código. Agora o gargalo é o CI

A novidade mais importante da IA para desenvolvimento, em setembro de 2026, não é só o modelo que escreve mais código: é o pipeline que precisa validar esse código na mesma velocidade. O caso recente da Linear mostra que agentes de programação aceleram pull requests, mas transformam CI, lint, testes e merge queue no novo gargalo operacional.

Em um relato publicado em 21 de setembro de 2026, a Linear descreveu como refez parte do seu CI depois que agentes aumentaram o volume de mudanças. A suíte de testes quase quadruplicou desde o começo do ano; ainda assim, a espera de pull requests caiu de mais de 6 minutos para pouco acima de 5 minutos, com tempo de runner por teste cortado aproximadamente pela metade.

Isso importa porque a adoção de IA saiu da fase de autocomplete. Ferramentas como GitHub Copilot, Cursor, Claude Code, Codex e agentes internos já criam branches, escrevem testes e abrem PRs. Em escala, a restrição vira validar, revisar e integrar mudanças com confiança.

O que aconteceu na Linear?

A Linear não tratou o problema como uma simples troca de ferramenta. O diagnóstico foi sistêmico: cada PR ainda passava por CI, então qualquer aumento na produção de código ampliava filas, custo de infraestrutura e tempo de feedback.

Ao mover workloads do GitHub Actions para runners de terceiros com CPUs, armazenamento e cache melhores, a empresa mediu jobs 34% mais rápidos em média. O check de tsc caiu 52% em alguns workloads. Depois, a mudança para tsgo, o compilador nativo de TypeScript, reduziu a mediana semanal do check de TypeScript em 73%.

Outro ponto foi o lint. Regras customizadas que dependiam do grafo de tipos obrigavam o ESLint a carregar muito contexto. A Linear reescreveu regras para operar sobre AST, sem type checking, e reduziu o lint da API em 68% e o lint do repositório inteiro em 55%.

• Change detection caiu de 26 segundos de mediana para 8 segundos.
• Instalação filtrada com pnpm reduziu installs de 44-73 segundos para 16-18 segundos.
• Setup por shard caiu de 110-140 segundos para 67-73 segundos.
• Consolidar sete checks curtos em dois jobs economizou cerca de 87.000 runner-minutes por mês.
• isolate: false no Vitest, com opt-in explícito, trouxe cerca de 17% de economia mensal.

Por que IA muda a arquitetura do CI?

Com agentes, o gargalo aparece em três camadas: volume de PRs, quantidade de testes gerados e repetição de setup. A IA aumenta a taxa de tentativa: um agente pode abrir três abordagens para o mesmo bug, ajustar mocks e rodar iterações automáticas. Isso é ótimo quando o feedback é rápido; quando demora, vira fila cara.

Na prática, CI para times com IA precisa ser tratado como produto interno, não como arquivo YAML esquecido. Um pipeline moderno precisa responder a perguntas como:

• Quais jobs estão no caminho crítico do merge?
• Qual é o custo fixo de subir runner, fazer checkout e instalar dependências?
• O cache realmente ajuda ou só adiciona variabilidade?
• Os testes estão balanceados por duração real ou apenas por quantidade de arquivos?
• O agente que escreve testes conhece as convenções de performance do repositório?

Esse último ponto é novo. A Linear menciona que atualizou suas skills de agentes para que testes gerados sigam as mesmas regras de performance por padrão. Não basta otimizar o CI; é preciso ensinar a IA a não desfazer a otimização no próximo PR.

O que desenvolvedores e empresas devem mudar agora?

Times que usam IA para programar precisam medir throughput de validação, não apenas produtividade individual. PRs abertos por semana e linhas geradas escondem a pergunta principal: quanto tempo uma mudança leva para virar software confiável em produção?

Um checklist mínimo para 2026 deveria incluir:

1. Separar checks rápidos de bloqueio real dos checks informativos.
2. Reduzir checkout, histórico Git e blobs quando o job só precisa de metadados.
3. Instalar apenas dependências do pacote afetado em monorepos.
4. Evitar cache quando restore e save custam mais que reinstalar.
5. Medir p50, p90 e p95 de cada etapa, não só tempo médio total.
6. Dar instruções explícitas aos agentes sobre padrões de teste, isolamento e fixtures.

Um exemplo simples de política para agentes em um repositório TypeScript:

Ao criar testes:
- prefira arquivos pequenos e focados;
- não adicione sleeps ou timers reais;
- reutilize fixtures existentes;
- marque testes elegíveis para execução sem isolamento apenas quando não houver estado global;
- rode o pacote afetado antes de ampliar para a suíte inteira.

Isso parece detalhe, mas muda a economia do desenvolvimento. Se cada PR economiza 30 ou 60 segundos, o ganho mensal em um time grande vira milhares de minutos de runner e muitas horas humanas de espera.

Qual é a lição para a atualidade da IA?

A fase atual da IA em software está menos glamourosa e mais operacional. Modelos melhores continuam importantes, mas a vantagem competitiva aparece em quem integra esses modelos a sistemas de engenharia: testes, observabilidade, permissões, revisão, deploy e custo.

O caso da Linear mostra que IA não elimina engenharia de software; ela aumenta a pressão sobre partes que antes podiam ser medianas. Um CI aceitável para humanos pode ser lento demais para agentes. Uma suíte de testes que cresce sem design pode virar imposto sobre cada mudança.

Para empresas, comprar assentos de IA é só o começo. O retorno vem quando o ambiente inteiro absorve a nova velocidade. Para desenvolvedores, a habilidade valorizada não será apenas pedir código ao modelo, mas construir um sistema onde esse código possa ser validado rápido e barato.

Perguntas frequentes

Como a IA afeta o CI em times de desenvolvimento?

A IA aumenta a quantidade de mudanças, testes e iterações por unidade de tempo. Com isso, CI lento passa a limitar entrega, elevar custo de runners e atrasar feedback para humanos e agentes.

Por que agentes de código tornam testes mais caros?

Agentes conseguem gerar mais PRs e mais casos de teste rapidamente. Sem sharding, instalação seletiva e regras claras de teste, cada tentativa repete setup, checkout e dependências desnecessárias.

Vale a pena trocar GitHub Actions por runners externos?

Depende do gargalo medido. No caso da Linear, runners externos trouxeram ganhos médios de 34%, mas a maior lição é medir CPU, armazenamento, cache, checkout e caminho crítico antes de trocar ferramenta.

Como preparar um monorepo para programação com IA?

O ideal é ter instalação por pacote afetado, testes bem divididos, lint sem type checking quando possível, métricas por job e instruções para agentes seguirem padrões de performance do repositório.