GitHub vai virar gargalo: o que eu aprendi cercando agentes de IA com um CI de 14 estágios
O Uncle Bob e o criador do Rails dizem que não leem mais código. Pra mim faz sentido, e eu faço isso em 19 dos meus mais de 300 microsserviços. O que quase ninguém conta é o preço: o CI que cerca o agente cresce, sai de 20 minutos pra 3 ou 4 horas, e o gargalo passa a ser o GitHub e a infraestrutura.
🎧 PREFERE OUVIR? · 21 min · Podcast Em Produção
Este artigo também é um episódio do podcast Josimar JMV | Em Produção — o mesmo vídeo, só o áudio, normalizado pra fone.
Gravei esses 20 minutos sem corte, em setembro de 2026, e publiquei no canal @josimarjmv em 4 de outubro. Assista e leia junto. Aqui embaixo eu conto a mesma coisa por escrito e ponho o que eu fui conferir depois: o anúncio de preço do GitHub Actions, a postagem do Uncle Bob, a keynote da Rails World 2026 e os casos do Redis e da Bitnami.
dá pra parar de ler o código que a IA escreve, desde que você cerque o agente com guardrails no CI. Eu faço isso em 19 dos meus mais de 300 microsserviços, com pipeline de até 14 estágios de teste. O preço aparece em outro lugar: o CI que durava 20 ou 30 minutos pode passar a durar 3 ou 4 horas, e aí o gargalo deixa de ser o dev e vira o GitHub e a infraestrutura. Em dezembro de 2025 o GitHub tentou cobrar o Actions por minuto e adiou. Eu acho que essa cobrança volta, e por isso eu rodo GitLab próprio, com quantos runners eu precisar.
De onde eu falo
Vou dar minha carteirada antes. Eu tenho infraestrutura própria e equipe de desenvolvimento há muitos anos. Eu pago a conta e ponho a mão na massa: desenvolvo, cuido de infraestrutura, de back, de front.
Então o que vem aqui não é resumo de notícia. É o que faz sentido pra mim, que tenho mais de 300 microsserviços rodando, cada um com o seu pipeline, e preciso que isso continue de pé no quinto dia útil.
O Uncle Bob e o criador do Rails pararam de ler código, e pra mim faz sentido
A pauta veio de um dev nosso, o Paçoca. Ele me mandou a história de que o criador do Ruby on Rails e o Uncle Bob, o do Clean Code, não escrevem nem leem mais código, exceto em casos específicos. Fui atrás.
O Uncle Bob escreveu em julho de 2026 que a estratégia dele hoje é não ler nenhum código escrito pelos agentes, e que no lugar disso ele cerca os agentes de restrição. A frase virou discussão no Hacker News. O criador do Rails, o DHH, abriu a Rails World 2026 em 23 de setembro, e a keynote correu o mundo como o anúncio de que ele parou de escrever código à mão. Eu fui ver a keynote esperando Rails e quase não tinha Rails. No caminho caí num texto do Akita em cima do Clean Code do Uncle Bob, o Clean Code pra Agentes de IA.
Isso bateu numa questão minha. Meses atrás eu falei que eu não estava mais conferindo todas as linhas que a inteligência artificial escreve dentro do meu pipeline de desenvolvimento autônomo, e que eu estava me cercando de teste end-to-end. Óbvio que precisa dos outros também: teste unitário, teste de regressão, os guardrails todos.
Até aqui você já ouviu isso em vários canais. O que eu quase não vi ninguém discutir é a consequência: pra deixar o agente trabalhar sozinho, o seu CI fica gigante. E aí o GitHub vira gargalo.
19 de mais de 300: por que não é copiar e colar
Em setembro de 2026 eu estou com apenas 19 desses serviços rodando de forma autônoma. Por quê? Porque dá o maior trabalho fazer o que precisa ser feito em nível de produção.
Tem gente que diz que é só copiar e colar o pipeline de um serviço pro outro. Não é. Quem diz isso não sabe do que está falando. Cada vez que eu monto um pipeline e os guardrails pra um sistema funcionar sozinho, dá um trampo danado. É aí que entra a gente, ser humano.
E esses 19 não estão perfeitos. Eu vou melhorando cada um ao longo do tempo, pra ele não tomar o meu tempo. Contei como foi o primeiro em substituí um dev júnior por IA no meu pipeline.
Sem guardrail eu volto pra frente da tela
Do fim do ano passado pra este eu toquei uns 15, 20 dias insanos, com quatro, cinco, seis projetos em paralelo. Funcionou. E eu virei um gargalo gigante, porque era eu na frente da tela o tempo todo.
Aí eu olhei e falei: funciona, mas agora eu preciso automatizar isso, senão eu não aproveito a magia da IA. E a magia é uma só: ela trabalha 24x7. Quando encontra alguma dependência que envolve dinheiro ou regra de negócio, ela chama o humano pra conversa. Correção de bug e melhoria básica, a ideia é que rode sozinha.
Só que como ela vai pôr alguma coisa em produção sozinha sem guardrail? Nos outros projetos, os que ainda não têm essa cerca, eu sou escravo da IA: fico eu no computador, a IA vai fazendo e eu vou testando, arquitetando e desembolando. Assim eu não escalo. Já escrevi sobre esse aperto em QA virou gargalo: a IA escreve mais rápido que eu testo.
O CI virou o lugar onde a regra de negócio é cobrada
A matriz de teste que a gente tinha era conhecida: teste unitário, você desenhava a regra de negócio, rodava o end-to-end. Isso continua essencial. Só que hoje não é só isso.
Você tem um monte de regra de negócio que colocou no CLAUDE.md, nas tools, nas skills do agente, e precisa garantir que nada daquilo passe pra frente quebrado. Quem garante? O CI. Então é no pipeline que você põe todas as validações. E esse trabalho você faz quase manualmente: você não escreve o código, mas confere se está certo cada vez que o pipeline roda.
Agora imagina um projeto com tudo isto pra validar:
- back e front separados;
- infraestrutura e banco de dados;
- cache de CDN e URL dinâmica;
- ambiente de staging, sandbox e produção.
Eu tenho pipeline com 14 estágios de teste, pra garantir que não passa nada quebrado. E quando passa alguma coisa quebrada, eu vou lá e faço mais um.
| O que mudou | Antes do agente autônomo | Com o agente trabalhando sozinho |
|---|---|---|
| Quem lê o código | Eu ou o time, linha por linha | Ninguém lê tudo. O CI cobra o resultado. |
| Onde mora a regra de negócio | Na cabeça do time e no teste | No CLAUDE.md, nas tools e nas skills, e validada no CI |
| Tamanho do pipeline | Unitário e end-to-end | Até 14 estágios, e cresce a cada erro que escapa |
| Duração do CI | 20 a 30 minutos | Pode chegar a 3 ou 4 horas |
| Onde está o gargalo | Em mim, na frente da tela | No runner e na infraestrutura |
Teste não mockado e o CI de 3, 4 horas
O seu CI que durava 20, 30 minutos pode começar a durar 3 horas, 4 horas? Pode. Depende da quantidade de teste, de integração, de end-to-end e de integração externa.
E tem uma escolha minha que pesa nisso: eu não gosto de teste mockado pra produção. Teste unitário mockando banco de dados roda rápido, tudo bem. Mas em alguns ambientes eu tenho teste não mockado: cria usuário, faz o fluxo completo, volta e deleta. Quantas horas se gasta num negócio desses?
A gente tem mapeamento de centenas de testes por job. Pega a plataforma EAD que eu tenho. Um job garante a área do aluno: todas as possibilidades de login, todas as de emissão de certificado, todas as de assistir aula, todas as de baixar arquivo, todas as travas de segurança pra não baixar vídeo. Aí já estamos falando de mais de uma hora rodando, só pra validar isso.
Um pipeline de 3, 4 horas quer dizer que pra subir cada coisa eu demoro 3, 4 horas. Você tem que ter isso em mente. Quando você é júnior e tem um projetinho só, você quer é pagar o boleto do mês, e está tudo bem. Quando o produto cresce, e a ideia de montar um SaaS é que ele cresça, você entende que um CI assim prejudica demais a operação.
Tem como melhorar. Um dev aqui estava com o CI lentaço num projeto. Melhorou bastante e ainda demora muito. A gente vai escovando bit, otimizando cada coisinha pra ele ficar mais rápido, sem abrir mão do que tem que ser testado.
O GitHub tentou cobrar o Actions em dezembro
Agora o meu stress com o GitHub. Em dezembro de 2025 ele tentou cobrar o Actions. Fui conferir o anúncio pra te dar o número certo, porque na gravação eu falei de cabeça.
O comunicado do GitHub criava uma cobrança de plataforma de US$ 0,002 por minuto para todos os workflows do Actions, nos runners hospedados por ele e nos self-hosted. No self-hosted ela começaria em 1º de março de 2026. Repositório público e GitHub Enterprise Server ficavam de fora. No mesmo pacote, o runner hospedado ficou até 39% mais barato a partir de 1º de janeiro de 2026.
A comunidade reagiu e ele recuou. O texto que está no ar hoje diz que a mudança de cobrança do self-hosted foi adiada pra reavaliar a abordagem. Adiada. Não cancelada.
E eu entendo o lado dele. Infraestrutura é cara. Runner é caro. Eu te digo porque eu tenho infraestrutura. Cada projeto tem uma imagem diferente, uma tecnologia diferente pra rodar. Tem runner de Mac pra quem desenvolve mobile, tem runner de Linux, cada um com a sua imagem base. É um preço real, que alguém está pagando pra você usar o GitHub de graça.
Nota de apuração: os números de volume
Na gravação eu falo de deploy saindo de centenas de milhões pra bilhões. Esse número eu disse de memória e não achei na fonte, então não vou sustentar. O que o próprio GitHub publicou é isto: a plataforma rodava cerca de 23 milhões de jobs por dia no começo de 2024 e a arquitetura nova aguenta 71 milhões por dia, e em 2025 os projetos públicos usaram 11,5 bilhões de minutos de Actions de graça. A ordem de grandeza é a que importa: é muito hardware. Haja data center.
Também falei em cobrança por execução. O anúncio era por minuto.
Eu acho que essa cobrança volta
Pode anotar aí. É opinião minha, não informação de bastidor: em algum momento o GitHub vai pôr um plano de cobrança no Actions. Alguém precisa pagar essa conta. O open source público talvez continue de graça. O resto, eu acho que não.
E vai ser do jeito que a Meta fez no WhatsApp: uma cobrançazinha de leve, marota. Pra ela são bilhões a mais. Pra você o valor não é grande o bastante pra abandonar a plataforma. Você paga contrariado, mas paga. Eu refiz essa conta em Meta vai cobrar mensagem no WhatsApp.
O valor pode ser pequeno. Mas na hora em que você tiver muitos pipelines e as suas IAs trabalhando 24 horas por dia fazendo deploy, você vai olhar a fatura e falar: ixe, tá caro isso aqui. Fora que o GitHub anda caindo com uma frequência grande, e eu já contei isso em GitHub caiu de novo: é a terceira vez.
Open source que vira pago: Redis e Bitnami
Esse filme eu já vi. A tecnologia começa open source, cresce, vira enterprise, a galera surta e migra. Uma hora, financeiramente, a coisa se torna inviável pra quem banca.
O Redis é o caso que me vem primeiro. Mudou a licença, e em 28 de março de 2024 a Linux Foundation anunciou o Valkey, que continua o desenvolvimento a partir do Redis 7.2.4 com licença BSD.
A Bitnami é o outro. Ela tinha um monte de imagem que a gente usava, formatadinha pra cluster de banco de dados, pra WordPress, pra um monte de coisa. De repente saiu do repositório. O aviso da própria Bitnami, hoje da Broadcom, é de agosto de 2025: o catálogo público foi arquivado num repositório legado sem suporte, a remoção ficou pra 29 de setembro, e pra ter o catálogo completo a recomendação passou a ser assinatura comercial.
Por isso eu não monto produção em cima do que eu não controlo. O raciocínio inteiro está em por que eu não uso GitHub, Supabase ou Firebase em produção.
Migrar é um parto
Aí você me diz: Josimar, eu tenho 14 estágios num projeto. Pois é. Se o GitHub cobrar e você resolver sair, você vai ter que transformar o seu Actions inteiro na linguagem do CI do GitLab, ou do Bitbucket, ou de onde for.
A IA acelera muito essa conversão. Ainda assim você tem que testar o CI, e isso toma o maior tempo. Aqui entra experiência de vida: migrar é um parto. Qualquer migração em produção. De banco, de storage, de fornecedor.
Migração é o que todo cliente evita. É por isso, aliás, que é difícil pegar cliente quando você monta um SaaS: o cara só migra se não tiver jeito. Então a pergunta fica com você. Se o GitHub começar a cobrar, você migra ou continua lá, com ele caindo?
O novo gargalo é a infraestrutura
Juntando tudo: o agente autônomo pede um CI enorme, o CI enorme pede runner, e runner é infraestrutura. A infraestrutura é o gargalo. O GitHub ou o GitLab viram o gargalo.
Você tem dois caminhos. Ou fica preso no GitHub de um jeito que dá preguiça de sair, ou aprende infraestrutura e domina esse negócio pra ter o seu ambiente.
Eu vejo comentário no canal dizendo que, se você não vai construir a nova Amazon, não precisa de infraestrutura própria. Sabe nada. E não, a saída que eu defendo não é o runner self-hosted do GitHub. Eu jamais colocaria um runner do GitHub dentro de um servidor meu. Nunca. Não vou abrir essa discussão de segurança agora, mas no meu sistema ele não entra.
O que eu uso é GitLab próprio, instalado e funcionando na minha infraestrutura, sem cobrança externa e sem limitação de terceiro, com quantos runners eu precisar. Ah, mas é difícil instalar. Lógico que é. Runner é runner: é imagem, instalou, botou, rodou. O que dá trabalho é o resto, backup, performance, uma série de coisas que só quem opera isso todo dia conhece. Contei o caminho de volta pra casa em migrei da nuvem pro on-premise.
Essa parte, de pôr um SaaS em produção com pipeline e desenvolvimento autônomo, é um pedaço do que eu ensino na Imersão de SaaS em Produção. Formato, data e condição valem o que está na página, não o que eu falei numa gravação.
O trabalho agora é validar, monitorar e ajustar
A gente vai montar um guardrail gigantesco de teste pro agente desenvolver sozinho. E a nossa leitura de código passa a ser baseada em erro.
É igual atendimento. O colaborador fez um atendimento errado, a gente dá o feedback e põe uma trava pra aquilo não acontecer de novo. Com o chatbot é a mesma coisa, e é o segredo de ter um chatbot que presta. Com a IA de desenvolvimento também. Vai acontecer alguma coisa? Inevitavelmente. A gente olha e fecha a brecha.
Se eu não deixar isso acontecer, a tecnologia não evolui e eu não produzo 10, 20, 100 vezes mais, que é a ideia de trabalhar com inteligência artificial. O objetivo não é ser escravo da IA.
Cuidado com o GitHub. É gargalo.
Discorda? Concorda? Tem um caso parecido? Aqui não tem caixa de comentário de propósito: segunda-feira, ao meio-dia, eu faço live no canal e a gente conversa sobre isso ao vivo — sem corte, como sempre.
Ver as lives no canal @josimarjmv →Perguntas frequentes
Dá pra parar de ler o código que a IA escreve?
Dá, desde que você troque a leitura por cerca. Eu parei de conferir todas as linhas dentro do meu pipeline de desenvolvimento autônomo, e no lugar pus teste end-to-end, teste unitário, teste de regressão e validação de regra de negócio no CI. Sem isso, não ler código é só torcer pra dar certo. E o guardrail não nasce pronto: cada vez que passa alguma coisa quebrada, eu vou lá e faço mais um estágio.
Quantos serviços seus já rodam com agente autônomo?
Em setembro de 2026, 19 de mais de 300 microsserviços. Parece pouco, e é de propósito. Dá o maior trabalho montar o pipeline e os guardrails pra um serviço rodar sozinho em nível de produção. Não é copiar e colar de um serviço pro outro. Nos demais projetos sou eu na frente do computador, testando e arquitetando enquanto a IA escreve.
O que entra num pipeline de 14 estágios de teste?
Além do teste unitário e do end-to-end, entram as validações das regras de negócio que eu escrevi no CLAUDE.md, nas tools e nas skills do agente. Quem garante que aquilo não passa pra frente é o CI. Num projeto com back e front separados, infraestrutura, banco de dados, cache de CDN, URL dinâmica e ambientes de staging, sandbox e produção, cada camada pede a sua validação. Eu tenho pipeline com 14 estágios, e eles não estão perfeitos: eu vou melhorando com o tempo.
Por que o CI passa de 20 minutos pra 3 ou 4 horas?
Pela quantidade de teste, de integração e de end-to-end, e porque eu não gosto de teste mockado pra produção. Em alguns ambientes o teste cria usuário, percorre o fluxo completo, volta e deleta. Só o job da área do aluno da minha plataforma EAD cobre todas as possibilidades de login, de emissão de certificado, de assistir aula, de baixar arquivo e as travas de segurança. Isso sozinho já passa de uma hora rodando.
O GitHub cobra pelo GitHub Actions em runner próprio?
Em 9 de outubro de 2026, não. Em dezembro de 2025 o GitHub anunciou uma cobrança de US$ 0,002 por minuto que alcançaria o runner self-hosted a partir de 1º de março de 2026, e depois adiou, dizendo que ia reavaliar a abordagem. Adiar não é cancelar. A minha aposta é que em algum momento a cobrança volta, porque alguém precisa pagar essa infraestrutura.
Vale a pena ter GitLab próprio em vez de depender do GitHub?
Pra mim vale, e é o que eu uso. Com o GitLab instalado na minha infraestrutura eu ponho quantos runners eu precisar, sem cobrança externa e sem limite de terceiro em cima do meu CI. O preço é operar: instalar, ter backup, cuidar de performance. É difícil, sim. Quem tem um projeto só e quer pagar o primeiro boleto do mês pode ficar onde está. Quando o produto cresce e a IA passa a fazer deploy 24 horas por dia, a conta muda.
Migrar o GitHub Actions pro CI do GitLab é simples?
Não. Você tem que transformar o seu Actions inteiro na linguagem do CI de destino. A IA acelera muito a conversão, mas você ainda precisa testar o CI estágio por estágio, e isso toma tempo. Migração em produção é um parto, seja de banco, de storage ou de fornecedor. Por isso eu prefiro decidir onde o pipeline mora antes de ele ter 14 estágios.
Baseado na gravação do canal @josimarjmv publicada em 04/10/2026 (20min38s), com transcrição própria das legendas do próprio vídeo.
O que veio da gravação e o que é apuração minha, com as fontes
Da gravação: a sugestão de pauta do dev da casa; eu ter parado de conferir todas as linhas dentro do pipeline de desenvolvimento autônomo; os mais de 300 microsserviços e os 19 autônomos em setembro de 2026; os 15, 20 dias com vários projetos em paralelo em que eu virei gargalo; as regras do CLAUDE.md, das tools e das skills validadas no CI; os pipelines com 14 estágios; a preferência por teste não mockado e o exemplo da área do aluno da plataforma EAD; o CI de 20, 30 minutos que pode ir a 3, 4 horas; a recusa a pôr runner do GitHub em servidor meu; o GitLab próprio; e a aposta de que o GitHub volta a cobrar o Actions, que é opinião minha. As durações de CI e o número de estágios foram ditos de cabeça.
Apuração minha (09/10/2026): o valor de US$ 0,002 por minuto, o alcance em runners hospedados e self-hosted, o início em 1º de março de 2026, a exclusão de repositório público e GitHub Enterprise Server, a redução de até 39% no runner hospedado em 1º de janeiro de 2026, o adiamento e os números de 23 milhões e 71 milhões de jobs por dia e 11,5 bilhões de minutos estão no comunicado do GitHub, de dezembro de 2025. Na gravação eu falo em cobrança por execução e cito de memória um salto de centenas de milhões pra bilhões; o anúncio é por minuto e eu não encontrei esse salto na fonte. A postagem do Uncle Bob, de julho de 2026, eu li pela discussão no Hacker News, que traz a frase e o link pra ela. A data e o palestrante da abertura da Rails World 2026 estão na página oficial do evento, e a gravação é a keynote publicada pelo canal do Ruby on Rails; que ela foi recebida como o fim do código escrito à mão eu tirei da repercussão, não de uma transcrição. O texto do Akita que eu linko é o Clean Code pra Agentes de IA, de 20/04/2026; na gravação eu não digo o título do que eu li. O Valkey e a base no Redis 7.2.4 estão no anúncio da Linux Foundation, de 28/03/2024. O arquivamento do catálogo público da Bitnami, o prazo de 29 de setembro e a recomendação de assinatura comercial estão no aviso publicado na comunidade da Broadcom em 18/08/2025. Deixei de fora um vazamento de credenciais que eu menciono de passagem, porque não conferi o número.