Anthropic cria seu próprio sistema de controle de versão

Ver no idioma original →

Autoria: Compilado do Código Fonte TV [OFICIAL] · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: português

Vídeo original: Anthropic cria o seu próprio “Git” · Canal: Compilado do Código Fonte TV [OFICIAL] · 10:22 · Assistir no YouTube

Tópicos: Agentes de IA, Engenharia de software com IA, Ferramentas de desenvolvimento com IA, Open source e ecossistemas de software

Resumo

O vídeo explica por que a Anthropic criou o Skein, um sistema interno de controle de versão, após o volume de alterações e operações de checkout tornar o Git um gargalo para sua infraestrutura. A proposta usa um monorepo centralizado e consultas por API, evitando que cada máquina precise clonar toda a base de código. Os apresentadores discutem as vantagens e os custos desse modelo, comparando-o a sistemas centralizados mais antigos. Também especulam que o aumento do uso de IA pode pressionar serviços como o GitHub e incentivar novas soluções de versionamento.

Pontos-chave

• Segundo o vídeo, os merges diários na Anthropic aumentaram de 2.500 em maio para mais de 30.000 em setembro.
• A branch principal mencionada teria cerca de 100 GB e sustentaria aproximadamente 25 milhões de checkouts por dia.
• O uso tradicional do Git nessa escala poderia gerar mais de 600 petabytes de tráfego diário, conforme apresentado no vídeo.
• O Skein é descrito como um sistema centralizado, com consultas ao código feitas por API, sem clonagem local completa.
• O Claude teria auxiliado no desenvolvimento do sistema e na reescrita de pipelines de ingestão.
• Os apresentadores comparam o modelo centralizado a ferramentas como CVS, SourceSafe, SVN, Perforce e TFVC.
• A centralização pode reduzir a carga nas máquinas de desenvolvimento, mas aumenta a dependência de servidores robustos.
• O vídeo relaciona o crescimento do desenvolvimento com IA a possíveis pressões sobre o GitHub e outros serviços de hospedagem de código.
• A Anthropic teria desenvolvido o Skein para uso interno, sem previsão de distribuir uma versão open source.

Capítulos

Início	Capítulo	Resumo
00:02	O problema de escala do Git	Os apresentadores descrevem o crescimento de merges e checkouts na Anthropic e a pressão que isso coloca sobre o Git.
03:07	Sistemas centralizados e seus trade-offs	A conversa compara o Skein a sistemas centralizados mais antigos e aborda bloqueios de arquivos, dependência de servidores e limitações para testes.
06:15	IA, GitHub e aumento de atividade	Os apresentadores discutem como o desenvolvimento com IA pode pressionar a infraestrutura do GitHub e mencionam incidentes na plataforma.
08:49	Possíveis soluções futuras	A conversa especula sobre a evolução do Skein e o surgimento de serviços semelhantes, encerrando com a divulgação do canal.

Citações

A geração massiva de código por modelos Claude levou a infraestrutura da Anthropic ao limite. — 00:02

As consultas ocorrem via API no servidor, sem exigir a clonagem de cópias locais completas da base de código. — 02:05

O Skein foi desenhado sob medida para as necessidades internas e não terá versão de código aberto distribuída ao mercado. — 03:07

O Git foi feito para humanos; ele não foi feito para a gente. — 06:15

Conceitos e entidades

• Anthropic (empresa): Empresa que, segundo o vídeo, criou o Skein para atender às necessidades internas de controle de versão.
• Skein (ferramenta): Sistema centralizado de controle de versão da Anthropic, descrito como acessado por meio de consultas via API.
• Git (ferramenta): Sistema distribuído de controle de versão que, segundo o vídeo, se tornou um gargalo para a escala de operações da Anthropic.
• Claude (modelo): Modelo da Anthropic que teria auxiliado no desenvolvimento do Skein e na reescrita de pipelines.
• GitHub (empresa): Plataforma de hospedagem de código baseada em Git, mencionada na discussão sobre a pressão causada pelo aumento de atividade.
• CVS (ferramenta): Sistema centralizado de controle de versão citado como exemplo de uma abordagem anterior.
• SourceSafe (ferramenta): Sistema de controle de versão da Microsoft lembrado pelos apresentadores como exemplo de modelo centralizado.
• SVN (ferramenta): Sistema de controle de versão mencionado entre as alternativas com modelo centralizado.
• Perforce (ferramenta): Sistema de controle de versão citado como exemplo de ferramenta com modelo centralizado.
• TFVC (ferramenta): Sistema de controle de versão citado na comparação com abordagens centralizadas.

Tradução completa (pt-BR)

00:02 Começando com a Anthropic, que resolveu criar o seu próprio Git. >> Como? Eu nem tinha visto isso. >> Pois é. >> Uau. >> Por quê? Por que eles precisaram criar o seu próprio Git? Eu ia falar GIF. >> [risadas] >> Olha, a geração massiva de código por modelos Claude levou a infraestrutura da Anthropic ao limite, forçando a companhia a abandonar a arquitetura distribuída do Git e criar seu próprio sistema de controle de versão, batizado de Skion. Pois é. A empresa revelou que o volume de alterações integradas que ela tem… vários

00:33 números aqui para você, é impressionante, hein? A empresa revelou que o volume de alterações integradas saltou de 2.500 merges diários em maio para mais de 30.000 por dia em setembro. >> Caramba. >> Cara, tem noção desse número? Aí você pensa: por quê? Porque deve estar tudo automatizado lá. >> Uhum. >> E aí eles devem ter configurado os agentes assim: alterou uma vírgula… >> Merge. >> Alterou uma vírgula. Merge. Bom, porque, cara, não tem como fazer 30.000 por dia

01:03 e serem funcionalidades novas. São ajustes pequenos, obviamente, né? Transformando o gerenciamento de repositórios, compilações e rotinas de integração contínua no principal gargalo técnico da operação. Então, o Git está atrapalhando eles. Olha, com a branch principal acumulando… >> Caramba, cara. >> Cara, chuta: quanto você acha que a branch principal do Claude precisa de armazenamento? Tempo. Pensou? Eu digo: 100 gigabytes. 100

01:34 gigabytes de uma branch e demandando cerca de 25 milhões de checkouts por dia para sustentar pipelines de CI, ambientes locais e instâncias de teste de agent. Cara, então vai ficar impossível rodar isso… Não impossível, né? Mas bem difícil de rodar isso até num computador normal de desenvolvimento, né? O tráfego gerado pela abordagem nativa do Git ultrapassaria 600 petabytes diários se fosse executada de maneira

02:05 tradicional. >> Caramba, cara. Então, para solucionar esse problema de escala, a desenvolvedora estruturou o Skion, que é um monorepo centralizado com cliente leve, no qual as consultas ocorrem via API no servidor, sem exigir a clonagem de cópias locais completas da base de código. >> Então, peraí. Então, não é o modelo descentralizado; tem que ser centralizado, com um banco de dados, usando um servidor que serve o código sob demanda. Seria isso? >> Essa é a ideia. Déjà vu, Gabriel?

02:35 >> É um déjà vu, aí. >> Já vi coisas parecidas. O próprio modelo Claude auxiliou no projeto, além de reescrever pipelines de ingestão sobre o motor Mitos Preview, com redução de 20 vezes no consumo de memória e velocidade quatro vezes maior. Segundo os engenheiros da companhia, a atuação humana passou a se concentrar em supervisionar e barrar decisões da IA que violassem restrições fundamentais de arquitetura. A Anthropic declarou que o Skion foi desenhado sob medida para as necessidades internas e não terá uma versão

03:07 de código aberto distribuída ao mercado. Termino com a… Porque, vamos lá, né? Claro, vimos aqui que os números impressionam, mas acredito que essa necessidade vai se estender para outras empresas que estão utilizando modelos e agentes de IA da mesma forma. Você não acha? >> É isso que eu ia falar. >> [risadas] >> Pois é. Obviamente, como eles estão desenvolvendo muito com IA, a tendência é que outras empresas também façam isso ou desenvolvam seus produtos com a mesma metodologia. Eu não vou fazer um

03:39 clickbait e falar: “O Git vai morrer”, sabe? É que eu acho que… >> Deu vontade, mas não, não. Claro que não. Mas eu entendo. >> Então, mas acho que o que deveria acontecer no futuro, se realmente a tendência for utilizar sistemas centralizados, como o CVS, ou tentar ressuscitar o SourceSafe da Microsoft… >> Ah, nossa, deu até um comichão aqui embaixo. >> Então. Era isso de déjà vu: a gente usava um banco de dados central com o código, que ficava armazenado ali, e as

04:09 pessoas faziam o checkout e o check-in. Check-in. É, só que o problema disso tudo, dessa abordagem, é que era uma porcaria: quando você fazia o checkout, travava o arquivo para check-in. Então, o arquivo era seu. >> É. Olha, é como se você fosse até a gavetinha, abrisse e dissesse: “Olha, vou usar esta caneta aqui”. Se o Gabriel fosse procurar na gaveta, não ia achar a caneta, porque eu estava usando naquele momento. Quando terminava, eu ia lá e devolvia direitinho. Então… >> O problema aí é o trade-off. Então, se ficou impossível utilizar o

04:41 Git com esses números aqui, realmente fica impossível. >> Não. >> O trade-off é você usar um desses sistemas centralizados; também tem que ter um super servidor lá para aguentar essa coisa. A vantagem é que você pode ter máquinas mais leves rodando os agentes, codificando só nos arquivos de que realmente precisa. A questão é você entender como isso vai funcionar com o time. Porque no SourceSafe ou em outros, por exemplo, no SVN, no CVS, tem o Perforce,

05:11 tem outros, como o TFVC. Todos esses têm modelo centralizado, tá? Ou também funcionam de alguma forma distribuída. O problema dessa abordagem, quando é centralizada, é você realmente ficar dependente das máquinas dos usuários para poder atualizar. O que dava problema? O desenvolvedor fazia o checkout e ia para casa na sexta-feira; aí você precisava do arquivo e, no fim, baixava a versão atual sem a atualização, ou forçava o check-in e travava aquele arquivo. E aí não

05:43 tinha esse conceito de merge depois. Você tinha que resolver na porrada com outro dev para saber quem ia subir a atualização correta. >> Não é tão amigável, talvez. >> É, pois é. Existem essas abordagens diferentes. E até para testar localmente, essa abordagem muda. Você tinha que ter, obviamente, um servidor de homologação, um servidor de teste, para poder fazer esses testes. Aí ocorre o mesmo problema: você tem uma instância do servidor de homologação, enquanto tem um time de vários agentes, vários

06:15 desenvolvedores subindo versões diferentes, e aquela versão está sempre mudando. Dessa forma, você também precisa ter um servidor robusto de homologação para subir tantas instâncias quantas forem necessárias. Porque o computador do desenvolvedor acaba ficando… >> Leve, né? >> Virando um computador burro. Ele não é um computador para você… >> Vira quase que um terminal, né? >> É, se você emular um ambiente. >> Uhum. Agora são novos desafios que vamos encontrar porque, realmente, o Git foi feito para humanos, não foi feito para a gente. Então, nessa velocidade

06:46 e nessa quantidade de transações, vai realmente ficar impossível. Agora vamos extrapolar também: imagina o quanto o GitHub não está sofrendo neste momento. >> Exato. >> Porque, né, é a principal plataforma que utiliza o Git como base; as empresas usam o GitHub em massa. Imagina só como é que a Microsoft não está lá, se esforçando para manter a estrutura do GitHub. >> Por isso que temos visto justamente essa plataforma, o GitHub,

07:16 sofrer neste ano e no ano passado. Houve algumas quedas e instabilidades também, e obviamente isso vai afetar. Não é à toa que o próprio GitHub acaba colocando alguns produtos pagos e algumas limitações também. Coisas que eles tinham deixado abertas lá atrás, que a Microsoft tinha liberado quando comprou o GitHub, vão ter que ser revistas. >> Não. >> Porque a quantidade de código que está entrando… Fazer checkout dos seus repositórios, dos seus 10 repositórios, dos seus 30, 40, é ótimo.

07:47 Agora, o que a gente vê numa empresa grande, por exemplo: rolou um problema na Meta. Não sei se a gente vai comentar isso, mas um desenvolvedor da Meta teve um problema: o computador dele foi comprometido e tiveram acesso aos repositórios. Na conta dele do GitHub, ele já tinha o quê? Mais de 2.000, 3.000 repositórios internos lá, não é? >> 2.500. >> 1.500, pois é. Isso é coisa pra caramba, cara, é coisa pra caramba. Então, a quantidade de PRs e checkouts que rola hoje por conta da inteligência artificial é algo para o qual eu acho que o

08:19 GitHub não estava preparado. Nem sonhava… imaginava que isso ia acontecer. Olha, só para vocês terem noção: em 12 meses, até o início de 2026, foram mapeados 257 incidentes no GitHub, e 48 foram considerados quedas globais. Os piores meses… fevereiro de 2026 foi caótico: só em fevereiro, acumulou 37 incidentes, tá? Então, saltou para perto de 10%. Será que é isso?

08:49 É. O maior apagão, olha, foi em agosto de 2026: ficou bloqueado por cerca de 7 horas e 30 minutos. Ou seja, acho que há realmente uma necessidade, talvez, de algo novo. Porque, como a Anthropic desenvolveu o que precisa, imagino — aqui vou fazer um exercício de futurologia, que pode estar completamente errado, afinal de contas, estou tentando adivinhar — que, devido a essa necessidade, provavelmente a própria Anthropic vai começar a testar isso internamente e

09:19 se der certo, vai lançar isso lá na frente, como open source ou, no mínimo, para que outras pessoas e empresas possam utilizar como um tipo de serviço. >> E que outras soluções similares vão acabar surgindo. >> O pessoal vai clonar. Vai pegar o código. Clona isso. >> Clonar, vai pegar o código, clona isso, clona esse código, beleza. Vai clonar o sistema; o versionamento vai ficar ótimo. Só não vai conseguir emular a necessidade dos servidores, tudo isso. Aí

09:50 não dá para clonar; aí tem que comprar mesmo, tem que colocar dinheiro nisso. >> E este aqui é um trecho de uma notícia do compilado do Código Fonte TV. >> Toda semana tem episódio novo falando de programação, tecnologia, inteligência artificial e cibersegurança. >> Então já se inscreve aqui no canal do compilado e acompanha os episódios completos. >> [música]

10:22 [música]

Transcrição original

[00:02] Começando com a Anthropic que resolveu criar o seu próprio Git. >> Como? Eu não tinha nem visto isso. >> Pois é. >> Uau. >> Por quê? Por que que eles precisaram criar o seu próprio give? Git. Ia falar gif. >> [risadas] >> Ó, a geração massiva de código por por modelos Claude levou a infraestrutura da Anthropic ao limite, forçando a companhia a abandonar a arquitetura distribuída do Git e criar seu próprio sistema de controle de versão batizado de Skion. Pois é. A empresa revelou que o volume de alterações integradas que ela tem vários

[00:33] números aqui por você é impressionante, hein? A empresa ela revelou que o volume de alterações integradas saltou de 2.500 merges diários em maio para mais de 30.000 por dia em setembro. >> Cassilda. >> Cara, tem noção desse número? Aí você pensa, por quê? Porque porque tá tudo deve tá tudo automatizado lá. >> Uhum. >> E aí eles devem ter configurado os agentes assim, alterou uma vírgula >> Merge. >> Alterou uma vírgula. Merge. Bom, porque cara, não tem como fazer 30.000 por dia

[01:03] e ser funcionalidades novas, é é são ajustes pequenos, obviamente, né? Transformando aí o gerenciamento de repositórios, compilações e rotinas de integração contínua no principal gargalo técnico da operação. Então, o Git está atrapalhando ele. Olha, com a branch principal acumulando >> Caramba, cara. >> Cara, chuta, quanto você acha que a que a branch principal da do Claude precisa de armazenamento? Tempo. Pensou? Eu eu digo. 100 gigabytes. 100

[01:34] gigabytes da de uma branch e demandando aí cerca de 25 milhões de checkouts por dia para sustentar pipelines de CI, ambientes locais e instâncias de teste de agente. Cara, então vai ficar impossível rodar isso até não impossível, né? Mas bem difícil de rodar isso até num computador normal para desenvolvimento, né? O tráfego gerado pela abordagem nativa do Git alcançaria mais de 600 petabytes diários se fosse executado de maneira

[02:05] tradicional. >> Caramba, cara. Então, para solucionar esse problema de escala, a desenvolvedora estruturou o Ski on, que é um monorepo centralizado com cliente leve, no qual as consultas ocorrem via API no servidor sem exigir a clonagem de cópias locais completas da base de código. >> Então, pera aí. Então, não é o modelo descentralizado, tem que ser centralizado com um banco de dados, usando um servidor que serve ali, eh, o código por demanda. Seria isso? >> Essa é a ideia. Dejavu, Gabriel?

[02:35] >> É um dejavu, aí. >> Já já vi coisas parecidas, já. O próprio modelo Claude auxiliou no projeto, além de reescrever pipelines de ingestão sobre o motor Mitos Preview, com redução de 20 vezes no consumo de memória e velocidade quatro vezes maior. Segundo os engenheiros da companhia, a atuação humana passou a se concentrar em supervisionar e barrar decisões da IA que violassem restrições fundamentais de arquitetura. A Anthropic declarou que o Ski on foi desenhado sob medida para as necessidades internas e não terá versão

[03:07] de código aberto distribuída ao mercado. Termino com a Porque, vamos lá, né? Claro, vimos aqui, os números impressionam, mas eu acredito que essa necessidade vai se estender para outras empresas que estão utilizando modelos e agentes de IA da mesma forma, você não acha? >> É isso que eu ia falar. >> [risadas] >> Pois é. Obviamente, como eles estão desenvolvendo muito com IA, a tendência que outras empresas também façam, eh, ou desenvolvam os seus produtos com a mesma metodologia. Eu não vou fazer um

[03:39] clickbait falar, “O Git vai morrer”, sabe? É que eu acho que é >> Deu vontade, mas não não, claro que não. Mas eu entendo. >> Então, mas eu acho que o que deveria acontecer no futuro, se realmente a tendência for utilizar sistemas centralizados, como o CVS ou tentar ressuscitar aí o SourceSafe da Microsoft. >> Ah, nossa, deu até um comichão aqui embaixo. >> então. Era isso de déjà vu, que a gente usava um banco de dados central com o código, ali ficava armazenado e as

[04:09] pessoas faziam o checkout e o check-in. Check-in. É, só que o problema todo disso, que a essa abordagem era uma porcaria, é quando você fazia o checkout, você travava o arquivo para check-in. Então, o o arquivo era seu. >> É. Olha, eu é como se você pegasse, fosse lá na gavetinha, abrisse, olha, eu vou usar essa caneta aqui. Se o Gabriel fosse lá procurar a gaveta, ele não ia na caneta, não ia achar porque eu estava usando a caneta naquele momento. Quando eu terminava, eu ia lá e devolvia ela certinho. Então, >> O o o problema, aí, é é trade-off. Então, se ficou impossível utilizar o

[04:41] Git e com esses números aqui, é realmente fica impossível. >> Não. >> O trade-off é você utilizar um desses central, é também ter um tem que ter um super servidor lá para aguentar essa coisa. Aí a vantagem é, você pode ter máquinas mais leves rodando ali os agentes, codificando só em arquivos que realmente você tem necessidade. Aí é o lance é é você entender como isso vai funcionar com o time. Porque no SourceSafe ou nesses outros, por exemplo, o SVN, o CVS, tem o Perforce,

[05:11] tem outros aqui que é o TFVC, todos esses têm modelo centralizado, tá? Ou também funciona de alguma forma distribuída também. O problema dessa abordagem, quando é centralizada, é você realmente ficar dependente de máquinas dos usuários para poder atualizar. O que dava de problema? O desenvolvedor fazia o checkout e ia para casa na sexta-feira e aí você precisava do arquivo, você, no fim, baixava a versão atual sem a atualização ou você forçava o check-in e aí você travava lá aquele ali. E aí não

[05:43] tinha esse conceito de merge depois. Aí você tinha que tinha que resolver na porrada lá com outro dev para saber quem que vai subir a atualização correta. >> não tão amigável talvez. >> É, pois é. Tem essas abordagens diferentes. E aí até para você testar local essa abordagem muda. Você tinha que ter obviamente lá um servidor de homologação, servidor de teste para você poder fazer esses testes. Aí ocorre o mesmo problema. Você tem uma instância do servidor de homologação enquanto você tem um time de vários agentes, vários

[06:15] desenvolvedores subindo versões diferentes, aquela versão sempre modificava. E aí dessa forma você tem que ter também um servidor robusto de homologação para você subir N instâncias quanto forem necessárias. Porque o computador de desenvolvedor fica acaba >> leve ali né? >> virando um computador burro. Ele não é um computador para você >> Vira quase que um terminal né? >> É, se você emular um ambiente. >> Uhum. Agora são novos desafios que nós vamos encontrar porque realmente né, o Git foi feito para humanos, ele não foi feito para a gente. Então nessa velocidade

[06:46] aqui de de quantidade de eh transação de vai realmente ficar impossível. Agora vamos extrapolar também, imagina o quanto o GitHub não tá sofrendo nesse momento. >> Exato. >> Porque né, é a principal plataforma que utiliza o Git como base, as empresas utilizam o GitHub em massa. Imagina só como é que não tá a Microsoft lá ó, cortando um dobrado para manter a estrutura do GitHub. >> Por isso que a gente tem visto justamente essa plataforma do GitHub

[07:16] sofrer nesse ano, no ano passado. Teve sim algumas algumas quedas, instabilidades também e obviamente que isso vai afetar. Não é à toa também que o próprio GitHub acaba colocando alguns produtos pagos, algumas limitações também, coisa que eles tinham aberto lá atrás, a Microsoft tinha liberado quando comprou o GitHub, eles vão ter que rever isso. >> Não. >> Porque a quantidade de código que tá entrando, checkout aqui, isso para os teus repositórios, pros teus 10 repositórios, pros teus 30, 40, é ótimo.

[07:47] Agora, o que a gente vê, numa empresa grande, por exemplo, rolou um problema na Meta. Não sei se a gente vai comentar isso, mas rolou um problema de um desenvolvedor da Meta lá, que o computador dele foi comprometido e tiveram acesso aos repositórios. Ele, no na conta dele do GitHub, já tinha o quê? Mais de 2.000, 3.000 repositórios lá internos, não é? >> 2.500. >> 1.500, pois é. Isso é coisa pra caramba, cara, é coisa pra caramba. Então, a quantidade de PRs, checkouts, que rolam hoje, por conta da inteligência artificial, eu acho que é algo que o

[08:19] GitHub não tava preparado. Nem nem >> sonhava >> imaginava que isso ia acontecer, ó. Só pra vocês vocês terem noção, ó, em 12 meses e início de 2026, foram mapeados 257 incidentes no GitHub e 48 considerados quedas globais. Os piores meses foi fevereiro de 2026, que foi o caótico aí, que acumulou, só fevereiro e fevereiro, 37 incidentes, tá? Então, é saltou aí perto de 10%, será que é isso?

[08:49] É. O maior apagão, ó, foi em agosto de 2026, ficou cerca de 7:30 bloqueado. Ou seja, eu acho que tem tem realmente uma >> uma necessidade, talvez, de de algo novo, até. Porque, como a Anthropic fez o que desenvolveu o que ela precisa, eu eu imagino, aqui vou fazer um exercício de futurologia, que pode estar completamente errado, né? Afinal de contas, eu estou tentando adivinhar, que devido a essa necessidade, provavelmente, a própria Anthropic vai começar a testar isso dentro de casa e

[09:19] ficando certo, ela lança isso lá na frente, ou open source, ou minimamente pra que outras pessoas possam, outras pessoas e empresas possam utilizar como um tipo de serviço. >> E que outras soluções similares vão acabar surgindo. >> Pessoal, o pessoal vai clonar. Vai pegar o código. Clone esse. >> clonar, vai pegar o código, clone esse, clone esse código, beleza. Vai clonar o o sistema, o versionamento vai estar topzeira, só não vai conseguir emular a necessidade dos servidores, isso tudo, aí

[09:50] não dá para clonar, aí tem que comprar mesmo, tem que botar grana lá para isso. >> E esse aqui é um corte de uma notícia do compilado do Código Fonte TV. >> Onde toda semana tem episódio novo falando de programação, tecnologia, inteligência artificial e cibersegurança. >> Então já se inscreve aqui no canal do compilado e acompanha os episódios completos. >> [música]

[10:22] [música]