Gargalo de CI na era da IA: o que a Linear mudou

Seu agente escreve um PR em 4 minutos e o CI leva 25 para dizer se ele presta. Essa conta não fecha. A Linear publicou um texto contando exatamente isso: depois que a IA entrou no fluxo de código do time, o gargalo de CI apareceu, e eles tiveram que refazer o pipeline para acompanhar.

O texto vale a leitura inteira pelos detalhes. Aqui eu quero falar do que isso significa para quem não é a Linear: você, eu e o time de cinco pessoas com um monorepo que cresceu sem pedir licença.

O que aconteceu na Linear

A tese é simples. Por anos, o tempo de escrever código era o passo mais lento do ciclo. O CI rodava enquanto você ia buscar café, e ninguém reclamava muito.

Aí vieram os agentes de código. O volume de PRs subiu. Os PRs ficaram menores e mais frequentes. Tem dev abrindo três, quatro branches em paralelo, cada uma com um agente trabalhando. E cada push dispara o pipeline inteiro.

O resultado é previsível: a fila de CI virou o lugar onde o trabalho espera. A Linear olhou para isso e tratou o CI como produto, não como encanamento. Mexeu em como os testes são escolhidos, em como o trabalho é paralelizado e em quanto se reaproveita entre execuções.

Por que a IA transformou o CI em gargalo

Pensa no ciclo como uma esteira com três etapas: escrever, validar, revisar. Se uma etapa fica dez vezes mais rápida, a mais lenta passa a mandar no ritmo. É a lei de Amdahl aplicada ao seu dia.

Antes da IA, um dev abria talvez dois ou três PRs por dia. Hoje, com agente, esse número pode facilmente triplicar. Se cada execução custa 20 minutos de runner, você não tem só mais espera. Você tem mais custo, mais fila e mais troca de contexto.

E tem um detalhe que pouca gente comenta: o agente depende do CI mais do que você. Você sabe que mudou só um CSS. O agente não tem esse instinto, ou pelo menos você não deveria confiar nele. Ele precisa do sinal verde ou vermelho para saber se terminou. CI lento deixa o agente lento também.

Quando escrever código fica barato, verificar código vira o trabalho caro.

O que muda no pipeline na prática

Não dá para copiar a infraestrutura da Linear, mas os princípios servem para qualquer projeto. Esses são os que eu aplicaria primeiro, em ordem de esforço.

Cancelar execuções que ninguém vai ler

Se você deu push três vezes em dois minutos, só o último resultado importa. No GitHub Actions isso é uma linha de configuração, e muito projeto ainda não tem:

concurrency:
  group: ci-${{ github.ref }}
  cancel-in-progress: true

Com agente fazendo push a cada ajuste, isso sozinho já corta uma fatia boa da fila.

Rodar só o que foi afetado

Em monorepo, rodar todos os testes de todos os apps a cada PR é queimar dinheiro. Turborepo e Nx já sabem calcular o que mudou a partir do grafo de dependências:

bunx turbo run test lint type-check --filter='...[origin/main]'

Mudou só o app de marketing? Não tem por que testar a API de pagamentos. O ganho aqui costuma ser o maior de todos, e o custo é ter o grafo de dependências bem declarado. Se não estiver, esse é o momento de arrumar.

Paralelizar com shards

Suíte grande que não dá para cortar dá para dividir. O Vitest e o Playwright aceitam shard nativo:

strategy:
  matrix:
    shard: [1, 2, 3, 4]
steps:
  - run: bunx vitest run --shard=${{ matrix.shard }}/4

Quatro runners de 5 minutos entregam resposta bem antes que um runner de 20. O custo total em minutos fica parecido, mas o tempo até o feedback cai muito. E é o tempo até o feedback que trava o time.

Cache de verdade

Cache de dependências todo mundo tem. O que faz diferença é cache de resultado de tarefa: se o pacote @repo/utils não mudou, o resultado do teste dele de ontem continua válido. Remote cache do Turborepo ou do Nx resolve isso entre máquinas, inclusive entre o seu laptop e o runner.

E a qualidade, não cai?

Essa é a objeção que eu mais ouço. "Se você roda menos testes, vai deixar passar bug."

Depende de onde você coloca a régua. O que funciona é separar dois momentos:

• No PR: feedback rápido, só o afetado, falha cedo. O objetivo é responder em poucos minutos.
• Antes do merge ou na main: suíte completa, testes lentos, E2E pesado. Uma merge queue resolve bem isso, validando o resultado combinado e não cada branch isolada.

Assim você não troca segurança por velocidade. Você só muda quando paga cada custo. O PR fica rápido para o humano e para o agente iterarem, e a main continua protegida.

Outro ponto honesto: teste flaky ficou bem mais caro. Antes, um teste instável incomodava uma vez por dia. Com dez vezes mais execuções, ele incomoda dez vezes mais e ainda confunde o agente, que vai tentar "consertar" um código que não tinha problema. Eu já vi agente reescrever uma função inteira por causa de um timeout aleatório num teste E2E. Quarentena de teste flaky deixou de ser luxo.

Como medir se o seu CI já é o gargalo

Antes de sair otimizando, olha os números. Três perguntas bastam:

1. Quanto tempo leva, em média, do push até o resultado do CI? Se passa de 10 minutos, você tem um problema.
2. Quantas execuções por dia são canceladas ou substituídas por um push mais novo? Se for muitas, falta cancel-in-progress.
3. Qual porcentagem dos jobs roda em código que não foi tocado no PR? Em monorepo sem filtro, a resposta costuma assustar.

A API do GitHub dá tudo isso sem ferramenta extra:

gh run list --limit 100 --json conclusion,createdAt,updatedAt,headBranch

Joga isso numa planilha e você já tem um retrato melhor que muita reunião de "precisamos melhorar o CI".

Tem também o lado do bolso. Em plano gratuito, seja de GitHub Actions ou de deploy na Vercel, a cota acaba rápido quando cada push vira cinco jobs e três deploys de preview. Eu mesmo já precisei colocar filtro de pasta nos meus projetos porque o agente fazia push demais e comia o limite diário antes do almoço.

Minha opinião

O que eu mais gostei no texto da Linear é que ele não trata a IA como mágica. Ela acelerou uma parte do trabalho e expôs o resto. Isso é engenharia normal: você resolve um gargalo e o próximo aparece.

A parte que me incomoda nesse debate todo é o discurso de que "IA vai fazer o time entregar 10x mais". Vai escrever 10x mais, talvez. Entregar depende de validar, revisar e colocar em produção, e essas etapas não aceleraram sozinhas. Se o seu pipeline foi desenhado para um humano abrindo dois PRs por dia, ele não aguenta um time de agentes. Não adianta ter uma Ferrari se a garagem tem portão de catraca.

Minha recomendação é começar pelo barato: cancel-in-progress, filtro de afetados e quarentena de flaky. Isso resolve a maior parte do problema numa tarde. Shard, remote cache e merge queue vêm depois, quando os números pedirem.

Se quiser ver como eu organizo pipelines em monorepos reais, dá uma olhada nos meus projetos.

Meu agente escreve um PR em 4 minutos. O CI leva 25 para dizer se ele presta.

A Linear contou que, quando a IA entrou no fluxo do time, o gargalo deixou de ser escrever código e passou a ser validar.

Quando escrever código fica barato, verificar vira o trabalho caro. E CI lento deixa o agente lento também.

O que eu faria primeiro numa tarde: cancel-in-progress, rodar só o que foi afetado e colocar teste flaky em quarentena.

IA pode até fazer o time escrever 10x mais. Entregar 10x mais depende do pipeline aguentar.

Escrevi no blog como aplicar isso em qualquer monorepo, link nos comentários.

#DevOps #CICD #IA #Monorepo #EngenhariaDeSoftware