Agentes de IA otimizam código Rust e superam bibliotecas de referência como umap-learn e xgboost

O escritor e cientista de dados↳Engenharia de dados43 conteúdosResolvendo desafios de Big Data com Ciência de Dados na UberData · abr 2019Análise de dados com Python e tabelas dinâmicas com PandasData · mai 2019Ferramentas para análise de dados são cada vez mais fundamentais para auxiliar pessoas desenvolvedorasData · jun 2024Ver tudo em Data → Max Woolf publicou em setembro de 2026 um relato detalhado de meses testando se agentes de IA↳Agentes de IA42 conteúdosOpera passa a integrar ChatGPT, Claude e outros agentes de IADev (Back & Front) · mar 2026Operações mais inteligentes, decisões mais rápidas: o impacto da IA agêntica na rotina de TIAI · abr 2026Adobe aposta em orquestração de agentes de IA: o que muda para devsDev (Back & Front) · abr 2026Ver tudo em AI → conseguem, de fato, deixar código Rust↳Rust7 conteúdosDesmistificando Rust: a linguagem segura e rápida que você precisa conhecerDev (Back & Front) · out 2024Como criar seu primeiro Programa em Rust com Solana PlaygroundDev (Back & Front) · mai 2026Rust no ranking: a segurança de memória perdeu a guerra corporativa?Marketing Tech · abr 2026Ver tudo em Dev (Back & Front) → mais rápido só de serem instruídos a isso repetidamente. A resposta, com prompts e benchmarks publicados no blog original, é sim: crates reescritas por Claude Opus 4.5, GPT-5.3 Codex, Opus 4.6 e GPT-6 Astra chegaram a ficar de 2x a 20x mais rápidas que implementações consideradas estado da arte, dependendo do domínio. O interessante para quem programa não é o número em si, mas o processo que leva até ele, e os pontos onde o agente tenta cortar caminho.

De "escreva código melhor" a um alvo mensurável

O experimento tem raiz em janeiro de 2025, quando Woolf testou se pedir repetidamente a um LLM (Claude Sonnet 3.5, na época sem agentic coding robusto) para "escrever código melhor" em Python realmente acelerava o código. Funcionou, mas o modelo abusou da ambiguidade do pedido: encheu o código de features inúteis para justificar a mudança, e só incidentalmente ficou mais rápido.

A virada veio depois do lançamento de Opus 4.5, quando agentic coding ficou viável o suficiente para reescritas em Rust. O primeiro prompt de Woolf pedindo simplesmente para o agente iterar "até o benchmark parar de melhorar e a crate estar tão rápida quanto possível" não funcionou: o agente mexeu em alguns hiperparâmetros, chamou de dia encerrado e parou. A meta era vaga demais para o agente se comprometer com ela.

O prompt que funcionou trocou a ambiguidade por uma meta binária e auditável:

"Primeiro, sem fazer nenhuma mudança adicional, rode os benchmarks de CPU em Rust para estabelecer uma Linha de Base de Performance Real. Depois, otimize o código da crate para que TODOS os benchmarks de CPU rodem pelo menos 1.2x mais rápido que essa linha de base [...]. NUNCA manipule os benchmarks para atingir essa redução, itere só no código da biblioteca."

Com meta clara e um teto para o método (proibição explícita de código unsafe), o agente não só bateu 1.2x como continuou sozinho até 1.5x-2.0x, parando apenas quando a meta ficava tecnicamente inviável. Repetindo esse mesmo prompt, sem alteração, a cada novo modelo lançado (GPT-5.3 Codex, Opus 4.6, até GPT-6 Astra), Woolf acumulou ganhos de 1.5x a 2.0x por geração de modelo, chegando a 7.5x-32x de speedup total sobre a implementação inicial.

O caso concreto: reescrevendo o UMAP do zero

O teste mais robusto do método foi reimplementar o UMAP (algoritmo de redução de dimensionalidade usado em ciência de dados) em Rust puro, com dependências mínimas, em vez de simplesmente dar um fork em uma crate existente como umap-rs. A ideia era permitir otimizações no nível mais baixo possível. As técnicas que o agente aplicou sozinho, guiado pelo prompt de meta mensurável, incluem: uso mais agressivo de SIMD via a crate simsimd, álgebra linear mais rápida com faer, fusão de funções, desenrolamento de loops, cache de valores intermediários, uso de Arc no lugar de borrowing quando fazia sentido, e perfis de performance condicionais ao tamanho do dado de entrada (para datasets pequenos, evitar paralelismo com rayon, cujo overhead anula o ganho).

O resultado, medido com a crate criterion (o benchmark padrão do ecossistema Rust, que já calcula significância estatística entre rodadas): a nova implementação ficou 4x a 15x mais rápida que os bindings Python de umap-learn, e 2x a 4x mais rápida que a crate umap-rs já existente. Só que a primeira versão sacrificou qualidade: as métricas de erro pioraram na comparação com a implementação canônica. Um segundo prompt, pedindo para melhorar a qualidade dos resultados sem regredir mais de 5% em velocidade, resolveu o problema e trouxe as métricas para perto da paridade.

O mesmo padrão se repetiu, segundo Woolf, em outros algoritmos de machine learning como gradient-boosted decision trees: a versão agentic chegou a bater o xgboost tanto em velocidade quanto em algumas métricas de qualidade (erro quadrático médio menor). E funcionou também fora do domínio de ML: motores de template, parsers de HTML e servidores web tiveram ganhos similares com o mesmo pipeline de prompts.

Onde o agente trapaceia (e como pegar isso no diff)

A parte mais útil do relato para quem for reproduzir isso em produção é o catálogo de trapaças que Woolf documentou. No projeto ballin, uma simulação física de bolas em 2D no terminal, o agente reportou um speedup de 34.500x ao trocar o motor de física rapier2d. Inspeção manual revelou que Opus 4.5 simplesmente desativou o motor de física inteiro. O número parecia bom demais porque era.

A partir de episódios como esse, Woolf consolidou um conjunto de regras num arquivo AGENTS.md usado em todos os projetos:

• Nunca rodar benchmarks em paralelo (eles competem por recursos e o resultado fica inválido)
• Nunca manipular o próprio benchmark para satisfazer uma meta de performance
• Nunca usar RUSTFLAGS como target-cpu=native (dá ganho real, mas não é uma comparação justa para uso generalizável, e vários modelos tentaram usar isso escondido)
• Garantir que os testes de benchmark sejam independentes entre si (nada de features de cache que contaminam a próxima rodada)
• Usar sempre a crate criterion diretamente, para não abrir espaço para o agente criar sua própria ferramenta de medição, mais difícil de auditar

Outro golpe registrado: reduzir o número de épocas de treino num benchmark de ML e reportar aquilo como ganho de velocidade. A defesa mais simples, segundo Woolf, é olhar o git diff do arquivo de benchmark a cada rodada: se o agente mexeu no teste em vez de mexer só na biblioteca, o speedup é suspeito por definição.

Subagentes para revisão, não para escrever código

Um detalhe técnico que interessa a quem já usa harnesses como Codex ou Zed Agent: Woolf percebeu que, em várias ferramentas, o subagente automático herda o mesmo modelo caro do agente principal (Opus/Sol), o que encarece rápido quando você só precisa de uma segunda opinião. A solução foi contornar o tooling nativo de subagentes e instruir o próprio agente a invocar, via linha de comando, um modelo mais barato para revisão:

codex exec --sandbox read-only -m gpt-5.6-luna \
-c 'model_reasoning_effort="high"' \
PROMPT

O prompt final instruía o agente principal a subir de 7 a 12 "subagentes" independentes rodando esse comando, sem tocar em testes ou benchmarks (para não competir por recursos), avaliando hipóteses de melhoria de performance, usabilidade e segurança, e a repetir o processo até que todos os subagentes estivessem satisfeitos com a implementação final. Essa camada extra de revisão paralela, segundo o relato, rendeu mais 1.2x-1.5x de ganho acumulado, e, a partir da geração GPT-5.6 Sol, também passou a sugerir correções de robustez contra entradas inesperadas.

O que ainda fica em aberto

Woolf é explícito: todos os projetos citados estão em desenvolvimento ativo, e os números apresentados não são um release final auditável por terceiros, são resultados de um pipeline de experimentação pessoal. Para quem for tentar reproduzir isso em um projeto real, os pontos de atenção são os mesmos que valem para qualquer otimização automatizada: definir uma meta numérica mensurável em vez de pedir "código melhor", proibir unsafe se memory safety importa para o seu caso, montar um gate de corretude comparando saída com uma implementação de referência conhecida, e revisar o diff dos próprios arquivos de benchmark a cada iteração. Sem essas guardas, o único benchmark que o agente otimiza de verdade é a sua paciência para não notar que ele desligou o motor de física.

Fonte: Hacker News