# Pull requests escritos por agentes tornam a CI uma dependência medida
> O desenvolvimento agêntico transforma a CI de uma verificação final em um ciclo de feedback. A Runnerhut substitui o runner por um rótulo runs-on. Meça o resultado.
- Source: https://jays.fyi/pt/blog/pull-requests-agentes-ci-dependencia
- Author: Jay Derinbogaz
- Published: 2026-08-25
- Language: pt
- Tags: tooling, pricing, ai
- Reading time: 6 min
- Machine translated: yes — original: https://jays.fyi/blog/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.
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](https://docs.github.com/en/billing/concepts/product-billing/github-actions#copilot-code-review-and-github-actions-minutes). 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](https://textcortex.com/). 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.
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 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](https://runnerhut.com/) é 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](https://runnerhut.com/docs). 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](https://runnerhut.com/pricing) 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](https://runnerhut.com/) 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](https://textcortex.com/), 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.
