Você aprovou. Mas revisou? Quanto Rust é preciso saber pra revisar o código da IA

PRs de agente de IA são aceitos em 18 minutos de mediana, e metade entra sem nenhuma alteração. Em Rust, o compilador faz boa parte da revisão, e é justamente isso que torna o carimbo perigoso. O que os estudos dizem sobre o nível necessário pra revisar de verdade.

Uma provocação antes de começar: da última vez que você aprovou um PR que a IA escreveu, você teria conseguido escrever aquele código sozinho? E, se não teria, o que exatamente você revisou?

No texto anterior o argumento foi que Rust é a linguagem certa pra parear com um gerador probabilístico, porque o compilador vira uma malha que devolve o erro ao modelo antes de ele virar incidente. Este texto é o outro lado da mesma moeda. Justamente porque o compilador do Rust pega tanta coisa, o código que chega até você já compila, já passa no borrow checker, parece idiomático. E aí fica fácil achar que não sobrou nada pra revisar. Sobrou, e é exatamente a parte que exige saber Rust.

Hoje a revisão de código de IA é, em boa parte, um carimbo

Um estudo de 2025 sobre o dataset AIDev (Li, Zhang e Hassan) mediu PRs abertos por agentes em projetos reais do GitHub. Os PRs aceitos do Codex foram fechados numa mediana de 0,3 hora (18 minutos), contra 3,9 horas dos PRs humanos. Os próprios autores levantam a dúvida sobre a profundidade dessa revisão. Outro estudo, com 567 PRs do Claude Code em 157 projetos, achou 83,8% mergeados, e 54,9% desses sem nenhuma modificação.

Pode ser que o código fosse bom. O problema é que a literatura sobre revisão humana diz que a gente não é bom em descobrir se ele é. A Microsoft analisou 1,5 milhão de comentários de revisão (Bosu, Greiler e Bird, MSR 2015): revisores que nunca tinham mexido no arquivo produziram 32-37% de comentários úteis; os que já conheciam o código chegaram a 65-71%. Outro estudo interno da Microsoft tem um título que dispensa resumo: Code Reviews Do Not Find Bugs (Czerwonka et al., ICSE 2015) — só cerca de 15% dos comentários apontam um possível defeito. E revisão de segurança é pior ainda: num experimento em Berkeley (Edmundson et al., 2013), 30 desenvolvedores revisaram uma aplicação com 7 vulnerabilidades conhecidas. Nenhum achou todas, a média foi 2,33, e mais experiência não significou revisão melhor.

Some a isso o que acontece com quem usa IA. No estudo de Stanford (Perry et al., CCS 2023), quem tinha assistente escreveu código menos seguro e acreditou mais que estava seguro. No RCT do METR de julho de 2025, desenvolvedores experientes ficaram 19% mais lentos com IA e, depois do estudo, ainda achavam que tinham ficado 20% mais rápidos. A percepção de quem revisa não é um bom instrumento de medida.

O que o compilador já revisou por você

É aqui que Rust muda a conversa, pro bem. Se o código não usa unsafe, o compilador garante que não existe use-after-free, data race, ponteiro nulo nem acesso a memória liberada. Isso não é pouco: o Google reporta que mudanças em Rust no Android passam 25% menos tempo em revisão que as de C++, com cerca de 4x menos rollback. Na pesquisa interna do Google com mais de 1.000 desenvolvedores, mais da metade disse que código Rust é muito fácil de revisar, e mais de dois terços se sentiam confiantes pra contribuir numa base Rust em até dois meses.

Ou seja: pra revisar Rust seguro, a barreira de entrada é baixa. E é essa a armadilha. O que sobra pra você revisar não é o que o compilador pega. É o que ele não pega.

O que sobra: a lista que o revisor precisa conhecer

Cruzando os estudos sobre Rust gerado por LLM com a documentação oficial da linguagem, dá pra montar a lista do que passa pelo compilador e chega no seu PR:

  • Panic como queda de serviço. Em 18 de novembro de 2025, a Cloudflare ficou fora do ar por quase seis horas. A causa foi um .unwrap() num proxy escrito em Rust: um arquivo de configuração passou do limite de 200 itens pré-alocados, o Result voltou Err, e o processo entrou em panic. Compilou. Passou no borrow checker. unwrap() é exatamente o tipo de coisa que um modelo usa pra fazer o código compilar rápido.
  • Overflow de inteiro silencioso em produção. Em modo debug, Rust dá panic em overflow. Em release, o padrão do Cargo é overflow-checks = false e o número simplesmente dá a volta (wrapping). O próprio Rust Book diz que depender disso é erro. O SafeTrans, que traduziu 2.653 programas de C pra Rust com LLM, achou que só 0,15% das traduções corretas usavam aritmética checked_*, e que o overflow do C original costuma passar direto pra versão em Rust.
  • Deadlock. O Rust Book é explícito: Mutex<T> traz risco de deadlock, e Rust não protege contra todo tipo de erro de lógica.
  • Async que compila e está errado. A documentação do Tokio lista operações que não são seguras contra cancelamento dentro de select! (read_exact, write_all, Mutex::lock e outras podem perder dados ou a posição na fila). Segurar um MutexGuard da std através de um .await compila, e segundo a própria doc do Tokio praticamente nunca resulta em código concorrente correto.
  • Dependência que não existe, ou que existe e é maliciosa. Um estudo de 2026 mediu que modelos alucinam nomes de crates em cerca de 22% dos casos, e que RAG e autorrevisão melhoram isso só 1 a 3 pontos. E o crates.io já teve typosquatting real: em setembro de 2025, faster_log e async_println roubavam chaves privadas de carteiras cripto em tempo de execução, com milhares de downloads.
  • API que mudou. No RustEvo², modelos acertam 56% das tarefas com APIs anteriores ao corte de treinamento e só 32,5% com APIs posteriores. O código usa uma assinatura que existia, ou que o modelo acha que existe.
  • Lógica de negócio. No Rust-SWE-bench (ICSE 2026), o melhor agente de base resolveu 21,2% de 500 tarefas reais. Num estudo de criptografia em Rust gerada por IA, só 23,3% das 240 amostras compilavam, e 57% das que compilavam tinham vulnerabilidade, principalmente reuso de nonce. O tipo não sabe o que o seu sistema deveria fazer.

Nada disso é exótico. É Rust intermediário. Mas é exatamente o conhecimento que você não tem se só aprovou o que o compilador já tinha aprovado.

E aí tem o unsafe, que é outro nível

As organizações que levam isso a sério não tratam revisão de Rust como uma competência só. Tratam como duas. O padrão de auditoria de crates do Google diz que os critérios pra código sem unsafe podem ser revisados por um engenheiro generalista; os níveis que envolvem unsafe exigem “expertise em Rust unsafe”, e a aprovação costuma envolver treinamento e acompanhar revisores experientes. No Chromium, todo código unsafe precisa do LGTM de alguém de uma lista nomeada de donos. O cargo-vet da Mozilla, no critério safe-to-deploy, exige que o auditor raciocine completamente sobre o comportamento de cada bloco unsafe.

O motivo é um detalhe que pega até gente experiente. Ralf Jung, um dos pesquisadores que mais estudam a semântica do Rust, mostrou em 2016 que não basta revisar o conteúdo dos blocos unsafe: uma função segura que faz self.len += 2 dentro do módulo do Vec já basta pra causar comportamento indefinido. O Rustonomicon diz o mesmo: código unsafe que depende de invariantes de um struct “contamina o módulo inteiro”. Ou seja, um diff sem nenhum unsafe pode quebrar a segurança se tocar num módulo que tem unsafe. O Miri, a ferramenta oficial que detecta comportamento indefinido, avisa na própria documentação que não pega tudo, porque testa uma execução entre muitas possíveis.

E os modelos vão pro unsafe exatamente quando empacam. Um artigo de 2026 sobre tradução C→Rust registra que LLMs tendem a recorrer a blocos unsafe ou ponteiros crus pra silenciar erros do borrow checker. No SafeTrans, mesmo com instrução explícita pra gerar Rust seguro, uma parte das traduções ainda saiu com unsafe. E as ferramentas automáticas de análise (Rudra, Miri) não reportaram nada em casos em que a revisão manual achou problema.

Não é um problema de iniciante: o Rudra (SOSP 2021) varreu todo o crates.io e achou 264 bugs de memória novos, muitos escritos por especialistas, alguns na própria biblioteca padrão.

Então, quanto Rust você precisa saber?

Juntando tudo, a resposta tem três degraus, e cada um tem um limite honesto:

  1. Pra aprovar Rust seguro que só mexe em lógica de aplicação: o suficiente pra conhecer a lista acima. Saber por que unwrap() num caminho de produção é uma escolha, e não um detalhe. Saber que as u32 trunca, que release não checa overflow, que .await com lock segurado é bug. Pelos dados do Google e da pesquisa de Fulton et al. (SOUPS 2021), isso é de semanas a poucos meses de estudo sério pra quem já programa. Mas é estudo, não exposição.
  2. Pra aprovar código async ou concorrente: entender o modelo de cancelamento do runtime que você usa. Isso não vem do compilador, vem da documentação do Tokio lida de verdade.
  3. Pra aprovar qualquer unsafe, ou qualquer diff num módulo que tem unsafe: expertise que o Google e o Chromium tratam como credencial separada. Se você não sabe explicar o que é soundness e por que um comentário // SAFETY: precisa provar cada premissa, você não está qualificado pra aprovar aquele diff — e tudo bem, a maioria dos engenheiros não está. A resposta certa aí não é aprender em uma tarde. É não aceitar unsafe de IA.

A provocação volta: a régua não é “eu conseguiria ter escrito isso”. É “eu consigo dizer o que acontece com esse código quando a entrada é hostil, o lock está contido, o Result vem Err e a conta dá a volta”. Se a resposta for não, você não revisou. Você carimbou.

Por que isso fica pior com o tempo, não melhor

Em 1983, Lisanne Bainbridge publicou Ironies of Automation, um artigo de quatro páginas que continua valendo. A ironia central: o sistema foi automatizado porque faz melhor que o operador, e ainda assim pedem ao operador que o vigie. Os operadores de hoje estão vivendo das habilidades que construíram antes, e as próximas gerações não vão tê-las. Parasuraman e Manzey (2010) mediram a outra metade: complacência com automação aparece em novatos e especialistas, e não se resolve com treino nem instrução.

A Anthropic publicou em janeiro de 2026 um RCT com 52 desenvolvedores aprendendo uma biblioteca nova: quem usou IA teve 50% de acerto no teste de compreensão, contra 67% de quem codou à mão, e a maior diferença foi justamente em debugging. Os autores resumem que produtividade com IA não é atalho pra competência. Se o revisor de amanhã aprendeu Rust aprovando PR de IA, ele não aprendeu o que precisava pra revisar PR de IA.

Até os fornecedores dizem isso. A OpenAI, no lançamento do Codex, disse que continua essencial revisar e validar manualmente todo código gerado pelo agente. A documentação do Claude Code tem uma frase mais seca: se você não consegue verificar, não entregue.

O que dá pra fazer, e o que estamos fazendo

Revisão humana sozinha não segura. O que segura é tirar da mesa o que dá pra tirar por máquina, e concentrar a atenção humana no resto. Em Rust, isso é barato:

  • unsafe_code = "forbid" no workspace. Se a IA precisar de unsafe, o compilador recusa e um humano qualificado decide.
  • overflow-checks = true no perfil de release, ou aritmética checked_*/saturating_* explícita onde importa.
  • Lints do Clippy unwrap_used e expect_used como erro em código de produção, pra que cada panic seja uma decisão escrita e não um atalho.
  • cargo-deny e cargo-audit no CI, pra que crate alucinada ou comprometida não chegue ao revisor.
  • E um dado do Braz et al. (ICSE 2022) que vale pra qualquer linguagem: só pedir explicitamente ao revisor que olhe segurança multiplicou por oito a chance de ele achar a vulnerabilidade. Checklist não somou nada. Atenção direcionada somou.

Sendo transparente: o nosso motor de backend em Rust, que começamos neste mês com a IA escrevendo boa parte do código, já nasceu com unsafe_code = "forbid" e cargo-deny. Uma das exceções no deny.toml é um bom exemplo do tipo de revisão que nenhum compilador faz: um alerta de segurança num crate de RSA foi ignorado porque o sistema só assina com EdDSA, e esse raciocínio está escrito do lado da exceção pra ser reavaliado. Mas escrever este texto mostrou dois buracos: o perfil de release ainda não liga overflow-checks, e unwrap ainda não é proibido por lint. Vamos corrigir os dois.

Se você aprova código de IA em Rust hoje: o compilador é o melhor revisor júnior que já existiu, e ele não se cansa depois do décimo PR. Mas ele não sabe o que o seu sistema deveria fazer, não sabe que o release desliga a checagem de overflow, e não sabe que o crate que a IA importou foi publicado semana passada por alguém que você não conhece. Essa parte é sua. Se você não sabe Rust o bastante pra fazê-la, a pergunta honesta não é se a IA escreve bem. É quem, de fato, revisou.

Fontes

Este texto foi escrito em conjunto por Alvaro Lopes e o Claude Code. A pesquisa foi feita por agentes de IA, e cada número foi conferido na fonte primária antes de entrar aqui. A provocação vale pra nós também: um humano leu tudo antes de publicar.