Onde o Código de Agentes Mora É Uma Decisão de Contenção

O GitHub cruzou a marca de um bilhão de commits em um único ano. Kyle Daigle registrou o número de 2025, e o ritmo não desacelerou: Matt Rickard estima hoje cerca de 275 milhões de commits por semana, uma cadência que projeta cerca de 14 bilhões por ano. O volume de CI conta a mesma história. O GitHub Actions rodava 500 milhões de minutos por semana em 2023 e dobrou para um bilhão de minutos por semana em 2025.

Essas curvas não dobraram porque humanos começaram a digitar mais rápido. Dobraram porque agentes começaram a fazer commit.

Esse único fato reformula uma pergunta que a maioria dos times ainda não fez em voz alta: onde o código gerado por agentes deveria, de fato, morar? A resposta reflexa é “no repositório, igual ao de todo mundo”. E é a resposta errada. O dado de volume é o que a torna errada.

O Substrato Foi Feito para Pessoas

Uma plataforma como o GitHub é, antes de tudo, um sistema social, e só depois um sistema de armazenamento. Stars, issues, threads de pull request, code review, um grafo de seguidores, um perfil que funciona como currículo. Esses recursos existem porque software era, até muito recentemente, um ato de colaboração humana. O repositório é onde a confiança se acumula: você lê quem tocou um arquivo, quando e por quê, e estende ou retém confiança a partir disso.

A observação direta de Rickard é que agentes não precisam de quase nada disso. Um agente não precisa de UI, de rastreador de issues, de feed social ou de stars. Ele precisa de uma camada Git durável e programática, em que possa escrever em velocidade de máquina e ler de volta com precisão. Os recursos que tornam uma plataforma humana valiosa são peso morto para um agente. Pior: viram superfície de ataque e risco de atribuição quando a saída de máquina passa por eles.

Despeje 275 milhões de commits por semana num substrato desenhado para colaboração em ritmo humano e os sinais de confiança deixam de significar algo. Um histórico de commits era um livro-razão de intenção humana. Encha-o de saída de agente e o livro-razão deixa de dizer quem decidiu o quê. O sinal que tornava o repositório valioso se dilui no próprio volume que o repositório agora carrega.

Misturar É o Erro de Governança

O problema real não é volume no abstrato. É a mistura. Quando commits de agente caem no mesmo branch, no mesmo histórico e na mesma fila de revisão dos commits humanos, três coisas quebram de uma vez.

A proveniência borra. Você deixa de conseguir responder “uma pessoa decidiu isto ou um modelo decidiu?” olhando o histórico, porque o histórico trata ambos como o mesmo tipo de evento. Atribuição por autor de commit é trivialmente falsificável e rotineiramente errada assim que agentes passam a commitar sob contas de serviço ou, pior, sob a identidade de um desenvolvedor.

O raio de impacto se expande. Um repositório humano carrega credenciais de produção, hooks de deploy, branches protegidos e a confiança implícita de tudo que está plugado nele. Um agente que escreve nesse repositório herda tudo isso por padrão. O sandbox que você construiu na camada de computação vale pouco se a saída do agente cai a um merge de distância da produção.

A revisão colapsa sob carga. A revisão humana foi calibrada para taxas humanas de commit. Ela não absorve uma mangueira de incêndio de máquina. Então os times fazem a coisa racional sob pressão: liberam os commits do agente sem olhar. O controle que deveria pegar a saída ruim vira carimbo automático justo quando o volume torna pegar erros mais difícil.

Nenhum desses é bug de ferramenta. São o resultado previsível de rodar saída de máquina por uma infraestrutura desenhada para confiança humana.

Um Substrato Separado, por Projeto

A correção é tratar “onde o código de agente mora” como uma decisão de contenção, definida no início, e não descoberta depois de um incidente. Três propriedades definem o substrato de que os agentes realmente precisam.

É durável e programático. Agentes precisam de Git de verdade, não de um diretório de rascunho que evapora. Precisam commitar, criar branch, fazer diff e ler histórico por API em velocidade de máquina, sem uma interface voltada a humanos no caminho. Os commits viram checkpoints do trabalho do agente, um registro granular do que mudou em cada etapa de raciocínio, que é exatamente a trilha de auditoria que você quer quando algo dá errado.

É efêmero e sob demanda. A unidade não é um repositório compartilhado de vida longa. É um repo isolado, criado para uma tarefa e destruído quando a tarefa fecha. Isolamento por tarefa significa que um agente descontrolado corrompe o próprio espaço de trabalho e nada além disso. Não há histórico compartilhado para envenenar, branch protegido para ameaçar, nem trabalho de vizinho para sobrescrever.

É escopado por credenciais de curta duração. O substrato do agente ganha identidade própria e tokens estreitos e expiráveis. Ele não alcança as deploy keys nem os segredos de produção do repo humano porque nunca os recebeu. A proveniência então é estrutural: código que veio de agente mora em infraestrutura escopada para agente, e a promoção para um repositório humano vira um evento explícito e revisável, não um merge silencioso.

É a mesma lógica que o stack de contenção aplica nas camadas de computação e de dados, estendida à camada que a maioria dos times esqueceu: o lugar onde o próprio código se acumula. Detalhamos a construção mais ampla em a infraestrutura de agentes que chegou em uma semana e o modelo de quatro andares no stack de contenção de agentes. Onde o código de agente mora é o andar embaixo de todos eles.

A Fronteira de Promoção

Separação não é um muro; é um portão. O código de agente não fica em quarentena para sempre. Ele conquista a entrada no repositório humano por uma fronteira definida: um ponto em que a saída é revisada, atribuída e assinada antes de se juntar ao histórico carregado de confiança.

Essa fronteira é onde a governança de fato mora. De um lado, saída de máquina em volume de máquina, efêmera e descartável. Do outro, histórico de propriedade humana, em que cada commit ainda carrega intenção. A membrana entre os dois é a superfície de controle. Quando a promoção é explícita, dá para auditá-la, limitar sua taxa e exigir assinatura humana em qualquer coisa rumo à produção. Quando a promoção é implícita, não dá, porque não existe fronteira para instrumentar.

Uma nota sobre a fonte. Rickard está construindo um produto exatamente nesse espaço, então leia o enquadramento de produto com esse interesse em mente. O dado de volume de commits é de terceiros e se sustenta independentemente de qualquer produto: a escala é real, e a escala é o argumento.

Faça Isto Agora

Escolha um repositório em que agentes já commitam. Responda duas perguntas. Primeira: dá para dizer, só pelo histórico, quais commits um modelo escreveu e quais uma pessoa escreveu? Se a resposta for “pelo campo de autor”, não é confiável, e você tem um déficit de proveniência. Segunda: o que está a um merge de distância da produção nesse repo, e a identidade do agente tem um caminho até lá? Se tem, seu raio de impacto inclui tudo que o agente consegue alcançar.

Se qualquer das respostas preocupa, o próximo passo não é mais disciplina de revisão. É um substrato separado: Git efêmero, programático e escopado por credencial para o trabalho de agentes, com uma fronteira de promoção explícita para os repositórios onde humanos ainda são donos do histórico. Decida onde o código de agente mora antes que o volume decida por você.

---

Fontes

• Matt Rickard. “Where should agent-generated code live?.” Maio de 2026.

A Victorino ajuda times a decidir onde o código de agentes mora, para que proveniência e raio de impacto sejam projetados, não descobertos: contato@victorino.com.br | www.victorino.com.br