Greg Kroah-Hartman, o “segundo em comando” do kernel, afirma que o staging — a porta de entrada de novos desenvolvedores — rejeitará automaticamente código criado por LLMs; medida responde à “enxurrada” de contribuições de IA.

A área de staging do kernel do Linux (drivers/staging/) tem uma nova regra: patches gerados por grandes modelos de linguagem (LLMs), a tecnologia de IA por trás de ferramentas como ChatGPT e Copilot, serão automaticamente rejeitados. O anúncio foi feito na segunda-feira (3) por Greg Kroah-Hartman, mantenedor do subsistema e uma das figuras mais influentes do ecossistema Linux, e prevê uma única exceção: correções de segurança genuínas — desde que testadas em hardware real.

A decisão responde ao aumento recente de contribuições geradas por IA no kernel e reacende um dos debates mais quentes do open source: qual é o papel da inteligência artificial no desenvolvimento colaborativo de software?

Uma “escola” que não pode ser automatizada

Para entender a medida, é preciso entender a função do drivers/staging/. A área existe principalmente como um ambiente de aprendizado: abriga drivers e códigos em transição, repletos de “frutas baixas” — limpezas simples e ajustes de API — perfeitos para que novatos aprendam o processo de desenvolvimento do kernel de forma segura e com revisões amigáveis.

“Não aceitamos patches do tipo ‘corrija todos os problemas de estilo deste arquivo!’ gerados por ferramentas, pois isso derrotaria todo o propósito do drivers/staging”, escreveu Kroah-Hartman. “Qualquer pessoa que tente usar um LLM para ‘limpar’ ou ‘corrigir’ código em drivers/staging/ está explicitamente derrotando a razão de ele existir.”

“É MUITO óbvio” — e tentar enganar tem custo

O mantenedor também deixou um aviso para quem pensa em ocultar o uso de IA: “É MUITO óbvio quando alguém envia um patch gerado por LLM. Não pense que basta não divulgar o uso para ‘se safar’. O objetivo é que as pessoas aprendam, não que tentem ‘enganar’ um mantenedor.”

A exceção: segurança testada em hardware real

Kroah-Hartman reconhece que os LLMs têm se saído bem em farejar supostos problemas de segurança no código do kernel. Mas os números aconselham cautela: “Mesmo com as melhores ferramentas atuais e de próxima geração, pelo menos um terço dos resultados gerados é completamente errado ou prejudicial.”

Por isso, correções de segurança encontradas por IA só serão aceitas se o autor cumprir duas condições: testar a correção no hardware real do driver e descrever em detalhes como fez o teste. Além disso, o contribuidor “deve estar disposto a defender o envio e provar que ele realmente corrige um bug que um usuário pode encontrar”.

Não é anti-IA: uma posição em evolução

A medida não significa uma rejeição à IA no kernel como um todo. O próprio Kroah-Hartman usa LLMs com sucesso em seu trabalho e afirmou, em março deste ano, que a revisão de código assistida por IA havia “saltado” em qualidade — com relatos de bugs indo “do lixo ao legítimo da noite para o dia”, em declaração ao The Register.

A questão é o papel do staging. Em outras partes do kernel, cada mantenedor define suas próprias regras para código gerado por IA; no staging, o “produto” protegido não é o código — é o processo de aprendizado.

O que a decisão significa

A política chega em um momento em que projetos open source enfrentam uma enxurrada sem precedentes de contribuições, relatos de bugs e vulnerabilidades gerados por IA — muitos deles errados, duplicados ou prejudiciais. Para o Linux, o recado é claro: a IA pode ajudar a encontrar problemas, mas a responsabilidade de testar, defender e assinar o código continua sendo humana.

E para os novatos que querem contribuir com o kernel, o conselho não muda: escolha uma tarefa no staging, faça com as próprias mãos e aprenda o processo. Agora, oficialmente, sem atalhos.