A Anthropic Abandonou o Lock da Fila de Merge. O Teste Foi para Depois do Merge.

Em maio de 2026, a Anthropic fazia em média cerca de 2.500 merges de código por dia. Em setembro, passava de 30.000 por dia. Os números são da própria empresa, publicados em um post de engenharia chamado Redesigning source control at Anthropic, e descrevem um crescimento de mais de dez vezes em poucos meses.

Boa parte do post trata de infraestrutura: os novos sistemas Scion e Antique e o custo de servir checkouts nessa escala. O trecho que importa para quem governa código escrito por agentes é mais curto. Ele admite que a Anthropic não conseguiu replicar um controle padrão da entrega de software nesse volume e descreve o que entrou no lugar.

O lock que não sobreviveu

A Anthropic chama o lock global do repositório na fila de merge de “the industry standard”, o padrão da indústria. Na nossa leitura, é esse lock que mantém a branch principal passando nos testes depois de cada mudança.

Os engenheiros fizeram uma pergunta direta, que parafraseamos: o que CI sequer significa quando centenas ou milhares de mudanças podem entrar enquanto os testes ainda estão rodando? A resposta foi que eles não conseguiram replicar de forma eficaz o lock global do repositório na fila de merge. Em vez disso, investiram em testes automatizados depois do merge e antes do deploy.

O post é franco sobre o custo. Mudanças concorrentes podem entrar em conflito, mas, segundo a empresa, o Claude costuma corrigir esses conflitos mais rápido do que um humano consegue identificá-los.

Nossa leitura da troca: a garantia sai do merge e vai para o deploy. A Anthropic testa depois do merge e antes do deploy, e diz que o Claude costuma corrigir os conflitos resultantes.

Vale registrar o que a fonte não diz. A Anthropic não informa dados de conflito nem de incidentes no modelo pós-merge. Trata-se de um fornecedor descrevendo o próprio sistema. A afirmação de que o Claude corrige conflitos mais rápido do que humanos os percebem aparece no post sem nenhum dado anexo.

A revisão foi para a intenção

A segunda mudança envolve pessoas e vem de como a Anthropic construiu o próprio sistema novo. Segundo o post, os membros do time continuam revisando todo pedido de mudança para o sistema, mas agora examinam a intenção da mudança em vez de ler cada linha de código.

Para mudanças nesse sistema, o que o revisor verifica saiu do diff e foi para o propósito.

O post descreve, à parte, suas ferramentas de revisão. O sistema de revisão consegue expressar restrições semânticas complexas sobre aprovações, o que permite separar coisas simples, como mudanças só em comentários, de mudanças lógicas sensíveis. Assim os revisores humanos se concentram nas mudanças de maior consequência.

Há uma segunda camada por baixo. A plataforma oferece controle de acesso detalhado nos repositórios e permite aplicar permissões a diretórios individuais, protegendo o código mais sensível sem perder os benefícios de um monorepo.

Juntando as duas coisas, na nossa leitura, o resultado é um sistema de roteamento: as regras de aprovação separam mudanças só em comentários de mudanças lógicas sensíveis, e as permissões de diretório protegem o código mais sensível.

Já escrevemos sobre o code review fazendo cinco trabalhos ao mesmo tempo e sobre por que substituí-lo acaba renomeando governança. O relato da Anthropic é útil porque nomeia os mecanismos.

O humano diz não

A frase mais reveladora fala do papel dos engenheiros na construção do sistema. Muitas vezes, segundo a Anthropic, o papel dos engenheiros era dizer “não” ao Claude. Os agentes às vezes violam restrições centrais do sistema para seguir um padrão que nunca deveria ter sido permitido.

Nossa leitura desse modo de falha: o agente segue um padrão que nunca deveria ter sido permitido, e uma restrição central quebra por causa disso. Quem impede é uma pessoa que conhece a restrição e diz não.

Uma segunda observação aponta na direção oposta. A revisão adversarial também pode ser míope, e engenheiros experientes precisaram afastar o Claude de over-engineering em partes do sistema, em resposta a preocupações hipotéticas. O papel humano cobre os dois lados: dizer não a mudanças que quebram restrições e afastar o Claude de over-engineering contra preocupações hipotéticas.

Nenhum dos dois trabalhos exige ler linha por linha. Os dois exigem saber para que o sistema serve. Na nossa leitura, a revisão de intenção é onde esse conhecimento é aplicado.

O que não se transfere

A Anthropic deixa explícito que sua infraestrutura não é um modelo a copiar. Segundo o post, o Scion não é um substituto adequado do git para uso geral, e os conceitos descritos só fazem sentido para monorepos realmente enormes, com dezenas de milhares de engenheiros ou enxames de agentes escrevendo código em grande quantidade.

Há uma segunda ressalva, sobre gasto de tokens: a empresa diz ser única porque sua capacidade de gastar tokens em uso interno supera em muito o que qualquer outro negócio gastaria de forma realista.

Os números de escala reforçam o ponto: algo na ordem de 25 milhões de checkouts de código por dia só para CI, o que, buscado de forma ingênua, passaria de 600 PB de tráfego git por dia. A Anthropic também relata que a infraestrutura do Scion é 200 vezes menor que a infraestrutura anterior de espelhamento git em CPU e memória, e o CI sozinho ganhou 25% de capacidade de CPU. A Anthropic diz que um time de sete pessoas construiu o Scion e o Antique e concluiu a migração em cinco meses.

Nada disso é motivo para adotar o Scion. A própria Anthropic diz isso.

O que se transfere

Nossa leitura é mais estreita que a história de infraestrutura. Quando o volume de agentes passa do que um portão serializado antes do merge aguenta, o controle muda de lugar e vai para dois pontos: o que um humano aprova e onde o teste roda. São decisões de roteamento, e decisões de roteamento custam pouco para copiar quando comparadas a um sistema de controle de versão.

As regras de roteamento do post podem ser enunciadas sem nenhuma ferramenta da Anthropic:

• Classifique as mudanças por consequência antes da revisão. Mudanças só em comentários podem ter uma aprovação mais leve que mudanças em lógica sensível.
• Proteja diretórios sensíveis com permissões próprias, para que o código de maior consequência sempre chegue a alguém que conhece suas restrições.
• Decida de forma explícita onde fica o seu portão de testes. Se ele for para depois do merge, o portão de deploy passa a ser a garantia e precisa ser tratado com esse peso.
• Escreva as invariantes que os revisores estão ali para defender, para que o “não” tenha uma referência.

O último item é inferência nossa a partir do trecho sobre dizer “não” ao Claude. A Anthropic não descreve uma lista escrita de invariantes. Descreve engenheiros que as conhecem. Na nossa leitura, onde esse conhecimento mora em poucas cabeças, a revisão de intenção no volume de agentes vai expor o quanto essa camada é fina.

Há também uma questão de tempo. O volume da Anthropic cresceu mais de dez vezes entre maio e setembro. Times que esperarem as filas de revisão colapsarem para desenhar regras de roteamento vão desenhá-las sob pressão. O argumento da capacidade de verificação vale aqui: o número de mudanças pode crescer mais rápido que os controles que as verificam.

Faça isto agora

Pegue as mudanças que entraram no mês passado e separe em duas pilhas: as que um revisor poderia aprovar só pela intenção e as que mexeram em lógica onde uma invariante poderia quebrar. Conte as duas. Se você não consegue separar, ainda não tem as regras semânticas de aprovação das quais a Anthropic depende, e esse é o primeiro item a construir.

Depois escolha seus três diretórios mais sensíveis e verifique quem pode aprovar mudanças neles hoje. Se a resposta for “qualquer pessoa com acesso de escrita”, permissões por diretório são o controle deste post que adotaríamos primeiro.

Por fim, descubra onde seus testes realmente barram mudanças. Se os agentes já empurram um volume maior do que uma fila serializada aguenta, decida de propósito se o portão de deploy carrega a garantia, antes que a fila decida por você.

---

Fontes

• Anthropic. “Redesigning source control at Anthropic.” Outubro de 2026.

A Victorino ajuda organizações de engenharia a desenhar roteamento de aprovações e portões de verificação para código escrito por agentes: contato@victorino.com.br | www.victorino.com.br