$20.000. 2 Semanas. 16 Agentes Claude. O Primeiro Compilador C da Anthropic Feito por IA

BBetter Stack
컴퓨터/소프트웨어경제 뉴스게임/e스포츠AI/미래기술

Transcript

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.

Key Takeaway

Embora a criação de um compilador C por agentes de IA seja um marco técnico impressionante, o sucesso do experimento dependeu criticamente de uma infraestrutura humana complexa e do uso de ferramentas de software já existentes como referência.

Highlights

A Anthropic utilizou 16 agentes Claude (Opus 4.6) operando 24 horas por dia durante duas semanas para criar um compilador C.

O compilador desenvolvido foi capaz de compilar o kernel do Linux e rodar o jogo Doom, demonstrando um avanço significativo em relação às versões anteriores.

A arquitetura do experimento envolveu containers Docker isolados e um sistema de 'bloqueio de tarefas' para evitar conflitos entre os agentes.

Nicholas Carlini implementou estratégias astutas, como o uso de um 'oráculo' (GCC) para identificar bugs e suítes de testes aleatórios e determinísticos.

A autonomia do projeto é questionada devido ao pesado direcionamento humano na criação do ambiente, definição de papéis e infraestrutura de testes.

O compilador resultante apresentou limitações técnicas, como a dependência do montador e linker do GCC e uma performance inferior ao padrão da indústria.

Timeline

Introdução e a Grande Conquista da Anthropic

O vídeo inicia apresentando o ambicioso projeto da Anthropic, onde 16 agentes Claude trabalharam ininterruptamente por duas semanas. O objetivo principal foi a construção de um compilador C funcional, algo anteriormente impossível para modelos de IA. O resultado foi surpreendente, permitindo a compilação do kernel do Linux e a execução do clássico jogo Doom. No entanto, o narrador introduz uma nota de ceticismo, mencionando que a comunidade debate se houve 'trapaça' ou uso de técnicas questionáveis. Este segmento estabelece o tom crítico da análise sobre a validade dos resultados apresentados.

Configuração Técnica e Arquitetura dos Agentes

Nesta parte, o experimento conduzido por Nicholas Carlini é detalhado, focando na infraestrutura de containers Docker e no repositório 'Upstream'. Cada um dos 16 agentes operava em um ambiente isolado para evitar interferências diretas no trabalho dos outros, resolvendo conflitos de merge via Git quando necessário. Uma técnica inovadora de 'travamento de tarefas' foi utilizada, onde arquivos de texto serviam como sinalizadores para garantir que dois agentes não trabalhassem no mesmo problema. O uso de loops 'Ralph' permitiu que os agentes mantivessem sessões limpas e foco em tarefas bem definidas. Essa organização foi fundamental para permitir a operação de longa duração dos modelos de linguagem.

Estratégias de Teste e o Uso do Oráculo GCC

O vídeo descreve como Carlini otimizou o processo de desenvolvimento através de um robusto arcabouço de testes. Para lidar com a tendência da IA de quebrar recursos antigos ao adicionar novos, foram integrados testes de projetos renomados como SQLite e Redis. Uma solução criativa foi a implementação de uma flag 'fast', permitindo que cada agente rodasse apenas uma fração dos testes de forma determinística, economizando tempo precioso. O ponto mais polêmico surge aqui: o uso do GCC como um 'oráculo' para validar partes da compilação do kernel do Linux. Isso permitiu aos agentes isolar erros específicos em seu próprio código, comparando os resultados com um compilador já perfeito.

Gestão de Memória e Especialização de Papéis

Para mitigar a falta de memória entre sessões limpas, Carlini instruiu os agentes a atualizarem arquivos README e relatórios de progresso constantemente. Isso garantiu que novas sessões do Claude tivessem contexto sobre o que já havia sido feito e quais bugs foram corrigidos anteriormente. Além da codificação, os agentes receberam papéis especializados, atuando como revisores de código, otimizadores de performance e até críticos de design sob a perspectiva de desenvolvedores Rust. Essa diversificação de funções permitiu uma abordagem multifacetada para o refinamento do compilador. O uso de múltiplos agentes em paralelo mostrou-se uma forma eficiente de atacar diferentes frentes de um projeto complexo simultaneamente.

Análise Final: Autonomia vs. Intervenção Humana

A conclusão do vídeo avalia se a Anthropic 'trapaceou', ponderando o nível de autonomia real dos agentes Claude. Embora a IA tenha gerado o código, ela o fez sob um direcionamento humano extremamente rigoroso que definiu toda a lógica do sistema e do ambiente de testes. O compilador final ainda apresentou dependências críticas de ferramentas externas, como o montador e o linker do próprio GCC, e falhou em superar a eficiência do software tradicional. O narrador observa que a performance da versão mais otimizada da IA ainda é inferior à versão básica do GCC. Em última análise, o experimento sugere que, embora a IA seja uma ferramenta poderosa, os desenvolvedores humanos continuam essenciais para o design e supervisão de sistemas complexos.

Community Posts

View all posts