00:00:00A Anthropic acaba de fazer algo grandioso: soltou 16 agentes do Claude para construir
00:00:05um compilador C e, após rodar 24 horas por dia durante duas semanas, eles de fato criaram um capaz de compilar
00:00:11o kernel do Linux e até rodar Doom, o que é impressionante e certamente não era possível
00:00:16com as versões anteriores do Opus 4. Mas há quem chame essa conquista de "caça-clique" e
00:00:22uma meia-verdade, devido às técnicas questionáveis que a Anthropic usou para chegar a esse resultado.
00:00:28Então, a Anthropic trapaceou? Inscreva-se no canal e vamos descobrir.
00:00:31Dividiremos este vídeo em três partes. Primeiro, veremos como o experimento foi configurado,
00:00:37depois passaremos pelas principais descobertas, com as quais acho que todo desenvolvedor aprenderá muito,
00:00:42e, por fim, analisaremos se os resultados são válidos, pois tenho algumas opiniões reais
00:00:47sobre como a Anthropic conseguiu construir esse compilador. Bem, o experimento foi conduzido por Nicholas
00:00:52Carlini, que, na minha opinião, é um ser humano muito inteligente. Vejamos como ele
00:00:58configurou isso. O projeto em si ficava em um diretório chamado Upstream, que estava montado
00:01:03em 16 containers Docker diferentes. Sei que só aparecem quatro aqui, mas vamos imaginar que são 16.
00:01:08E cada um desses containers continha uma versão do Claude rodando o Opus 4.6 e
00:01:15clonava o repositório Upstream para o Workspace, fazia todas as alterações ali e depois
00:01:21enviava para o Upstream. Isso foi genial, pois cada agente podia trabalhar isolado sem
00:01:27afetar o trabalho dos outros. Caso houvesse algum conflito de merge, o Claude
00:01:32seria inteligente o suficiente para resolvê-lo e enviá-lo de volta ao Upstream. Cada agente escolhia
00:01:38algumas tarefas. Não sei se essas tarefas foram geradas por um humano ou pelo próprio agente
00:01:44com base em testes, mas as tarefas existiam com nomes e cada agente assumia
00:01:50uma nova tarefa e, sempre que o fazia, criava uma nova sessão. Para manter
00:01:56esses agentes rodando por muito tempo, foi usado um loop Ralph. Assim, os agentes trabalhavam na tarefa,
00:02:02concluíam, enviavam ao Upstream, pegavam uma tarefa nova em uma sessão limpa e repetiam o processo.
00:02:08Se você viu nosso vídeo sobre Ralph, sabe que o segredo para ter agentes de longa duração
00:02:13é ter tarefas bem definidas. Mas, com 16 agentes simultâneos,
00:02:19como evitar que escolham a mesma tarefa? Travamento de tarefas. A lógica funciona assim:
00:02:24em algum lugar não mencionado pelo autor, existe uma lista de tarefas; um agente escolhe uma e,
00:02:30através de um arquivo de texto com o nome da tarefa, cria um commit para bloqueá-la, garantindo que só ele trabalhe nela,
00:02:36enviando isso ao diretório Upstream. Se outro agente escolher a mesma tarefa
00:02:42e criar o mesmo arquivo de texto, ao tentar enviar ao repositório Upstream, o Git rejeitará,
00:02:48avisando que o arquivo já existe, e ele terá que trabalhar em outra tarefa. Essa é a base
00:02:53de como Carlini testou o limite de agentes de longa duração equipados com o Opus 4.6, e os resultados
00:03:00são realmente incríveis. Mas, ao realizar esse experimento, ele descobriu coisas interessantes que
00:03:07todo desenvolvedor pode aproveitar. A primeira é construir um arcabouço de testes ou um script
00:03:12que rode diferentes tipos de testes, pois quando Nick estava rodando o experimento — sim, já estamos
00:03:17íntimos agora —, ele notou que o Claude quebrava recursos existentes ao trabalhar em novos.
00:03:23Então, ele criou um ambiente de testes com testes de alta qualidade de repositórios famosos como
00:03:29SQLite, libjpg e Redis. E para evitar a poluição de contexto, ele garantiu que o ambiente de testes
00:03:35só exibisse logs úteis ao agente — basicamente logs de erro — e salvava
00:03:41os demais logs em um arquivo separado para o Claude consultar se precisasse. Contudo, com milhares
00:03:47de testes, os agentes levariam horas para rodar tudo, perdendo tempo que
00:03:52poderia ser usado em outra coisa. Foi aí que Nick foi muito astuto. Ele adicionou uma flag "fast"
00:03:58ao ambiente de testes, fazendo com que o agente rodasse apenas 1% ou 10% do total de testes,
00:04:05conforme o definido por Nick. Se cada agente rodasse 10%, teríamos 160% dos testes,
00:04:13o que é mais que suficiente, e isso não é ruim. O funcionamento era o seguinte: os testes,
00:04:19ou seja, os testes específicos de cada agente, eram aleatórios, mas com o mesmo número de semente,
00:04:25tornando-os determinísticos. Assim, cada agente teria os mesmos testes aleatórios e, por fim,
00:04:31percorreria toda a suíte de testes muito mais rápido do que se estivesse rodando tudo sozinho.
00:04:36O próximo ponto também é inteligente, mas um pouco polêmico, já que envolve usar tecnologia existente.
00:04:41Até então, cada agente rodava testes unitários de vários projetos de código aberto,
00:04:46o que funcionava bem ao dividi-los em blocos de 1% ou 10%. Mas, ao compilar o
00:04:53kernel do Linux, como esses arquivos não são testes unitários individuais, as coisas ficaram
00:04:58difíceis, pois cada agente tentava compilar tudo, encontrava o mesmo erro,
00:05:04tentava consertar e acabava sobrescrevendo o ajuste do outro. Nick resolveu isso
00:05:09fazendo com que cada agente rodasse uma porcentagem da compilação e deixando o GCC — o
00:05:15compilador GNU — rodar o restante. Nick chamou o GCC de "oráculo", já que o kernel do Linux deve compilar
00:05:22perfeitamente com ele. Se um agente compilasse uma seção do kernel com seu próprio compilador —
00:05:27uma seção diferente para cada agente — e o resto com o GCC, se algo quebrasse, a culpa era
00:05:34com certeza do compilador do agente, e não do GCC. Assim, o agente corrigia apenas aquilo em vez
00:05:40de corrigir um erro de outro agente. Isso é polêmico por usar um compilador existente para
00:05:46fazer algo que o Claude deveria fazer do zero. Mas falaremos mais disso ao final
00:05:51do vídeo. Vamos ao próximo ponto: dar memória ao seu agente. Como as novas tarefas são
00:05:57executadas por sessões limpas do Claude, sem memória do que foi feito antes,
00:06:03Nick achou útil atualizar o arquivo README e ter arquivos de progresso com instruções
00:06:09de onde pararam e o andamento do projeto, para que as novas sessões tivessem uma base sólida
00:06:13para começar e não reintroduzissem bugs que já haviam sido corrigidos. E o último ponto,
00:06:18mais óbvio, é dar papéis diferentes aos agentes. A vantagem de ter vários agentes trabalhando
00:06:23em paralelo é que várias ações podem ser feitas no mesmo trecho de código ao
00:06:29mesmo tempo. Quando não estava escrevendo código novo, Nick dava papéis únicos aos agentes, como
00:06:35um para verificar código duplicado, outro para otimizar a performance ao máximo,
00:06:40e até um para criticar o design sob a ótica de um desenvolvedor Rust — que espero não ter
00:06:45saído anunciando isso para os outros agentes. Mas, apesar do sucesso do projeto,
00:06:51a pergunta real é: a Anthropic trapaceou para obter esse resultado? Bem, mais ou menos. A tarefa era
00:06:57construir um compilador C do zero e o agente não tinha acesso à internet, então ele mesmo
00:07:03gerou todo o código. Ou será que não? Pois ele tinha acesso às suítes de teste de projetos
00:07:10de código aberto e à versão compilada do GCC. Tecnicamente, ele poderia ter testado
00:07:16o compilador GCC, inserindo entradas e inspecionando saídas para guiar o
00:07:24design de seu próprio compilador escrito em Rust. Mas, sejamos justos, se eu estivesse criando
00:07:31um compilador C do zero, faria o mesmo. Olharia para compiladores existentes, veria como foram implementados
00:07:36e usaria isso para moldar o meu. Agora, se eu estivesse criando um compilador para
00:07:41uma linguagem totalmente nova, aí as coisas seriam bem mais difíceis e talvez fosse um teste
00:07:47excelente para ver se o Claude é mesmo bom em criar compiladores do zero. Talvez
00:07:53seja uma ideia para o Nick testar, mas vamos falar sobre a natureza autônoma do
00:07:57experimento, já que isso também foi testado. Sendo justo, sim, o Claude escreveu todo o código, mas
00:08:04com um direcionamento humano pesado. Um humano decidiu quais testes rodar. Um humano iniciou
00:08:11o loop e decidiu usar o Ralph. Foi um humano quem criou o ambiente de testes e deu aos agentes
00:08:16papéis específicos. Então, embora esteja longe de ser apenas pedir para o Claude criar um compilador e deixá-lo
00:08:22rodar para sempre, eu não diria que o código foi escrito por um agente 100%
00:08:28autônomo, pois quão bom seria esse compilador se não houvesse um humano envolvido desde o início?
00:08:33E mesmo com todos esses sistemas projetados por um humano, o compilador C do Claude teve
00:08:39limitações cruciais. Por exemplo, ele usou o montador e o linker do GCC porque o que ele criou era
00:08:46bugado demais. Ele também precisou do compilador x86 de 16 bits do GCC para iniciar o Linux. E para completar,
00:08:54o código não era muito eficiente. A versão mais otimizada do compilador do Claude era menos
00:09:00performante que a versão menos otimizada do compilador GCC. Portanto, parece que os desenvolvedores
00:09:05não perderão seus empregos tão cedo, ou pelo menos não por enquanto.