Dois mil agentes se reescrevem em duas semanas: como o Prime Agent levou TypeScript para Rust

Um exército de dois mil, e nenhum é humano

O Prime Agent, o agente de programação lançado oficialmente só em agosto de 2026, acumulou em dois meses mais de 300 mil downloads e processou mais de 8 trilhões de tokens. Em 9 de outubro, sua desenvolvedora Prime Intellect anunciou algo ainda mais chamativo: a ferramenta foi reescrita por ela mesma. A passagem de TypeScript para Rust foi concluída em duas semanas, e quem fez o trabalho foram mais de dois mil agentes autônomos.

Não é o bordão de "a IA escreve o código por você". Durante toda a portabilidade, a equipe humana fez sobretudo uma coisa: montar os critérios de aceitação para que os agentes pudessem medir sozinhos se tinham feito certo. O resto, orquestração, escrita do código, revisão e verificação, foi entregue às máquinas.

Custo e escala: mover 200 bilhões de tokens

Segundo o blog oficial, essa reescrita mobilizou mais de 2.000 agentes trabalhando em paralelo em mais de 10.000 sandboxes do Prime, consumindo mais de 200 bilhões de tokens do endpoint GLM-5.3 do Prime Inference. A fase que de fato escreveu Rust foi concluída por 1.981 agentes, com cerca de 192,99 bilhões de tokens; a fase seguinte, de três dias de subida de desempenho, somou outros 228 agentes e cerca de 35,7 bilhões de tokens.

Esses números são, por si só, um sinal. O fato de o modelo aberto GLM-5.3 se tornar o motor de inferência principal de um enxame de agentes de nível de produção não é a mesma coisa que "um modelo ganhou mais um ponto em um benchmark". Mostra que, em cenários de engenharia longos, de grande volume e que exigem chamadas de ferramentas estáveis, o custo-benefício dos modelos de pesos abertos já é aceitável para projetos reais.

Orquestração: o agente raiz não escreve código de produto

O que mais vale copiar não é "usou dois mil agentes", mas a forma como eles dividiram o trabalho. Toda a reescrita foi dirigida por um único agente raiz, que por sua vez não escreveu uma linha sequer de código de produto. Ele fazia só três coisas: dividir as tarefas em um grafo com ordem topológica, acompanhar o progresso de cada tarefa e mesclar o trabalho concluído.

Cada tarefa passa por quatro papéis, em sequência:

• Planejador: escreve a especificação, o design da funcionalidade e a "resposta de referência", esta última tirada diretamente do comportamento existente da versão TypeScript.
• Implementador: escreve o código Rust em um worktree separado, para que funcionalidades diferentes avancem em paralelo.
• Revisor: troca de modelo e de contexto para procurar, de forma adversarial, os defeitos dessa mudança.
• Verificador: compila o código e roda testes de consistência em um sandbox totalmente novo.

Se a revisão ou a verificação falhar, a tarefa volta ao implementador com as conclusões. Só quando as duas passam é que a mudança pode ser mesclada. A Prime Intellect separou de propósito "geração" e "avaliação", por um motivo direto: se você deixa o agente que escreveu o código julgar o próprio resultado, ele naturalmente vai pender para si mesmo.

As verdadeiras proteções: quatro tipos de checagem de consistência

Só o processo não basta; também são necessários critérios objetivos de certo e errado. A equipe montou quatro tipos de checagens de paridade, cobrindo facetas distintas da mesma funcionalidade:

• Testes diferenciais de TUI: rodar os dois binários, TypeScript e Rust, sob o mesmo modelo com script, comparando a tela do terminal quadro a quadro, cobrindo inicialização, menus, chamadas de ferramentas, retomada de sessão, subagentes e recuperação de falhas.
• Consistência do harness: comparar as transcrições de sessão geradas por cada lado e as requisições que cada um envia ao provedor do modelo.
• Consistência do protocolo: verificar cada tipo de mensagem do protocolo do daemon contra a implementação em TypeScript.
• Auditoria funcional: onde os scripts não chegam, os agentes conferem componente por componente e marcam cada um como "consistente", "parcialmente consistente" ou "ausente".

Com essas réguas objetivas, os agentes conseguem julgar o próprio progresso e barrar regressões antes da mesclagem, o que reduz a necessidade de revisão humana. A equipe também é franca: os bugs que escaparam foram aqueles que nenhum teste cobria, e só apareceram com o uso diário interno.

Resultados: inicialização a frio 14 vezes mais rápida, 80% menos memória

Nos dados comparativos oficiais, a latência da inicialização a frio até poder digitar cai de 737,8 milissegundos na versão TypeScript para 55,8 milissegundos, um ganho de 14,18 vezes; a inicialização a quente ganha 13,34 vezes; a memória de toda a árvore de processos cai de 607,4 MB para 106 MB, uma economia de cerca de 80%; e o tamanho de instalação encolhe de 172,1 MB para 59,6 MB. A primeira saída visível chega aos 23,6 milissegundos. A fase de subida registrou 144 experimentos no total e mesclou 69 mudanças válidas. Um alerta: essa comparação lado a lado usa a própria suíte de execução da equipe, e a própria equipe aponta a falta de um benchmark comum, então os números devem ser lidos com cautela.

A mudança estrutural pode durar mais que a velocidade. O código foi dividido em nove crates, com dependências unidirecionais impostas pelo Cargo; o maior arquivo-fonte passou de cerca de 15.000 linhas para cerca de 2.500, e nenhum arquivo ultrapassa mais 5.000 linhas. Cada sessão roda no próprio processo de trabalho, então uma queda não afeta as demais. O suporte a Windows veio como efeito colateral de uma abstração de plataforma mais limpa, e o catálogo de modelos passou a ser buscado em tempo de execução, de modo que um modelo novo já não depende de um lançamento.

Por que Rust

Os pontos de dor do TypeScript listados pela equipe são concretos: os tipos são opcionais e somem em tempo de execução; os erros se propagam como exceções não verificadas; o trabalho que consome CPU, como renderizar e analisar sessões grandes, disputa o mesmo laço de eventos com a digitação; e cada processo precisa carregar um runtime de JavaScript e coleta de lixo. Para um daemon que fica residente e roda um processo de trabalho por sessão, código nativo sem GC é a principal fonte de melhora em memória e tempo de inicialização.

E quando o código é escrito sobretudo pelos agentes, o valor das "garantias em tempo de compilação" se amplifica. Enums exaustivos, posse e tempos de vida, mais os lints rígidos do Clippy, eliminam toda uma classe de bugs antes de o código rodar. Em outras palavras, o compilador assume parte do julgamento que caberia a um revisor humano.

O que isso significa para pessoas diferentes

Se você lidera uma equipe de engenharia, o que dá para reaproveitar não é o número "dois mil agentes", mas o método: primeiro transformar os critérios de aceitação em checagens objetivas e executáveis automaticamente, depois dividir geração e avaliação entre modelos e contextos diferentes, e por fim deixar os agentes avançarem sozinhos dentro das proteções. A Primer Intellect já está transformando esse padrão de quatro papéis em um fluxo de trabalho reutilizável, com o argumento de que uma "fábrica de enxames bem definida" é mais confiável do que montar uma às pressas para cada projeto.

Se você é apenas um usuário comum, isso explica uma coisa: a velocidade de atualização de ferramentas como o Prime Agent vai parecer cada vez menos com a de software tradicional. Quando um produto pode se reescrever, o significado do número de versão muda. É também um lembrete: diante de conclusões como "a refatoração acelerou 14 vezes", vá primeiro à nota de rodapé para ver quem mediu e com o que comparou. Os agentes sabem escrever código útil, mas também sabem escrever elogios confiantes a si mesmos.