O git como gargalo e o Scion da Anthropic

Pro git virar gargalo, um time precisa integrar mudança num volume que quase nenhuma empresa tem. A Anthropic chegou nesse ponto este ano e contou como resolveu num post de engenharia.

Em maio entravam por volta de 2.500 mudanças por dia no monorepo deles. Em setembro já passava de 30 mil. Só a CI faz uns 25 milhões de checkouts por dia, e a branch principal carrega quase 100 GB de histórico. Eles tentaram primeiro o que o git oferece pra cada job baixar só a parte do código que usa, e chegaram a manter várias centenas de espelhos internos. Com os merges acelerando, isso foi ficando difícil de operar.

O git foi desenhado pra quem trabalha desconectado, por isso cada cópia traz o histórico inteiro. Lá, quase tudo que acessa o repositório é agente ou job, online o tempo todo. Então fizeram o Scion, em que o servidor responde pelo histórico e faz os commits e merges, e o cliente só pede o que vai ler.

Resolve bem um problema que a maioria dos times não tem. Com algumas dezenas de PRs por semana, a cópia inteira nem chega a pesar. O risco pra esses times é sair copiando decisões que só fazem sentido com 30 mil mudanças por dia.

Uma delas é a fila de merge. No formato mais comum, ela ordena as mudanças e trava a branch principal enquanto os testes rodam. Com centenas de mudanças chegando nesse meio tempo, a Anthropic não conseguiu manter essa trava. Os testes foram pra depois do merge e antes do deploy, e quando duas mudanças entram em conflito, normalmente é o Claude que resolve.

Junto com isso vem a revisão. O time de sete pessoas que construiu o Scion ainda revisa toda mudança, só que pela intenção, sem ler linha por linha. E montaram simulações de toda interação não trivial de infraestrutura e controle de versão que já tinham encontrado.

Uma coisa segura a outra. Revisar só a intenção, sem teste por trás, acaba sendo confiar na descrição que o próprio agente escreveu no PR. E com dezenas de PRs por semana ainda dá tempo de ler linha por linha o que mexe em regra de negócio ou em dado.

Se o controle de versão começar a pesar num time médio, deve aparecer primeiro na CI, que baixa o código e roda os testes a cada mudança. Quando os jobs passam mais tempo baixando o repositório do que testando, ainda dá pra resolver no próprio git, com cada job baixando só as pastas que usa (o tal do sparse checkout). Lá isso deixou de bastar com 30 mil mudanças por dia. Com dezenas de PRs por semana sobra folga.

Por isso eu manteria a trava da fila de merge e os testes rodando antes de qualquer PR entrar, de pessoa ou de agente. Nesse ritmo quase nada chega enquanto os testes rodam, e a trava que a Anthropic teve que largar sai barata.

O post da Anthropic sobre o Scion: Redesigning source control.