Redesenhando o controle de código na Anthropic
A Anthropic construiu o “Scion”, um sistema de controle de código centralizado e customizado para substituir o git em seu monorepo em rápido crescimento e em suas frotas de agentes de programação, que agora geram dezenas de milhares de merges e dezenas de milhões de checkouts de código por dia. Comentadores comparam o design ao Perforce ou ao Subversion e debatem se o problema real é a escalabilidade do git, as escolhas de monorepo e fluxo de trabalho da Anthropic, ou o simples volume de rotatividade gerada por IA. O fio levanta questões mais amplas sobre desenvolvimento orientado por agentes: como revisar a intenção em vez de cada linha de código, se tal velocidade é sustentável ou sensata, e por que a Anthropic não está open-sourcing uma ferramenta treinada com tanto código externo.
Por que a Anthropic construiu o Scion
- O Git começou a falhar na escala da Anthropic: ~100 GB de histórico da branch principal, ~25 GB de cópia de trabalho, ~25 milhões de checkouts/dia para CI e agentes.
- Fazer clone ingenuamente por job implicaria ~600 PB/dia de tráfego; mesmo com cache e repack, há relatos de que a manutenção de repositórios Git se torna frágil.
- O monorepo é intencional: permite mudanças atômicas que atravessam várias áreas, ferramentas consistentes e fácil acesso para agentes, mas amplifica os problemas de escala.
Design e comparações
- O Scion é centralizado e sempre online: todos os commits/merges/rebases acontecem no servidor; os clientes buscam apenas os blobs necessários sob demanda.
- Histórico e conteúdo de arquivos são objetos imutáveis e endereçados por conteúdo, armazenados em um log + object store, com dados derivados calculados assincronamente.
- Muitos comentaristas dizem que isso “parece” Subversion, Perforce, ClearCase ou o Piper do Google / o Sapling da Meta, isto é, servidor central + working trees virtualizadas.
- Outros apontam ideias semelhantes no EdenFS, em sistemas de arquivos baseados em artefatos e em ferramentas baseadas em jj; alguns veem isso como um padrão inevitável para monorepos gigantes.
Escala, agentes e mudanças no fluxo de trabalho
- Os merges cresceram de ~2,5 mil/dia para >30 mil/dia, em grande parte impulsionados por agentes. Alguns veem isso como “gradient descent com código” ou exploração bruta.
- A semântica de CI/merge queue muda: não dá para travar o repositório globalmente, então mais coisas são feitas pós-merge e pré-deploy; conflitos semânticos concorrentes são esperados e corrigidos por agentes.
- O papel dos engenheiros humanos é descrito como escolher problemas, fazer trade-offs de arquitetura e dizer “não” aos agentes com frequência, depois revisar a intenção em vez de cada linha.
Preocupações com qualidade, segurança e manutenção
- Muitos se mostram desconfortáveis com 30 mil merges/dia e alta rotatividade: medo de código espaguete, jank e “AI slop” se acumulando mais rápido do que pode ser compreendido.
- Vários observam que, mesmo hoje, precisam revisar de perto código gerado por IA para evitar bugs sutis; duvidam que a Anthropic consiga realmente supervisionar tudo nessa velocidade.
- VCS centralizado e apenas online levanta preocupações sobre indisponibilidade, segurança e perda de fluxos offline; outros respondem que grandes organizações já vivem em setups sempre online e orientados por API.
Open source, generalidade e implicações mais amplas
- A Anthropic diz que o Scion é muito específico e divergente demais do git para ser open-sourced de forma útil; muitos leitores ficam frustrados com um post detalhado sem código.
- Alguns argumentam que a maioria das organizações deveria continuar com git ou comprar sistemas no estilo Perforce; só laboratórios de fronteira com enormes fleets de agentes e orçamentos de tokens precisam de ferramentas no estilo Scion.
- Debate mais amplo: LLMs tornam barato reinventar infraestrutura (VCS, CI, deploy, dashboards), mas não está claro quanto disso gera valor duradouro versus rotatividade e dívida técnica.