30 Mil Merges Por Dia: O Que A Anthropic Mudou No Merge Queue E Na Revisão De Código Para Acompanhar Agentes

Toda vez que alguém propõe aumentar o volume de código que um time entrega, a primeira coisa que eu tento imaginar é a fila de merge. Não o editor, não o modelo, a fila. É ali que o aumento de volume costuma doer primeiro: o pull request que espera o CI, o CI que espera o outro pull request, o rebase que invalida o teste que acabou de passar. Quando o número de mudanças dobra, a fila não dobra de tamanho, ela se comporta de um jeito pior do que isso.

Foi com essa pergunta na cabeça que li o texto da engenharia da Anthropic sobre a reconstrução do controle de versão interno, publicado em 13 de outubro e atualizado dois dias depois. O texto circulou bastante, e um digest que acompanho registrou 866 pontos no Hacker News. A manchete fácil seria "a Anthropic trocou o git". Não é o que me interessa, e, como vou mostrar, nem os autores querem que seja a leitura. O que me prendeu foram três decisões de processo que aparecem quase de passagem no meio de um texto sobre infraestrutura: abrir mão de uma fila de merge com trava global, mudar o que o revisor humano olha e aceitar que a rede de segurança passa a ser o teste, não a leitura.

Um aviso de método: não operei nada disso. Todo número abaixo é da Anthropic sobre a própria operação, dado do fornecedor sem medição independente, e o que escrevo é leitura e interpretação.

O caminho é este: os números e o que quebrou primeiro, o que entrou no lugar da fila global, como funciona a revisão por intenção, as pré-condições que fazem essa prática ser engenharia e não negligência, o que os próprios autores dizem que não se transfere e, por fim, o que um time pequeno pode aproveitar sem copiar a infraestrutura.

---

Os Números E O Que Quebrou Primeiro

Segundo a Anthropic, em maio de 2026 eram cerca de 2.500 mudanças de código mescladas por dia. Em setembro, mais de 30.000 por dia. Os autores dizem esperar que a curva continue. Cinco meses para um fator de doze, aproximadamente, e o texto afirma que os merges diários cresceram dez vezes enquanto sete pessoas construíam o sistema novo. Em outra publicação da empresa, a pesquisa sobre emprego interno de 16 de outubro, aparece que os commits por engenheiro estavam cerca de cinco vezes acima do nível de seis meses antes. Cito só de passagem: é o mesmo fenômeno visto de outro ângulo, mais gente (ou agentes) escrevendo mais, e todo o resto do pipeline precisando acompanhar.

O que quebrou primeiro, no relato, foi o git em si, e vale entender o mecanismo antes de qualquer julgamento. O histórico da branch principal chegou a quase 100 GB, e a cópia de trabalho comprimida passa de 25 GB. O CI faz cerca de 25 milhões de checkouts por dia. Quem faz a conta ingênua, cada checkout buscando o que precisa do servidor, chega a mais de 600 PB de tráfego git por dia, um número que não é operável por ninguém. Os atalhos clássicos ajudaram: clones rasos, sparse checkout, seeds pré-populados. Mas, no pico, a empresa mantinha várias centenas de espelhos git internos, cada vez mais difíceis de operar, com seeds cada vez mais defasados em relação à ponta do main.

Os autores apontam a raiz como um descompasso de projeto. O git foi desenhado para clientes distribuídos e frequentemente offline, cada um com o histórico inteiro. Os clientes da Anthropic são quase todos agentes e jobs sempre online. Um modelo que carrega o repositório inteiro para cada cliente faz sentido para quem trabalha num avião, e deixa de fazer sentido quando o cliente é um job de CI que vive a poucos milissegundos do servidor. Essa é a tese do Scion: clientes sempre online, servidor fazendo a maior parte do trabalho (histórico, blame, commits, merges, rebases), controle de versão exposto por APIs, componentes escaláveis na horizontal e cópias de trabalho opcionais e esparsas.

---

O Que A Anthropic Colocou No Lugar Da Fila Global

A decisão está numa frase curta do relato: a Anthropic não replicou uma trava global de repositório, porque a viu como inadequada na escala de agentes. Em vez disso, ela depende de testes automatizados depois do merge e antes do deploy. Vale ler com calma o que isso significa em termos de mecanismo.

Uma merge queue tradicional resolve um problema real: garantir que o que entra no main foi testado contra o main como ele estará no momento do merge. Ela serializa, ou quase, as mudanças, e o preço é a latência. Com poucas mudanças por hora, o preço é aceitável. Com dezenas de milhares por dia, a serialização vira o gargalo dominante, porque a fila é uma região crítica e o tempo de espera cresce rápido quando a taxa de chegada se aproxima da capacidade de processamento. Qualquer pessoa que já olhou um sistema de filas reconhece a curva.

O que a Anthropic faz é deslocar a garantia. Em vez de "nada entra no main sem ter sido testado contra o main exato", vale algo como "o main pode ficar momentaneamente inconsistente, mas nada chega a produção sem passar por teste". A integração acontece primeiro, a verificação vem logo depois, e o ponto de contenção passa a ser o deploy, não o merge. É uma troca explícita de garantia forte e cara por garantia mais fraca e barata, com a segunda barreira posicionada mais adiante.

Isso admite uma consequência que o texto reconhece: mudanças concorrentes podem conflitar. A resposta da empresa é que o Claude normalmente resolve conflitos mais rápido do que humanos conseguiriam sequer detectá-los. Repare na formulação, que é cuidadosa. Não é "conflitos não acontecem", é "o custo de resolver caiu tanto que não compensa pagar a fila para evitá-los". É uma afirmação da própria empresa sobre o próprio ambiente, e eu a trato como hipótese plausível, não como fato transferível. Em um repositório onde as mudanças são pequenas, bem delimitadas e cobertas por teste, um agente resolvendo conflito é razoável. Em um repositório onde o conflito é semântico, duas mudanças que compilam e passam nos testes individuais mas se contradizem no comportamento, quem decide é o teste de integração, e voltamos à qualidade da rede de segurança.

Aqui entra o ponto que li no post sobre agentes que erram com confiança: teste pós-merge só protege se for capaz de detectar. Um conjunto de testes que passa quando deveria falhar transforma a política "testamos depois" em "não testamos". A Anthropic descreve, de forma complementar, agentes "superfan" do Claude que monitoram componentes individuais e detectam anomalias sutis que alertas tradicionais perdem. Não há detalhe suficiente no texto para avaliar o quanto isso funciona, mas o desenho revela a preocupação: se você tira a trava, precisa de observação mais fina do outro lado.

---

Revisão Por Intenção E Aprovação Semântica

A segunda decisão é a que mais mexe com o dia a dia de quem lidera times. Segundo o relato, os revisores humanos não leem mais todas as linhas; revisam a intenção de cada mudança. Eu li a frase três vezes antes de seguir, porque ela se presta a duas leituras opostas: uma defensável e uma temerária. A defensável é que a atenção humana, que é o recurso escasso, deixa de ser gasta em checagem mecânica e vai para a pergunta que só uma pessoa responde: isso deveria existir, e deveria existir assim?

O mecanismo que sustenta essa leitura é o Antique, o sistema de revisão de código que a empresa construiu em paralelo ao Scion. Ele oferece regras de aprovação semântica, que separam mudanças triviais, como uma alteração que mexe só em comentário, de mudanças de lógica sensível. Pense numa regra de roteamento: o sistema classifica a mudança, e a classificação decide quem precisa olhar e com que profundidade. Uma mudança só de comentário pode passar com aprovação mínima. Uma que toca lógica sensível exige revisão humana de verdade. O humano deixa de ser um filtro uniforme e passa a ser um recurso alocado por risco.

Para tornar isso concreto, um cenário hipotético. Imagine um time que recebe, num dia, cem mudanças geradas por agentes. Quarenta mexem em documentação e comentários, trinta em testes, vinte em código de interface sem efeito colateral e dez em lógica de autorização ou de cobrança. Revisão linha a linha em tudo exige que alguém gaste a mesma atenção nas cem. Revisão por intenção com gate semântico concentra o olhar humano nas dez, e pergunta nas demais se a classificação foi correta. A economia só existe se a classificação for confiável, e esse é o ponto frágil do desenho: um classificador que erra para baixo, tratando como trivial algo sensível, produz o pior tipo de falha, a que passa sem que ninguém tenha olhado.

Já escrevi sobre como o code review muda quando o código gerado por IA vira maioria. O caso Anthropic é um ponto de chegada extremo, e o relato não afirma que a revisão linha a linha acabou; afirma que o humano não é obrigado a ela em toda mudança.

---

As Pré-Condições: Teste, Permissão E Rollback

Se o texto da Anthropic fosse apenas uma lista de decisões, eu teria parado na seção anterior. O que o torna útil para quem não opera em 30 mil merges por dia é olhar o que precisa existir antes de qualquer uma delas. A análise secundária que li, publicada pelo blog Redreamality em 19 de outubro, vai direto a esse ponto: a revisão por intenção só funciona se testes, permissões e rollback já existirem; sem eles, a prática não reduz a revisão, elimina a revisão. É uma fonte de terceiros, com uma tese própria, mas a lógica é difícil de refutar.

Comece pelos testes. Revisar a intenção sem ler o código pressupõe que o comportamento descrito na intenção está verificado por algo executável. Se o único elo entre "o que a mudança diz que faz" e "o que ela faz" é a leitura humana, tirar a leitura quebra o elo. Os testes automatizados depois do merge e antes do deploy, na descrição da Anthropic, são esse elo. A qualidade deles define o teto de segurança de todo o resto. Cobertura numérica não basta; o que importa é a capacidade de falhar quando o comportamento está errado, o mesmo problema da falha silenciosa que mencionei antes.

Depois, as permissões. O relato cita controle de acesso por repositório, permissões por diretório, simulação extensa, fuzzing e rate limiting. A função das permissões num mundo de revisão por intenção é limitar o raio de dano de uma mudança que passou sem leitura. Se um agente só pode alterar certos diretórios, a pior mudança possível é a pior mudança dentro daquele diretório, não no sistema inteiro. É o mesmo princípio de blast radius que costuma aparecer em engenharia de confiabilidade, aplicado ao momento da escrita e não só ao da execução.

Por fim, o rollback. Se o deploy é o ponto de contenção e o merge é livre, o que acontece quando algo ruim passa pelas duas barreiras? A resposta saudável é: desfaz-se rápido. Rollback barato e confiável é o que transforma "pode dar errado" em "o custo de dar errado é limitado". O catálogo de padrões operacionais de deploy que escrevi no início do mês tem como primeiro item justamente a atualização atômica com rollback, e eu não acho coincidência: é o tipo de capacidade que sustenta qualquer política de menos revisão prévia.

Pré-condição	Pergunta de diagnóstico	Se a resposta for "não"
Teste que detecta	Uma mudança errada de verdade falha o pipeline antes do deploy?	A revisão por intenção vira ausência de revisão
Permissão por escopo	Um agente consegue alterar áreas sensíveis sem passar por humano?	O raio de dano não tem limite
Rollback rápido	Desfazer uma mudança em produção leva minutos e é rotina?	Um erro raro vira incidente longo

---

O Que Os Próprios Autores Dizem Que Não Se Transfere

O trecho do texto que mais respeito é o das ressalvas, e elas são mais fortes do que o resumo de manchete sugere. Os autores dizem que o Scion não é um substituto geral do git. Só faz sentido para monorepos muito grandes ou para uso pesado de agentes. Reconhecem que a Anthropic gasta muito mais em tokens internos do que a maioria das empresas e que o ferramental é muito sob medida. E afirmam que oferecer o Scion publicamente exigiria migrar todo o ciclo de desenvolvimento, revisão, busca e CI, porque as peças dependem umas das outras.

A fonte secundária reforça: o volume da Anthropic não é referência de mercado. Concordo, e acrescento que o número de 30 mil merges por dia não deveria entrar em planejamento de capacidade de nenhuma empresa que não tenha uma frota de agentes própria. Para a maior parte dos times, o gargalo não é o git, é a revisão, a priorização e a triagem. Não por acaso, o texto da próxima quarta aborda o lado oposto do problema: o adiamento do Postgres 19 e a triagem de defeitos achados por revisão com LLM mostra um projeto em que a IA encontra mais defeitos do que o time consegue triar. É o espelho da história da Anthropic. Lá, o gargalo é a capacidade humana de absorver o que a máquina encontra; aqui, é o volume que a máquina produz e que o processo precisa absorver. Nos dois casos, o ponto central é que a capacidade humana é o recurso escasso e o processo precisa protegê-la.

Há ainda a crítica de terceiros. No Hacker News, um post em sunshowers.io argumentou que o Scion é fortemente inspirado pelo Mononoke, da Meta, e a discussão teve 232 pontos. Segundo a análise secundária que li, a Anthropic acrescentou atribuição depois da crítica. Cito só como registro de que o desenho não nasceu do zero, e que quem avalia essas decisões faz bem em olhar a literatura de sistemas parecidos, em vez de tomar o relato como invenção isolada. Só vi o título e o endereço desse post, então não vou além disso.

Por fim, a esperança declarada dos autores é a que eu levaria para casa: que plataformas e clientes git adotem as ideias do lado do servidor, como RPCs mais ricas e recursos sparse e shallow composáveis, sem abandonar o modelo do git. Eles próprios reconhecem que a comunidade git passou quase duas décadas escalando a plataforma. O recado não é "abandone o git"; é "o servidor pode fazer mais trabalho do que costuma fazer".

---

O Que Um Time Pequeno Pode Aprender Sem Copiar A Infraestrutura

A primeira é classificar mudanças por risco antes de decidir quanto revisar. Isso não exige um Antique. Um time pode começar com regras simples, expressas em arquivo de configuração da própria plataforma de código: mudanças que tocam apenas documentação ou testes seguem um caminho, mudanças em diretórios sensíveis (autenticação, cobrança, migrações) seguem outro, com revisor obrigatório. O benefício é duplo: a atenção humana vai para onde o risco está e o time passa a ter, por escrito, uma definição do que é "sensível". Imagine um time de oito pessoas em que a lista de diretórios sensíveis cabe numa tela; já seria um começo mais disciplinado do que a revisão uniforme que depende do humor do revisor.

A segunda é tornar o teste pós-merge e pré-deploy um contrato, com rollback automático. Antes de afrouxar a fila ou a revisão prévia, vale checar se uma falha no pipeline pós-merge realmente bloqueia o deploy e se reverter uma mudança é uma ação rotineira, não um evento. Se a resposta for "mais ou menos", o trabalho é construir isso antes de mexer em qualquer outra coisa. Um time que mantém a fila de merge e acelera o rollback ganha mais do que um que remove a fila e torce.

A terceira é o gate semântico como complemento, não como substituto. Para um time pequeno, o equivalente mais simples talvez seja pedir à ferramenta de revisão automática que classifique cada mudança e comente a intenção, deixando para o humano a decisão sobre as de maior risco, e amostrar periodicamente as classificadas como triviais para medir quanto o classificador erra. Sem essa amostragem, o time não sabe se o gate está calibrado. Essa auditoria barata é, na prática, o análogo do monitoramento fino que a Anthropic descreve, em escala compatível. Se o time usa agentes em paralelo com git worktrees, vale tratar a saída de cada agente como candidata a esse mesmo fluxo de classificação.

---

Conclusão

O que a Anthropic descreve é um conjunto coerente de trocas: menos garantia na entrada, mais garantia mais adiante; menos leitura integral, mais classificação por risco; menos fila, mais capacidade de desfazer. Cada troca só faz sentido porque existe uma infraestrutura de teste, permissão e rollback que a sustenta, e uma equipe de plataforma capaz de manter tudo isso. Isolar uma das decisões e aplicá-la sozinha é a maneira mais provável de errar.

Não sei dizer quanto desse arranjo resiste a um ambiente menos controlado. O relato é do fornecedor sobre a própria operação, os resultados não foram verificados por ninguém de fora, e o desenho tem pelo menos uma inspiração reconhecida em outro sistema. O que me parece sólido, independentemente do Scion, é a pergunta de processo: qual garantia cada etapa do meu pipeline compra, a que custo, e onde mais ela poderia ser comprada. Responder isso para a própria fila de merge já é um exercício útil, mesmo que a resposta seja manter tudo como está.

Voltando à pergunta com que abri o texto, o que acontece com a fila quando o volume dobra, minha leitura é que a resposta honesta depende menos do git e mais do que existe ao redor dele. Se há teste que detecta, permissão que limita e rollback que funciona, dá para discutir revisão por intenção. Se não há, o primeiro investimento não é uma ferramenta nova, é o piso. E, sobre o ritmo do assunto, acho prudente esperar mais relatos de quem opera em escala menor antes de tirar conclusões firmes.

Fontes:

• Anthropic Engineering — Redesigning source control at Anthropic
• Redreamality — Making the environment legible to agents
• Anthropic — How employment is changing at Anthropic
• sunshowers.io — Anthropic's Scion is heavily inspired by Mononoke