A descentralização do Git e seu modelo de clones completos foram otimizados para fluxos de trabalho humanos offline: cada desenvolvedor mantém uma cópia do repositório e calcula localmente o histórico, as diferenças e o blame. Na escala de agentes, essas características se tornam custos: o histórico completo aumenta muito as necessidades de armazenamento e transferência, a geração de packfiles e a manutenção de espelhos exigem trabalho pesado de CI e operações, e clones parciais criam casos extremos frágeis para consultas que dependem do histórico. Quando as mesclagens chegam a dezenas de milhares por dia, centralizar essas operações e disponibilizá-las por meio de APIs eficientes reduz o trabalho redundante e atende a consumidores programáticos, como tarefas de CI e sandboxes.

O Scion adota um modelo que prioriza o servidor: os conjuntos de alterações são criados no servidor, os blobs são imutáveis e endereçados por conteúdo, e os clientes solicitam apenas as árvores e os blobs de que precisam. Um ponto crucial é que o Scion separa os dados primários, semelhantes aos de commits, dos índices derivados. Blame, histórico de caminhos e ancestralidade são calculados por pipelines genéricos e recursivos de dados derivados, que podem ser executados de forma antecipada ou sob demanda. Essa separação modular permite escalar o sistema horizontalmente — os servidores funcionam como grandes caches que respondem a solicitações determinísticas de objetos — e viabiliza novos fluxos programáticos que dispensam a materialização de checkouts.

Centralizar as operações traz outros modos de falha: indisponibilidade de caches regionais, amplificação de leituras durante o aquecimento e necessidade de IAM e auditoria robustos no nível das APIs. A Anthropic mitigou esses riscos com uma hierarquia rigorosa de camadas, metas elevadas de acertos de cache e um modelo abrangente de controle de acesso. Segurança e conformidade também mudam: as políticas precisam ser aplicadas no servidor, a revisão adversarial passa a ser programática e a observabilidade deve revelar a intenção dos agentes e a procedência das revisões. Para manter a confiança em grande escala, as equipes precisam investir em barreiras automatizadas de políticas, simulações herméticas do comportamento dos agentes e registros robustos.

Adotar um VCS preparado para a escala de agentes significa repensar revisões, responsabilidades e CI. Os fluxos de revisão devem validar a intenção e as invariantes, em vez de inspecionar cada linha; os engenheiros deixam de ler todas as alterações e passam a auditar intenções e casos extremos. Pipelines de CI e de lançamento devem priorizar verificações orientadas por API e materialização esparsa para evitar clones dispendiosos. Do ponto de vista operacional, as equipes precisarão de novas funções: responsáveis por caches e índices, engenheiros de políticas no servidor e responsáveis pela confiabilidade dos pipelines de dados derivados. Treinamentos e guias práticos que definam os limites dos agentes e os modos de falha tornam-se essenciais.

Comece com uma abordagem híbrida: introduza APIs de metadados no servidor e serviços de dados derivados, mantendo o Git para os fluxos de trabalho dos desenvolvedores. Faça um projeto-piloto com sandboxes de agentes que usem checkouts esparsos e validem a correção dos dados derivados. Invista desde cedo na topologia de cache e no isolamento regional e crie interfaces automatizadas e simples de revisão para controlar as ações dos agentes. Por fim, refine as políticas e a experiência dos desenvolvedores — com árvores de trabalho materializadas ou checkouts virtualizados — para manter a produtividade dos fluxos humanos enquanto os agentes escalam. Acompanhe a latência das mesclagens, as taxas de acerto de cache e a aplicação das políticas como métricas prioritárias.