Resposta rápida: O Anthropic Scion é o sistema interno de controle de versão desenvolvido pela Anthropic após agentes de programação levarem o monorepo da empresa de cerca de 2.500 merges diários em maio de 2026 para mais de 30.000 por dia em setembro. O Scion processa commits, merges e rebases diretamente no servidor. Trata-se de uma ferramenta interna, e a própria Anthropic reforça que ele não foi pensado como um substituto geral para o Git.
O que a Anthropic fez com o Scion e por quê
Em 13 de outubro de 2026, a equipe de engenharia da Anthropic publicou o artigo Redesigning source control at Anthropic. A declaração inicial é contundente: “programar já não é mais o gargalo para construir sistemas ou fazer pesquisas”. O verdadeiro gargalo, segundo eles, é “toda a infraestrutura de desenvolvimento projetada para a escala humana: controle de versão, builds e CI”.
Os números deixam claro o motivo. Em maio de 2026, a empresa realizava cerca de 2.500 merges de alterações de código por dia. Em setembro, esse volume já ultrapassava os 30.000 — um salto de doze vezes em apenas quatro meses, que a Anthropic atribui diretamente ao trabalho dos agentes de programação.
O Git deu conta do recado na escala humana, mas cedeu na escala dos agentes. A Anthropic relata cerca de 25 milhões de checkouts de CI por dia, um histórico da branch principal próximo a 100 GB e centenas de mirrors internos de Git operando no horário de pico. Uma estratégia ingênua de fetch teria gerado mais de 600 PB de tráfego de Git diários.
Diante desse cenário, uma equipe de sete engenheiros desenvolveu o Scion, uma ferramenta de code review chamada Antique, um mecanismo de busca de código e um sistema de controle de acesso por diretório. Eles migraram o monorepo para fora do Git em cinco meses. A Anthropic utilizou inclusive o Claude Mythos Preview para reescrever o pipeline de ingestão do Git para o Scion — e a nova versão consumiu 20 vezes menos memória, rodando 4 vezes mais rápido.
Se a sua equipe já utiliza Claude Code, Codex ou qualquer outro agente de programação, este relato antecipa qual será o seu próximo gargalo. O Sharkly foi desenvolvido exatamente para resolver esse desafio: ele centraliza o trabalho, os resultados e a revisão dos agentes em Tarefas compartilhadas, em vez de deixá-los dispersos em vários terminais.
Como o Scion se diferencia do Git
O Git assume que todo clone é uma cópia completa e autossuficiente do histórico, capaz de operar offline. O Scion parte do princípio oposto: os clientes estão permanentemente online e realizam pouquíssimo processamento local.
| Git | Anthropic Scion | |
|---|---|---|
| Onde commits, merges e rebases são executados | Localmente, no seu computador | No servidor |
| Dados locais | Histórico completo | Cache limitado de objetos, checkout esparso ou virtualizado |
| Unidade de trabalho | Commit apontando para uma árvore (tree) | Changeset em um write-ahead log, listando arquivos modificados |
| Branches e refs | Fáceis de criar e incentivadas | Desencorajadas, exceto para a branch main e branches de release |
| Fetch | Packfiles | Por objeto (árvores e depois blobs), sem manutenção periódica do repositório |
| Trabalho offline | Sim | Não |
| Principais clientes | Pessoas | Agentes, CI e rotinas de pesquisa |
A arquitetura é dividida em três camadas: o scion-daemon em cada nó, o scion-cache em cada região e o servidor central autoritativo scion-server. A interface de linha de comando utilizada pelo cliente é o scn. As taxas de acerto de cache (cache hit rates) superam os 99% em todas as camadas.
O impacto prático é expressivo. A pegada de CPU e memória é 200 vezes menor em comparação com a arquitetura anterior baseada em mirrors de Git. Os checkouts de CI e de pesquisas agora levam segundos em vez de minutos, e o ambiente de CI liberou 25% de capacidade computacional de CPU.
Do que você abre mão com commits no servidor
Mover os commits para o servidor significa abdicar da principal característica que consagrou o Git: dispor do histórico local integral para trabalhar até mesmo dentro de um avião. A própria Anthropic reconhece isso abertamente. O Scion “não é, sob hipótese alguma, um substituto adequado para o Git em uso geral”, e empacotá-lo de forma a permitir o uso por outras organizações seria uma tarefa bastante complexa. A ferramenta não foi disponibilizada publicamente e a publicação não a trata como open source.
O modelo de concorrência também foge do habitual. A Anthropic não enfileira cada merge sob um bloqueio global. Alterações simultâneas podem sim entrar em conflito, e a equipe detecta essas divergências por meio de testes pós-merge e validações pré-deploy.
Git para agentes de IA: a lição para equipes sem o Scion
Você não terá acesso ao Scion — e nem precisa dele. O seu repositório não tem 100 GB e você não executa 25 milhões de checkouts diários. O maior valor desse artigo está em entender a mecânica do problema, que se repete em qualquer ordem de grandeza.
Quando os agentes passam a escrever o código, o gargalo se desloca para as etapas seguintes do fluxo: primeiro para a integração (merging), depois para a revisão humana. Tanto a análise do DevOps.com quanto o artigo do TechSpot retratam o Scion como uma resposta necessária de infraestrutura para acompanhar o ritmo dos agentes. Uma equipe de cinco engenheiros coordenando dez agentes enfrenta uma versão menor desse mesmo impasse.
Os sintomas são fáceis de identificar:
- Dois agentes editam o mesmo arquivo no mesmo período e você precisa resolver o conflito na mão.
- Os pull requests se acumulam com mais rapidez do que qualquer pessoa consegue ler.
- As filas de CI ficam mais lentas a cada semana, enquanto os agentes continuam gerando código em alta velocidade.
- Ninguém consegue rastrear com clareza qual agente fez determinada mudança nem o motivo dela.
- Uma branch aberta na terça-feira vira um pesadelo de conflitos ao tentar fazer rebase na sexta.
A Anthropic contornou os itens 1 e 3 construindo uma infraestrutura do zero. No entanto, é perfeitamente viável resolver todos os cinco pontos aprimorando processos e tirando melhor proveito dos recursos que o Git já oferece.
Conflitos de merge com agentes de programação: por que eles se multiplicam
Conflitos de merge crescem proporcionalmente à sobreposição de arquivos editados, não ao tamanho da equipe. Dez agentes atuando em um único objetivo amplo tocarão nos mesmos arquivos o tempo todo. Já dez agentes distribuídos em dez tarefas de escopo fechado raramente colidem. A granularidade de cada tarefa pesa muito mais do que o total de agentes trabalhando.
Branches que demoram a ser integradas agravam esse quadro. A cada hora em que uma branch permanece aberta, a main continua avançando. Com agentes, essa distância cresce ainda mais rápido, pois eles criam branches num ritmo muito superior ao ritmo humano de aprová-las e fechá-las. Nosso artigo sobre quantos dias de trabalho de agentes um dia de trabalho humano consegue revisar traz dados detalhados sobre essa assimetria.
O que você pode fazer hoje sem o Scion
Estes cinco hábitos atendem com folga à realidade da maioria das equipes — e nenhum deles exige adotar um novo sistema de controle de versão.
Dê a cada tarefa o seu próprio worktree
Um Git worktree é um segundo diretório de trabalho apontando para o mesmo repositório local. Usar um worktree por tarefa garante que dois agentes nunca gravem no mesmo diretório ao mesmo tempo.
git worktree add ../tasks/COIN-212 -b agent/COIN-212 origin/main
cd ../tasks/COIN-212
# run the agent here, commit, push, open a PR
git worktree remove ../tasks/COIN-212
Explicamos como configurar esse fluxo em Git worktrees para agentes de programação de IA e abordamos o gerenciamento e limpeza desses diretórios em como gerenciar worktrees sem dores de cabeça.
Mantenha as tarefas pequenas e com escopo bem definido
Descreva cada tarefa delimitando com precisão os arquivos ou módulos permitidos e a validação necessária para comprovar a conclusão. Uma tarefa que resulta em um diff conciso e fácil de revisar é mesclada com tranquilidade. Já um pedido genérico como “refatorar autenticação” certamente causará problemas.
Adote uma fila de merge na branch main
Uma fila de merge valida cada pull request aplicando-o sobre a versão mais recente da branch main somada a todas as alterações que já estão na fila, realizando o merge ordenadamente. A merge queue do GitHub oferece esse suporte em branches protegidas. É o equivalente para equipes ágeis da estratégia de testes pós-merge da Anthropic: você evita descobrir combinações incompatíveis depois que elas já entraram na branch principal.
Vincule a revisão à tarefa acompanhada de evidências
Um diff isolado não esclarece o que foi exatamente pedido ao agente nem os testes que ele executou. O processo de revisão ganha agilidade quando a solicitação original, os comandos rodados, a saída dos testes e as alterações de código ficam reunidos no mesmo contexto. Confira como revisar código gerado por IA com evidências no nível da tarefa e compreenda por que a revisão humana se torna o grande gargalo.
Exija aprovação humana antes do merge
Deixe os agentes encarregados de pesquisar, codificar, testar e reportar. Deixe as pessoas responsáveis por orientar a direção, validar passos críticos e aprovar o resultado final. Um agente pausado à espera de validação humana custa apenas alguns minutos. Já um agente que faz merge de alterações não revisadas diretamente na main pode custar um dia inteiro de retrabalho. Nosso guia sobre portões de aprovação (approval gates) para agentes de programação orienta onde inserir esses pontos de parada.
Onde o Sharkly entra
O Sharkly não pretende substituir o Git nem resolver conflitos de merge por conta própria. Seus agentes continuam enviando commits para o repositório por meio do seu provedor Git habitual. A função do Sharkly é organizar e dar visibilidade a todo o trabalho executado em torno desses commits.
Cada demanda executada por um agente é registrada como uma Tarefa (Task), contendo um Responsável (Assignee), status e histórico de execução. Os agentes rodam nas suas próprias máquinas (Computers), aproveitando as contas que você já possui no Claude Code, Codex ou outros ambientes. No modo temporário, cada Tarefa conta com um diretório isolado, e execuções ligadas a repositórios podem instanciar um worktree dedicado, impedindo que Tarefas simultâneas sobrescrevam os mesmos arquivos.
Ao concluir um trabalho, o agente pode deixar a Tarefa aguardando aprovação humana. Essa notificação é direcionada para a sua Inbox, onde o responsável abre o item, avalia o resultado em seu devido contexto e decide se aceita, solicita nova tentativa ou reatribui a tarefa. A execução da Tarefa e todo o diálogo subsequente permanecem vinculados à linha do tempo da demanda, tornando o próprio painel a sua fila de revisão.
Essa abordagem une as boas práticas de Git listadas acima a um ambiente unificado para pedidos, execuções, comprovações e decisões. Se você estiver avaliando alternativas, veja nosso panorama sobre as melhores ferramentas para gerenciar agentes de código paralelos.
Quem deve agir agora
Equipes que utilizam três ou mais agentes diariamente. Vocês estão prestes a bater de frente com o limite de merges. Implementem worktrees e uma fila de merge ainda esta semana.
Desenvolvedores solo que rodam agentes em paralelo. O seu gargalo principal é a revisão, não a integração do código. Reduza o escopo das tarefas até que qualquer diff possa ser inspecionado em menos de dez minutos.
Lideranças de plataforma e infraestrutura. Monitore de perto o tempo de espera nas filas de CI e a idade média dos PRs abertos. Conforme relatado pela Anthropic, o controle de versão e o CI ruíram antes de qualquer outro componente; é de se esperar que o mesmo aconteça no seu ecossistema. Estruturar agentes paralelos com worktrees isolados garantirá o tempo necessário para você se adaptar.
Conclusão
O Anthropic Scion é um forte indicativo de tendências futuras, não uma solução comercial pronta para ser adotada. O volume de merges da Anthropic aumentou doze vezes em quatro meses, o modelo primordialmente offline do Git mostrou seus limites para essa realidade e uma equipe enxuta de sete pessoas reconstruiu o controle de versão voltado para clientes que são, em sua maioria, agentes automatizados. A imensa maioria das equipes jamais precisará ir tão longe.
Contudo, qualquer equipe que adote agentes de código passará por essa mesma transformação: produzir código torna-se rápido e barato, enquanto revisar e integrar esse código passa a ser a etapa crítica. Mantenha as tarefas pequenas e isoladas, organize os merges em fila e exija revisões com base em evidências concretas.
Para centralizar todo esse processo de revisão em um só lugar, conecte uma máquina ao Sharkly, configure um Agente e atribua a ele uma Tarefa simples e de baixo risco. Acompanhe a entrega do resultado e avalie o ganho na prática.
Perguntas frequentes
O que é o Anthropic Scion?
O Scion é o sistema interno de controle de versão da Anthropic, criado para substituir o Git no monorepo da organização em 2026. A execução de commits, merges e rebases ocorre no servidor, enquanto os clientes mantêm somente um cache local delimitado.
Por que a Anthropic substituiu o Git?
O uso massivo de agentes de programação elevou a taxa diária de merges de cerca de 2.500 em maio de 2026 para mais de 30.000 em setembro. A infraestrutura de mirrors do Git, os checkouts e o fluxo de CI não sustentaram esse volume, transformando o controle de versão no gargalo central da engenharia.
O Scion é open source ou está acessível para uso externo?
Não há versão pública disponível. A Anthropic ressalta que o Scion não foi concebido como um substituto genérico para o Git e que adaptá-lo para outras empresas seria inviável. Os princípios de arquitetura foram compartilhados para que a comunidade possa aplicar ideias similares em seus próprios fluxos de Git.
Como reduzir conflitos de merge causados por agentes de programação?
Atribua um worktree exclusivo para cada tarefa, delimite o escopo para caber em um diff rápido de revisar, faça merges com frequência e posicione uma fila de merge na branch principal. Conflitos decorrem de arquivos compartilhados simultaneamente; portanto, o escopo da tarefa é muito mais decisivo do que a quantidade de agentes operando.
Equipes pequenas precisam de um novo sistema de controle de versão?
Praticamente nunca. Os gargalos da Anthropic foram causados por um repositório com 100 GB de histórico e 25 milhões de checkouts por dia. Em escalas normais, a combinação de worktrees, filas de merge e revisões orientadas a evidências absorve a demanda com tranquilidade.
