Um mês de discussão termina numa frase

A 5 de agosto de 2026, as equipas que mantêm o compilador Rust, a biblioteca padrão, o sistema de tipos, o rustdoc e o bootstrap publicaram uma política formal sobre o uso de LLM no monorepo rust-lang/rust, encerrando mais de um mês de debate interno que chegou a cerca de 3000 mensagens no chat Zulip do projeto. A mudança chegou como um pull request ao repositório de governação rust-lang/rust-forge, escrito por Jynn Nelson (conhecido no Zulip e no GitHub como jyn514), o mesmo repositório que já documenta como o projeto revê, testa e entrega o compilador de que depende uma grande parte do software crítico para a segurança de memória em todo o mundo.

A publicação de anúncio do Inside Rust resume o resultado numa frase: 'É correto usar LLM para responder a perguntas, analisar, resumir, refinar, verificar, sugerir, rever. Mas não para criar.' Essa frase é a política. Tudo o resto no documento aplica a mesma ideia a um elemento concreto de cada vez: um comentário de documentação, um comentário de segurança, uma descrição de pull request, uma revisão de código.

A linha está na autoria do commit

A regra que sobreviveu a cerca de 3000 mensagens no Zulip traça a sua linha na autoria do commit, e não no uso da ferramenta em si. Os colaboradores da Rust podem usar um LLM para ler código, analisar um erro, resumir uma longa discussão ou entender como funciona um subsistema, e nada disso exige divulgação. No momento em que a saída de um LLM se torna código que fica num pull request integrado, a política trata-o como proibido por defeito.

A exceção restrita é acordada com antecedência e totalmente testada: um colaborador que queira fazer o commit de código escrito por um LLM tem de acordar o alcance com os revisores com antecedência, e o patch resultante tem de atingir o mesmo nível de qualquer alteração escrita por uma pessoa, sem atalhos por ter sido gerado por máquina. Fora desse acordo, um patch de IA não revisto não é integrado, sejam quais forem os testes que afirme passar no seu próprio branch.

Comentários de documentação e de segurança seguem a mesma regra

A política alarga a proibição de escrita à prosa que rodeia o código, e não apenas ao código em si. Comentários de documentação, comentários de segurança, descrições de pull request e textos públicos de issues gerados por um LLM têm de ser declarados como gerados por máquina ou ficam proibidos sem exceção, porque um comentário de segurança em Rust unsafe é uma afirmação em que um revisor confia, e uma afirmação de IA não declarada sobre porque é que um bloco de código unsafe é seguro é exatamente a falha que toda a política existe para evitar.

O pull request no rust-lang/rust-forge que traz a mudança descreve-a como escrever melhor, e não mais rápido: o objetivo não é atrasar os colaboradores por atrasar, mas manter cada frase em que um revisor confia rastreável a uma pessoa que responde por ela. Um rascunho de IA declarado que uma pessoa depois reescreve e assume é tratado de forma diferente de um não declarado apresentado como prosa original.

As revisões de IA são consultivas, nunca um travão ao merge

As revisões de código geradas por IA são explicitamente consultivas segundo a nova política, e nenhuma pode, por si só, travar ou aprovar um merge. Um bot ou o assistente de IA de um colaborador pode assinalar um erro, sugerir uma reestruturação ou apontar um teste em falta, mas a aprovação que efetivamente desbloqueia um pull request tem de continuar a vir de um revisor humano que aplique os padrões de revisão existentes do projeto.

Essa distinção pesa mais num compilador e numa biblioteca padrão do que em quase qualquer outro ponto do software, porque uma regressão de segurança de memória aqui não fica contida numa única aplicação - propaga-se a jusante a cada crate e a cada binário construído sobre Rust. Tratar uma revisão de IA como uma sugestão e não como um travão mantém a responsabilidade por aquilo que é integrado numa pessoa identificada, sempre.

Porque é que esta linha importa além de um projeto

A Rust sustenta uma parte desproporcionada das bases de código fintech, automóvel e embutido da UE e do Reino Unido, da fintech lisboeta à indústria automóvel europeia que atravessa fronteiras, precisamente por causa das garantias de segurança de memória que a linguagem impõe já na compilação - exatamente a propriedade que um patch gerado por IA e não revisto poderia minar em silêncio se passasse pela revisão. Uma organização que depende de infraestrutura baseada em Rust e que, em silêncio, baixa o seu próprio nível de revisão para código assistido por IA tem agora um ponto de referência concreto para se medir, publicado por escrito por quem mantém essa dependência.

A maioria das empresas escreve orientações informais sobre o uso de IA que ninguém faz cumprir. A política da Rust destaca-se porque traça a sua linha num ponto concreto e verificável: a autoria do commit. Uma equipa que auditar as suas próprias regras deve fazer a si mesma a mesma pergunta restrita a que a rust-lang acabou de responder: uma alteração escrita por IA chega a um merge sem uma pessoa que a tenha testado e responda por ela? Um sim honesto significa que a política escrita existe apenas no papel.

Leia a seguir: Falha Squid de 29 anos expõe logins em texto simples  |  A Microsoft Já Limita O Que Os Seus Engenheiros Gastam Em IA