Pull requests escritos por agentes tornam a CI uma dependência medida

/ Artigo

Tradução automática. Ler o original em inglês: Agent-written pull requests turn CI into a metered dependency →

Um agente pode escrever um patch enquanto você dorme. É essa a parte que todo mundo quer discutir. O patch ainda precisa de dependências instaladas, uma matriz de testes executada, containers construídos, artefatos armazenados e um check verde antes de tocar na branch que importa para você. Tudo isso é computação medida.

A conta de CI virou uma dependência da criação de software. Ela fica dentro do ciclo de feedback entre a mudança proposta por um agente e a próxima tentativa dele, onde um job lento significa um agente ocioso e um job caro significa que uma máquina só pode iterar até alguém notar a fatura.

Dois gráficos de barras mostram as contribuições públicas e de código aberto do GitHub subindo de cerca de 1 bilhão em 2024 para 1,128 bilhão em 2025, e os pull requests mesclados subindo de 402,7 milhões para 518,7 milhões.
Atividade pública do GitHub em 2024 e 2025. O GitHub Octoverse conta contribuições e pull requests mesclados, não linhas de código.

O GitHub já documenta o mecanismo em linguagem simples. Em repositórios privados, a revisão de código do Copilot consome minutos do GitHub Actions. Qualquer pessoa com acesso de escrita pode disparar uma Action, e o uso acima da franquia incluída é cobrado do dono do repositório. Um loop de agente apenas faz esse medidor rodar com mais frequência.

Isso importa para nós na TextCortex. Construímos e executamos workflows agênticos. Mais mudanças propostas significam mais execuções de teste, mais restaurações de cache e mais tentativas falhas que precisam ficar verdes. A velha imagem do CI como um pedágio final subestima a carga. Agora ele faz parte do chão de fábrica.

A afirmação de que agentes escrevem mais testes ainda não tem número que a comprove.

A geração de código pode criar uma grande quantidade de código de teste. Também pode criar um patch sem nenhum teste útil, ou um teste que afirma o erro da implementação. Não tenho um corpus público que prove que um agente médio produz mais testes que um humano, e não vou fabricar um para uma frase de marketing.

Dois gráficos de barras mostram a parcela de respondentes do Stack Overflow que usam ou planejam usar ferramentas de IA subindo de 76% em 2024 para 84% em 2025, enquanto a parcela que não confia na precisão da saída da IA subiu de 31% para 46%.
A pesquisa de 2025 do Stack Overflow mostra o uso de IA subindo junto com a desconfiança. É uma pesquisa com desenvolvedores, não uma medida de código gerado.

A conclusão operacional sobrevive sem essa estatística. Toda mudança proposta precisa de evidência antes do merge. Um agente que consegue propor mudanças rapidamente transforma duração, capacidade e custo de CI em restrições sobre a velocidade com que ele aprende. Isso já é motivo suficiente para se importar com runners.

Um gráfico de barras mostra um índice de velocidade de conclusão de tarefa de 100 para um grupo de controle e 155,8 para um grupo do GitHub Copilot. O estudo envolveu 95 programadores profissionais concluindo uma tarefa de servidor HTTP em JavaScript.
Um estudo controlado do GitHub Copilot relatou conclusão 55,8% mais rápida em uma tarefa. Isso é evidência de capacidade, não uma previsão para todo repositório.

A Runnerhut apresenta o caso de custo-benefício em números simples.

A Runnerhut é um serviço gerenciado de runners do GitHub Actions. Você autoriza o GitHub App dela, substitui o rótulo runs-on de um job e mantém as Actions, secrets e permissões que já estão no seu workflow. A documentação dela mostra a migração de uma linha. Cache gerenciado, builders Docker persistentes, analytics por workflow e computação hospedada na UE vêm junto.

A Runnerhut publica uma comparação de preços de 2 vCPU contra os runners hospedados no GitHub. Estes são os preços da tabela de tarifas dela em agosto de 2026. Windows e macOS custam metade da tarifa listada do GitHub-hosted. Linux x64 custa metade do preço e Linux arm64 é 36% mais barato.

Tipo de runner GitHub-hosted / min Runnerhut / min Você economiza
Linux x64 $0,0080 $0,0040 50%
Linux arm64 $0,0050 $0,0032 36%
Windows $0,0160 $0,0080 50%
macOS $0,0800 $0,0400 50%

A Runnerhut adiciona inicialização rápida, restauração de cache de 1 GB/s e builders Docker persistentes a essas tarifas mais baixas. A página do produto lista inicialização de runner em 3 segundos e pipelines duas vezes mais rápidos. Tarifas de runner mais baixas tornam cada minuto de CI mais barato. Builds mais rápidos consomem menos desses minutos em primeiro lugar.

A Runnerhut também cobra por segundo após um mínimo de um minuto, sem cobrança por cache, egress, tempo de fila ou concorrência. O plano gratuito inclui 3.000 minutos Linux por mês, o suficiente para mover um workflow real e observar os números antes de se comprometer com uma nova conta de CI.

A Runnerhut transforma CI mais rápido em uma conta menor.

O preço e a duração se multiplicam. Um runner com metade da tarifa por minuto que termina o pipeline na metade do tempo corta o gasto de computação por quatro. A Runnerhut otimiza a taxa de transferência do cache, o tempo de inicialização do runner e as camadas Docker junto com o preço por minuto, porque um pipeline verde importa mais do que um minuto lento e barato.

O serviço mantém o GitHub Actions familiar. Instale o GitHub App, troque o rótulo runs-on e mantenha suas actions, secrets e permissões exatamente como estão. O Runnerhut adiciona cache gerenciado, builders Docker persistentes, análise de custo por workflow e computação hospedada na UE sem forçar um produto de CI separado para dentro do time.

Seu loop de agentes precisa de um CI que acompanhe o ritmo.

Não há mistério na acumulação. Um pull request produzido por um agente precisa de uma execução de testes. Uma falha leva a outro patch e outra execução de testes. Uma matrix multiplica o trabalho. Um teste flaky adiciona uma nova execução. A conta acompanha o loop, e o tempo entre decisões úteis também.

Um CI confiável tem um trabalho chato: iniciar de forma previsível, restaurar o que o job precisa, executar o mesmo workflow de ontem, reportar o custo e sair do caminho. A migração de uma linha do Runnerhut mantém esse trabalho pequeno. Os times podem testá-lo sem reescrever o pipeline ou mover o processo de deploy para um novo plano de controle.

Na TextCortex, a conta falou por nós. No período de cobrança imediatamente anterior à migração dos nossos workflows de CI para o Runnerhut, pagamos cerca de €3.000 pelo GitHub Actions.

O Runnerhut reduziu drasticamente esse gasto para nós e tornou o pipeline de CI/CD mais rápido e mais fácil de operar. Os runners iniciam de forma previsível, os caches permanecem quentes e o time consegue ver quanto cada workflow custa, em vez de tratar a conta de CI como uma surpresa mensal.

O desenvolvimento agentic continuará aumentando o volume de código e testes que passam pelo CI. O Runnerhut dá a essa carga de trabalho um lar simples: o mesmo workflow do GitHub Actions, runners mais rápidos, taxas de computação menores e uma conta que continua legível à medida que o número de jobs cresce.

Foi por isso que migramos a TextCortex. O CI tinha se tornado infraestrutura de produção para nossos agentes. O Runnerhut o tornou mais barato e mais rápido sem transformar a migração em outro projeto de engenharia.