A proposta de política de LLM do Rust traça o limite certo

Um pull request do Rust Forge aberto em 17 de abril de 2026 propõe uma política de uso de LLM para rust-lang/rust. Em 17 de maio de 2026, o pull request ainda estava aberto, com 65 comentários de issue e 284 comentários de revisão; portanto, a proposta ainda não é uma política adotada.¹

Mesmo assim, a proposta já importa porque nomeia o limite que a maior parte das orientações sobre programação com IA evita: LLMs podem ajudar pessoas a pensar, aprender, verificar e experimentar, mas não devem substituir a autoria humana nos pontos em que um projeto preserva julgamento, gosto, responsabilidade e entendimento compartilhado.²

A proposta também combina com as normas já existentes de contribuição do Rust. O guia atual de contribuição do Rust Forge já orienta contribuidores a construir confiança, respeitar o tempo dos revisores, enviar trabalhos que entendem por completo, revisar tudo em detalhe antes do envio e manter comentários concisos.³ A política de revisão do compilador também diz que revisores precisam ter entendimento suficiente do código em revisão e que o tempo de revisão é limitado.⁴ A proposta de LLM torna essas expectativas antigas concretas para trabalhos assistidos por IA.

Resumo

A proposta do Rust permite o uso privado de LLM para aprendizado, resumo, revisão privada, ferramentas pessoais e experimentos.² Ela proíbe comentários públicos, corpos de issue, descrições de pull request, documentação, diagnósticos do compilador e qualquer processo que trate uma revisão feita por LLM como suficiente para mesclar ou rejeitar código.² Também cria um experimento estreito para mudanças de código criadas por LLM: solicitadas, não críticas, divulgadas, de alta qualidade, bem testadas e plenamente compreendidas tanto pelo autor quanto pelo revisor.² Minha leitura: a política funciona porque otimiza para responsabilidade intelectual, não para volume de produção.

Principais pontos

• Para mantenedores: a política deve proteger a capacidade de revisão, a voz do projeto e a responsabilidade antes de falar em produtividade.
• Para equipes de programação com IA: permita amplamente o uso privado, mas estabeleça um limite mais rígido em autoria pública, documentação, diagnósticos e autoridade para mesclar.
• Para contribuidores: a divulgação só ajuda quando o humano ainda assume a responsabilidade pelo trabalho. “O modelo escreveu” não pode virar desculpa.
• Para criadores de ferramentas: bots de revisão precisam de identidades separadas, possibilidade de bloqueio, baixa pressão de falsos positivos e status consultivo.
• Para equipes de agentes: a melhor regra da proposta é cultural, não técnica: use IA para escrever melhor, não mais rápido.²

A proposta separa pensamento de autoria

A maioria das políticas de LLM coloca dois atos diferentes na mesma categoria: usar IA. A proposta do Rust separa o ato em cognição privada e autoria pública.

A cognição privada recebe ampla permissão. Um contribuidor pode fazer perguntas a um LLM sobre a base de código, resumir comentários para entendimento próprio, revisar em privado o próprio código ou texto, criar ferramentas pessoais de desenvolvimento e gerar possíveis soluções para estudar antes de escrever a própria solução.²

A autoria pública recebe o limite rígido. A proposta proíbe comentários publicados por uma conta pessoal quando eles foram originalmente criados por um LLM. A mesma regra vale para corpos de issue e descrições de pull request.² A proposta também proíbe documentação originalmente criada por um LLM, incluindo comentários de código não triviais, comentários de documentação, comentários de segurança, comentários com vários parágrafos e diagnósticos do compilador.²

Essa distinção faz sentido porque artefatos públicos carregam a voz do projeto. Diagnósticos do compilador, comentários de segurança e documentação não apenas transmitem informação. Eles ensinam aos usuários como o Rust pensa. Também passam a fazer parte do custo de manutenção de longo prazo do projeto.

Texto gerado por LLM pode soar polido enquanto enfraquece essa responsabilidade. O revisor agora precisa perguntar: quem escolheu esta formulação, quem entende a implicação, quem assume o caso extremo e quem vai corrigir a confusão depois? A proposta se recusa a permitir que um contribuidor terceirize essa responsabilidade mantendo a credibilidade de uma conta humana.

A regra mais forte: nada de revisão por IA como autoridade para mesclar

A proposta proíbe tratar uma revisão de LLM como condição suficiente para mesclar ou rejeitar uma mudança.² Bots de revisão podem existir, mas a proposta exige que continuem consultivos. Revisores precisam endossar explicitamente um comentário de LLM antes que ele bloqueie um pull request, e autores ainda devem fazer a própria revisão.²

Essa regra evita um modo de falha tentador. Equipes podem adicionar revisão por IA e chamar o fluxo de trabalho de mais seguro, mesmo quando a nova ferramenta só cria uma segunda corrente de afirmações que ninguém tem tempo de avaliar. Um bot pode encontrar bugs reais. Um bot também pode produzir objeções triviais, conselhos de estilo desatualizados, restrições alucinadas ou comentários confiantes sobre código que não entendeu.

A proposta do Rust lida com esse problema estruturalmente:

O ponto não é que revisão por LLM não tenha valor. O ponto é que a autoridade de revisão pertence às pessoas e ao processo do projeto. Uma máquina pode auxiliar o revisor. Ela não pode se tornar a revisora oficial.

A exceção para código é estreita de propósito

A proposta não proíbe todo código criado por LLM. Ela cria um experimento para mudanças de código que atendam a cinco condições: solicitadas, não críticas, de alta qualidade, bem testadas e bem revisadas.²

Cada palavra faz trabalho real.

Solicitadas significa que o revisor concordou previamente em revisar um pull request criado por LLM. Novos contribuidores não podem usar um LLM nesse caminho a menos que conversem primeiro com o mesmo revisor atribuído ao PR.²

Não críticas mantém mudanças criadas por IA longe de áreas em que um erro poderia causar uma regressão de solidez. A proposta cita ferramentas internas como algo mais plausível e áreas como o sistema de traits, a construção de MIR ou o sistema de consultas como provavelmente inadequadas.²

Alta qualidade significa que o código deve atender pelo menos ao mesmo padrão das outras mudanças. A proposta rejeita explicitamente PRs que degradem a qualidade da base de código.²

Bem testadas eleva o nível de exigência. PRs criados por LLM enfrentam uma expectativa maior de testes porque LLMs tornam testes mais fáceis de escrever. Se nenhuma suíte de testes existente cobre o código, o autor precisa escrever uma nova ou fechar o PR.²

Bem revisadas significa que autor e revisor se comprometem a entender completamente o código. A revisão de um membro do projeto não substitui a revisão própria.²

Esse experimento tem um formato útil. Ele não finge que código criado por IA não pode ajudar. Também rejeita a versão preguiçosa de “contribuição assistida por IA”, em que o contribuidor gera um patch, pede aos mantenedores que o decifrem e não dedica esforço humano para entendê-lo.

Melhor, não mais rápido

A frase mais importante da proposta diz que LLMs funcionam melhor quando as pessoas os usam para escrever melhor, não mais rápido.²

Essa frase deveria virar o padrão básico para programação com IA.

Velocidade sozinha desloca trabalho dos autores para os revisores. Um contribuidor economiza uma hora gerando um patch, depois mantenedores gastam três horas separando código útil de testes estranhos, comentários inflados, diagnósticos vagos e decisões de design sem dono. O projeto perde mesmo quando o diff acaba compilando.

Melhor faz outra pergunta: a ferramenta ajudou o humano a formar um entendimento mais preciso? Ela encontrou um caso extremo que o autor verificou? Ajudou a rascunhar um teste que o autor entende? Tornou a contribuição final mais fácil de revisar, manter e confiar?

A proposta do Rust torna essa distinção aplicável. O uso privado de LLM pode melhorar o entendimento do autor. A autoria pública originada em LLM pode degradar o entendimento compartilhado do projeto. Código experimental criado por IA só pode avançar quando solicitação, escopo, qualidade, testes e revisão carregam todo o peso extra.

Essa combinação é melhor que otimismo irrestrito e proibição irrestrita. Ela diz que a tecnologia pode ajudar, mas que o projeto não vai absorver produção sem responsabilidade suficiente só porque um modelo a tornou barata.

A seção de moderação evita caça às bruxas

A proposta também trata a fiscalização com cuidado incomum. Ela diz aos contribuidores que eles não precisam brincar de detetive sobre uso de LLM. Se uma violação parecer clara, aponte para a política. Se o caso parecer limítrofe, reporte aos moderadores e siga em frente.²

A mesma seção trata desonestidade sobre uso de LLM como questão de código de conduta, mas também afirma que assediar contribuidores por usarem LLMs não é aceitável.² Esse par importa. Uma política que incentiva suspeita pode envenenar uma comunidade mais rápido do que o conteúdo gerado por IA que tenta impedir.

Uma boa política de IA precisa de dois limites:

A proposta coloca a responsabilidade no contribuidor sem transformar cada revisor em investigador. Isso protege a cultura de revisão tanto quanto o código.

O que outros projetos deveriam copiar

A proposta do Rust merece atenção porque define papéis, não impressões vagas.

Use LLMs como:

• um tutor privado;
• um revisor privado;
• uma ferramenta de resumo para seu próprio entendimento;
• um auxílio para descoberta de bugs quando o humano verifica o bug;
• uma fonte de experimentos quando o revisor aceita participar e o escopo permanece de baixo risco.

Não use LLMs como:

• o autor público do seu comentário;
• a voz da documentação do projeto;
• o autor de diagnósticos do compilador;
• substituto para revisão humana;
• desculpa para testes que você não escreveu;
• uma forma de fazer mantenedores revisarem código que você não entende.

Essa lista dá aos mantenedores algo melhor que um argumento moral. Dá uma política operacional.

Minha leitura

A proposta combina com o problema de qualidade que a programação com IA cria. Código fica mais barato de produzir. Atenção de revisão, gosto, coerência, voz do projeto e confiança social não ficam mais baratos. A escassez sobe de camada.

Um projeto que otimiza para volume de produção vai afogar seus mantenedores em diffs plausíveis. Um projeto que otimiza para responsabilidade ainda pode usar IA, mas apenas de formas que tornem o autor humano mais capaz e o revisor menos sobrecarregado.

A proposta do Rust protege a camada escassa. Ela trata diagnósticos, comentários, documentação e autoridade de revisão como parte do projeto, não como texto intercambiável. Trata testes e revisão própria como obrigações, não acessórios. Dá um caminho para experimentação, mas não um cheque em branco.

Essa é a direção certa para projetos de software sérios. As regras exatas podem mudar antes que o Rust adote qualquer coisa. O formato de fundo não deveria mudar: IA pode ajudar pessoas a fazer um trabalho melhor, mas o humano ainda precisa assumir a contribuição.

FAQ

Esta política do Rust foi adotada?

Não. Em 17 de maio de 2026, a política existia como um pull request aberto do Rust Forge intitulado “Add an LLM policy for rust-lang/rust.” O branch main atual de rust-lang/rust-forge ainda não contém src/policies/llm-usage.md.¹⁵

A proposta proíbe todo uso de IA?

Não. A proposta permite condicionalmente o uso privado de LLM para aprendizado, resumo, revisão, ferramentas pessoais e geração de ideias. Ela também cria um experimento estreito para código criado por LLM que seja divulgado, solicitado, não crítico, de alta qualidade, bem testado e bem revisado.²

O que a proposta proíbe?

A proposta proíbe comentários públicos originados em LLM, corpos de issue, descrições de pull request, documentação, diagnósticos do compilador e tratar revisão por LLM como suficiente para mesclar ou rejeitar código.²

Por que a proposta trata documentação e diagnósticos com tanta rigidez?

Documentação e diagnósticos carregam a voz do projeto, orientação ao usuário e obrigações de manutenção de longo prazo. A proposta permite que LLMs auxiliem a lógica ao redor em alguns casos, mas impede que LLMs criem as mensagens em si.²

O que equipes de programação com IA devem aprender com a proposta?

Separe assistência privada de autoria pública. Exija divulgação quando IA afetar outras pessoas. Mantenha humana a autoridade de revisão. Eleve o padrão de testes e revisão própria quando IA ajudar a criar código. Otimize para trabalho melhor, não para mais produção.

Referências