A Anthropic abandonou o Git (Claude o quebrou)

Autoria: Hyperautomation Labs · 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: inglês

Vídeo original: Anthropic Just Ditched Git (Claude Broke It) · Canal: Hyperautomation Labs · 08:46 · Assistir no YouTube

Tópicos: Agentes de IA, Automação de tarefas e workflows, Claude Code, Engenharia de software com IA

Resumo

A Anthropic chegou a mais de 30 mil alterações de código em um dia, e o Git se tornou um gargalo para seus agents e sistemas de teste. Para lidar com a escala, sete engenheiros criaram o Scion, um sistema de controle de código-fonte em que o servidor faz o trabalho e as máquinas baixam apenas o que precisam. A mudança acelerou tarefas e reduziu o uso de recursos, enquanto Claude ajudou a reescrever componentes do sistema. O vídeo destaca cinco lições: otimizar o ciclo de desenvolvimento inteiro, revisar o julgamento do modelo, investir em testes, usar agents especializados para monitoramento e questionar processos criados para compensar a lentidão humana.

Pontos-chave

A Anthropic passou de cerca de 2.500 alterações de código por dia em maio para 30.401 em um único dia em 9 de setembro.
O Git foi um gargalo porque seus clones completos eram inadequados para agents e tarefas de teste executados em data centers.
O Scion transfere o trabalho para o servidor e baixa apenas os arquivos ou dados solicitados.
O status do código passou de quase quatro segundos para 19 milissegundos, e a preparação de um workspace para agent caiu de sete minutos para cinco segundos.
Sete engenheiros desenvolveram o Scion, a ferramenta de revisão Antique e outros sistemas, e migraram a empresa em cinco meses.
Claude Mythos reescreveu um componente usando 20 vezes menos memória e executando quatro vezes mais rápido, preservando regras implícitas do código anterior.
A equipe ainda revisa as alterações de Claude, com foco na intenção, nas regras do sistema e em verificar se o modelo está resolvendo um problema real.
O vídeo recomenda investir em testes, criar agents especializados para monitoramento e rever etapas que existem apenas porque as pessoas eram o gargalo.
A Anthropic afirma que o Scion não é destinado a equipes comuns e não será lançado; espera que GitHub, GitLab e Git aproveitem algumas de suas ideias.

Capítulos

Início	Capítulo	Resumo
00:00	O crescimento do código expõe os limites do Git	O aumento das alterações e dos checkouts na Anthropic torna o Git um gargalo para agents e tarefas de teste.
02:34	Como o Scion funciona e o que mudou	O Scion transfere operações para o servidor, usa camadas de cache e reduz o tempo e os recursos necessários para trabalhar com o código.
04:37	Claude ajuda a reescrever o sistema	A equipe relata os resultados de Claude Mythos ao reescrever um componente e apresenta lições sobre gargalos, revisão e testes.
06:12	Cinco lições para trabalhar com IA	O vídeo recomenda priorizar testes, usar agents especializados no monitoramento e repensar processos que pressupõem que humanos são o gargalo.
07:45	O que muda no trabalho dos engenheiros	A Anthropic esclarece que não lançará o Scion como substituto geral do Git e destaca o julgamento como parte central do trabalho de engenharia.

Citações

No Git, sua máquina faz o trabalho. No Scion, o servidor faz. — 02:34

O gargalo agora é tudo o que foi construído para a velocidade humana. — 05:09

Muito frequentemente, o trabalho era dizer não a Claude. — 05:41

Código está ficando barato. Julgamento, não. — 08:15

Conceitos e entidades

Anthropic (empresa): Empresa de IA que desenvolveu internamente o Scion para lidar com a escala de seu desenvolvimento de código.
Claude (modelo): Modelo de IA usado pela Anthropic para escrever código e apoiar o trabalho de engenharia.
Claude Mythos (modelo): Versão interna inicial de Claude que reescreveu um componente do sistema com menos uso de memória e maior velocidade.
Git (ferramenta): Sistema de controle de versão que, segundo o vídeo, se tornou um gargalo para as cargas de trabalho da Anthropic.
Scion (ferramenta): Sistema interno de controle de código-fonte da Anthropic que centraliza operações no servidor e baixa dados sob demanda.
Antique (ferramenta): Ferramenta de revisão de código desenvolvida pela equipe junto com o Scion.
GitHub (empresa): Plataforma que a Anthropic espera que possa aproveitar ideias do Scion.
GitLab (empresa): Plataforma que a Anthropic espera que possa aproveitar ideias do Scion.
Subversion (ferramenta): Sistema de controle de versão citado por um comentarista que comparou suas ideias às do Scion.
mono repo (conceito): Um único repo grande que reúne o código de toda uma empresa.

Tradução completa (pt-BR)

00:00 Em maio, a Anthropic integrava cerca de 2.500 alterações de código por dia. Em 9 de setembro, integrou 30.401 em um único dia. E o que fez esse número chegar tão alto? Claude escrevendo código. E o que quebrou não foi a IA, foi o Git, a ferramenta que quase todo desenvolvedor do planeta usa. Então, sete engenheiros fizeram algo que quase ninguém faz. Substituíram o Git em cinco meses. Vou mostrar exatamente como e as cinco lições que isso traz, capazes de mudar a forma como

00:31 você deve trabalhar com IA a partir desta semana. Veja por que isso importa, mesmo que você nunca vá trabalhar lá. A Anthropic usa Claude para escrever código mais do que quase qualquer empresa do planeta. Por isso, eles encontraram esses limites primeiro. E, nessa publicação, dizem que o mesmo problema vai atingir muito mais empresas nos próximos 6 a 12 meses. Então, pense nisso como uma prévia do seu próprio futuro. Antes de continuar, cinco palavras que você vai ouvir. Um commit é uma alteração salva no código. Um merge é quando essa alteração passa a fazer parte da versão principal usada por todos. Um repo, abreviação de repositório, é a pasta que

01:02 contém todo o código e seu histórico completo. Um mono repo é um repo gigantesco para a empresa inteira. E um checkout é quando uma máquina baixa esse código para poder trabalhar nele. É isso. Você já está a postos. Veja o que eles tinham pela frente. Um repositório gigantesco que continha quase todo o código da empresa. Só o histórico da branch principal tem quase 100 GB. Mesmo uma cópia compactada do código passa de 25 GB. E as máquinas de teste fazem checkout desse código cerca de 25 milhões de vezes por dia.

01:33 Se cada uma dessas máquinas baixasse o código da maneira normal, isso daria mais de 600 PB de tráfego todos os dias. Para entender por que o Git quebrou, você precisa saber uma coisa. O Git foi criado para que cada cópia seja completa. Seu laptop guarda o histórico inteiro para você poder continuar trabalhando em um avião sem internet. Para as pessoas, isso é genial. Mas os programadores da Anthropic não estão em aviões. São agents e tarefas de teste rodando em data centers. Por definição, estão conectados. Então, cada um deles carregava uma cópia completa de que não

02:04 precisava. Eles tentaram todas as soluções padrão. Clones superficiais, checkouts parciais, snapshots do repo mantidos no armazenamento em nuvem. No auge, estavam usando várias centenas de servidores Git extras, chamados de mirrors, só para dar conta. Isso lhes deu mais tempo, mas os snapshots ficavam defasados, e os mirrors ultrapassaram a capacidade dos próprios discos e da própria memória. Então, deram um passo atrás e fizeram uma pergunta. Se você projetasse um sistema de controle de código-fonte do zero, sabendo que seus usuários estão sempre conectados, como ele seria?

02:34 A resposta deles se chama Scion. Aqui está a ideia toda em linguagem simples. No Git, sua máquina faz o trabalho. No Scion, é o servidor. Quem alterou esta linha? Pergunte ao servidor. O que mudou entre estas duas versões? Pergunte ao servidor. Até mesmo um commit acontece no servidor, então não há nada para enviar. Sua máquina mantém um cache pequeno e só baixa os arquivos que realmente abre. E, como tudo é um único serviço grande, muitas tarefas nem sequer baixam o código. Um teste que precisa de um diff só

03:05 pede esse diff. As ferramentas automáticas deles, que encontram a alteração que causou um problema e a desfazem, só funcionam nessa escala porque consultar o servidor é tão barato. Nos bastidores, cada alteração é um pequeno registro. Quem fez? Quando? E apenas os arquivos que mudaram, com ponteiros para onde seu conteúdo fica armazenado. Agora, veja o autor no próprio exemplo da Anthropic: Claude. O trabalho pesado, como reconstruir o histórico completo de um arquivo, fica a cargo do servidor mais tarde, e só se alguém pedir.

03:36 Depois, eles empilharam três camadas de caches: uma em cada máquina, outra em cada região e o servidor de verdade no topo. Cada camada responde sozinha a mais de 99% das solicitações, então o servidor no topo mal é incomodado. E os resultados são, sinceramente, impressionantes. Verificar o status do seu código passou de quase 4 segundos para 19 milissegundos: 207 vezes mais rápido. Preparar um workspace novo para um agent passou de 7 minutos para 5 segundos. Somando tudo,

04:06 cada alteração feita por um agent passa menos de 4 minutos no controle de código-fonte, em vez de 34. Isso representa cerca de 11.000 horas de trabalho de agents economizadas todos os dias. E o sistema inteiro funciona com 200 vezes menos poder computacional do que os antigos mirrors do Git. Agora, aqui está o que mais me surpreendeu. Quantas pessoas construíram isso? Sete. Sete engenheiros criaram o Scion, uma nova ferramenta de revisão de código chamada Antique e meia dúzia de outros sistemas. Depois, migraram a empresa inteira em cinco meses, enquanto o volume de código que chegava cresceu 10 vezes. Não muito tempo atrás, um projeto como esse

04:37 levaria anos e muito mais engenheiros em uma grande empresa. E este é o momento que mostra para onde as coisas estão indo. No início do ano, a equipe escreveu à mão a primeira versão de uma peça fundamental: o pipeline que copia o histórico do Git para o Scion. Eles acharam que estava bom. Então, receberam uma versão interna inicial do Claude Mythos. Pediram que ele reescrevesse tudo, sem dar nenhuma outra instrução. Ele voltou com uma versão que usava 20 vezes menos memória e rodava quatro vezes mais rápido. E preservava todas as regras ocultas das quais o código antigo dependia.

05:09 Então, o que você deve tirar disso? Cinco lições. E todas elas também servem para projetos pequenos. Lição um: escrever o código já não é mais a parte lenta. A Anthropic diz isso claramente. O gargalo agora é tudo o que foi feito para a velocidade humana: controle de código-fonte, builds e testes. Então, se Claude escreve seu recurso em 2 minutos, mas você espera 20 minutos pelos testes e um dia pela revisão, é aí que está seu próximo grande ganho. Meça o ciclo inteiro, não só a digitação. Lição dois: esta é a mais importante. Todos os engenheiros dessa equipe agora dizem: “Claude escreve código melhor do que eles.” Leia de novo. Então, qual é o trabalho deles? Nas palavras da Anthropic, muitas vezes, era dizer não a Claude. Há dois tipos de não. Um: Claude às vezes quebrava uma regra básica do sistema só para fazer algo funcionar, como percorrer todo o log de commits para descobrir quando uma alteração entrou, em vez de perguntar à ferramenta de revisão. Dois: quando Claude revisa Claude, ele pode ficar paranoico com problemas que não existem e acrescentar verificações extras de que ninguém precisa. Então, eles ainda revisam cada alteração, mas a leem pensando na

05:41 intenção, não linha por linha. Antes de aceitar qualquer coisa de Claude, faça duas perguntas. Isso quebra alguma regra do meu sistema? E está resolvendo um problema que eu realmente tenho? Uma coisa rápida. A maioria de vocês que está assistindo ainda não se inscreveu. É grátis e é assim que este canal continua fazendo vídeos como este. Certo, lição três. Lição três: use o tempo que você economiza para fazer testes. Como Claude escreve código tão rápido, a Anthropic diz que o Sci-on é uma das bases de código mais bem testadas em que já trabalharam. Construída com um prazo apertado, simulações completas, fuzzing e limitação de taxa.

06:12 E é isso que torna seguro o truque de Midas. Quando você tem testes que fixam o comportamento atual do seu código, pode pedir ao melhor modelo que reescreva tudo, e os testes dizem se ele preservou as regras. Lição quatro, a minha favorita. A Anthropic deu a cada parte do sistema seu próprio Claude, em seu próprio canal do Slack, cuja única função é se dedicar obsessivamente àquela parte. Eles os chamam de super fãs. Há um super fã do cache, um super fã da fila de merge e

06:43 outros. Eles leem gráficos e logs como um engenheiro experiente sem nada melhor para fazer e detectam problemas estranhos que os alertas normais deixam passar. Você pode copiar isso hoje. Um Claude, uma coisa para monitorar, seus logs e uma nota diária sobre qualquer coisa estranha, com Claude no Slack ou uma tarefa programada do Claude. Lição cinco: questione todas as regras que só existem porque os humanos são lentos. Uma fila de merge normal deixa as alterações entrar uma de cada vez para que nada entre em conflito. Com 30.000 alterações por dia, isso simplesmente trava. Então, a Anthropic não usa um bloqueio global.

07:13 As alterações são integradas, e os testes acontecem depois do merge e antes de qualquer coisa ser lançada. Sim, às vezes as alterações entram em conflito, mas Claude geralmente resolve o conflito mais rápido do que uma pessoa conseguiria sequer percebê-lo. Então, examine seu próprio processo. Quais etapas só existem porque as pessoas costumavam ser a parte lenta? Agora, nem todo mundo gostou disso. No Hacker News, a publicação recebeu mais de 600 comentários. Uma pessoa perguntou: “Eles simplesmente reinventaram o Subversion?” Outra perguntou o que talvez você esteja pensando. Pergunta sincera: “O que as pessoas da Anthropic fazem, afinal

07:45 As alterações são mescladas, e os testes acontecem depois da mesclagem e antes de qualquer coisa ser lançada. Sim, às vezes as alterações entram em conflito, mas Claude geralmente resolve o conflito mais rápido do que uma pessoa sequer conseguiria percebê-lo. Então, analise seu próprio processo. Quais etapas existem apenas porque as pessoas costumavam ser a parte lenta? Bem, nem todo mundo gostou disso. No Hacker News, a publicação recebeu mais de 600 comentários. Uma pessoa perguntou: “Eles simplesmente reinventaram o Subversion?” Outra fez a pergunta que talvez você esteja pensando. Pergunta sincera: “O que as pessoas da Anthropic fazem, afinal

08:15 agora?” Perguntas justas. E, para deixar claro, a Anthropic concorda que Scion não é para você. Eles dizem que não é um substituto do Git para equipes comuns e que não vão lançá-lo. O que querem é que GitHub, GitLab e o próprio Git adotem as melhores ideias. E essa segunda pergunta é a história toda. O que aquelas sete pessoas fizeram? Elas não digitaram a maior parte do código. Decidiram o que construir, até que escala precisava funcionar e quando Claude estava errado. Esse é o trabalho agora. Código está ficando barato. Discernimento, não. Reuni todas as cinco lições em um PDF gratuito

08:46 : o Agent Scale Playbook. O cartão de revisão com duas perguntas, um prompt de super fã para copiar e colar que você pode configurar hoje e quatro configurações do Git que deixam grandes repos mais rápidos agora mesmo. Comente Scion e eu envio para você. E, se você está começando a usar Claude code, meus guias para iniciantes estão nos links abaixo. Até a próxima.

Transcrição original

[00:00] In May, Anthropic merged about 2,500 code changes a day. On September 9th, they merged 30,401 in one day. And what pushed it that high? Claude writing code. And the thing that broke wasn’t the AI, it was Git, the tool almost every developer on Earth uses. So, seven engineers did something almost nobody does. They replaced it in 5 months. I’ll show you exactly how and the five lessons from it that change how

[00:31] you should work with AI starting this week. Here’s why this matters even if you’ll never work there. Anthropic uses Claude to write code more than almost any company on Earth. So, they hit the walls first. And in this post, they say the same problem will reach a lot more companies in the next 6 to 12 months. So, think of this as a look at your own future. Before we go on, five words you’ll hear. A commit is one saved change to the code. A merge is when that change joins the main version everyone uses. A repo, short for repository, is the folder that

[01:02] holds all the code and its whole history. A mono repo is one giant repo for the entire company. And a checkout is when a machine downloads that code so it can work on it. That’s it. You’re ready. Here’s what they were up against. One giant repository holding almost all their code. The history of the main branch alone is almost 100 GB. Even a compressed copy of the code is over 25 GB. And their test machines check that code out around 25 million times a day.

[01:33] If every one of those downloaded it the normal way, that’s over 600 PB of traffic every single day. To see why Git broke, you need one idea. Git was built so every copy is complete. Your laptop holds the whole history so you can keep working on a plane with no internet. For people, that’s brilliant. But Anthropic’s coders aren’t on planes. They’re agents and test jobs running in data centers. They are online by definition. So, every one of them was hauling around a full copy it didn’t

[02:04] need. They tried every standard fix. Shallow clones, partial checkouts, snapshots of the repo kept in cloud storage. At the peak, they were running several hundred extra Git servers called mirrors just to keep up. It bought them time, but the snapshots kept falling behind and the mirrors outgrew their own disks and memory. So, they stepped back and asked one question. If you designed source control from scratch, knowing your users are always online, what would it look like?

[02:34] Their answer is called Scion. Here’s the whole idea in plain English. In Git, your machine does the work. In Scion, the server does. Who changed this line? Ask the server. What’s different between these two versions? Ask the server. Even a commit happens on the server, so there’s nothing to push. Your machine keeps a small cache and it only downloads the files it actually opens. And because it’s all one big service, a lot of jobs never download the code at all. A test that needs one diff just

[03:05] asks for that diff. Their automatic tools that find which change broke something and undo it only work at this scale because asking the server is that cheap. Under the hood, every change is a small record. Who made it? When? And only the files that changed with pointers to where their contents live. Now, look at the author on Anthropic’s own example, Claude. The heavy stuff, like the full history of a file, gets worked out by the server later and only if someone asks for it.

[03:36] Then they stacked three layers of caches, one on every machine, one in every region, and the real server at the top. Each layer answers more than 99% of requests on its own, so the server at the top barely gets bothered. And the results are honestly ridiculous. Checking the status of your code went from almost 4 seconds to 19 milliseconds, 207 times faster. Setting up a fresh workspace for an agent went from 7 minutes to 5 seconds. Add it all

[04:06] up and each agent change spends under 4 minutes on source control instead of 34. That’s about 11,000 agent hours saved every day. And the whole system runs on 200 times less computing power than the old Git mirrors. Now, here’s the part that surprised me most. How many people built this? Seven. Seven engineers built Scion, a new code review tool called Antique, and half a dozen other systems. Then, they moved the whole company over in 5 months while the amount of code coming in grew 10 times. Not long ago, a project like this

[04:37] took a big company years and a lot more engineers. And this is the moment that tells you where things are going. Early in the year, the team wrote the first version of one key piece by hand, the pipeline that copies Git history into Scion. They thought it was good. Then, they got an early internal version of Claude Mythos. They asked it to rewrite the whole thing with no other instructions. It came back using 20 times less memory and running four times faster. And it kept every hidden rule the old code depended on.

[05:09] So, what do you actually take from this? Five lessons. And every one of them works on a small project, too. Lesson one, writing the code is no longer the slow part. Anthropic says it straight. The bottleneck is now everything built for human speed, source control, builds, testing. So, if Claude writes your feature in 2 minutes and then you wait 20 minutes for tests and a day for review, that’s where your next big win is. Time the whole loop, not just the typing. Lesson two, this is the big one. Every engineer on this team now says, “Claude

[05:41] writes code better than they do.” Read that again. So, what’s their job? In Anthropic’s words, very often, it was to tell Claude no. Two kinds of no. One, Claude would sometimes break a basic rule of the system just to make something work, like reading through the entire commit log to find when a change landed instead of asking the review tool. Two, when Claude reviews Claude, it can get paranoid about problems that don’t exist and pile on extra checks nobody needs. So, they still review every change, but they read it for the

[06:12] intent, not line by line. Before you accept anything from Claude, ask two questions. Does this break a rule of my system? And is this fixing a problem I actually have? Quick one. Most of you watching haven’t subscribed yet. It’s free and it’s how this channel keeps making videos like this. Okay, lesson three. Lesson three, spend the time you save on tests. Because Claude writes code so fast, Anthropic says Sci-on is one of the best tested code bases they’ve ever worked on. Built on a tight deadline,

[06:43] full simulations, fuzzing, rate limiting. And that’s what makes the Midas trick safe. Once you have tests that lock in how your code behaves today, you can ask the best model to rewrite the whole thing and the test tell you if it kept the rules. Lesson four, my favorite. Anthropic gave every part of the system its own Claude in its own Slack channel whose only job is to obsess over that one part. They call them super fans. There’s a cache super fan, a merge queue super fan, and

[07:13] more. They read the charts and logs like an experienced engineer with nothing better to do and they catch weird problems that normal alerts miss. You can copy this today. One Claude, one thing to watch, your logs, and a daily note of anything strange with Claude in Slack or a scheduled Claude task. Lesson five, question every rule that only exists because humans are slow. A normal merge queue lets changes in one at a time so nothing clashes. At 30,000 changes a day, that just jams. So, Anthropic doesn’t use a global lock.

[07:45] Changes merge and the testing happens after the merge and before anything ships. Yes, changes sometimes clash, but Claude usually fixes the clash faster than a person could even notice it. So, look at your own process. Which steps are there only because people used to be the slow part? Now, not everyone loved this. On Hacker News, it pulled over 600 comments. One person asked, “Did they just reinvent Subversion?” Another asked what you might be thinking. Honest question, “What do people at Anthropic even do

[08:15] now?” Fair questions. And to be clear, Anthropic agrees Scion isn’t for you. They say it’s not a Git replacement for normal teams and they’re not releasing it. What they want is for GitHub, GitLab, and Git itself to borrow the best ideas. And that second question is the whole story. What did those seven people do? They didn’t type most of the code. They decided what to build, how big it had to scale, and when Claude was wrong. That’s the job now. Code is getting cheap. Judgment isn’t. I put all five lessons into one free

[08:46] PDF, the Agent Scale Playbook. The two question review card, a copy and paste super fan prompt you can set up today, and four Git settings that make big repos faster right now. Comment Scion and I’ll send it to you. And if you’re new to Claude code, my beginner guides are linked below. See you in the next one.