Linus Torvalds promete endurecer contra pull requests “sem sentido” no kernel Linux, inclusive os gerados após revisões com IA

Linus Torvalds, principal responsável pelo desenvolvimento do kernel Linux, sinalizou que passará a rejeitar com mais firmeza pull requests considerados irrelevantes ou mal posicionados no ciclo de lançamento. A crítica foi feita após ele apontar um aumento de contribuições triviais enviadas em fases avançadas do processo, algumas delas motivadas por revisões de código feitas com ferramentas de inteligência artificial.

O comentário apareceu na atualização semanal sobre o estado do kernel, publicada no domingo, junto com o anúncio do quinto release candidate da versão 7.1 do Linux. Torvalds afirmou que o rc5 ficou “bem grande”, maior do que historicamente se espera para essa etapa do ciclo, e disse não estar totalmente satisfeito com o volume de mudanças recebidas.

Segundo ele, boa parte das alterações envolve ajustes triviais em drivers aleatórios. Embora esse tipo de correção costume ter baixo risco, o problema está no momento em que essas submissões chegam. No modelo de desenvolvimento do Linux, há uma janela inicial de duas semanas, conhecida como merge window, na qual os colaboradores enviam código para ser incorporado à próxima versão. Depois disso, são publicados release candidates, normalmente do rc1 ao rc7, que servem para estabilizar a versão antes do lançamento final.

Nesse estágio, a prioridade deveria ser corrigir regressões, ou seja, problemas introduzidos recentemente que quebraram funcionalidades ou alteraram o comportamento esperado do sistema. Para Torvalds, correções não críticas de falhas antigas não deveriam aparecer no rc5, quando o kernel já deveria estar em fase de estabilização.

Ele reconheceu que muitas dessas mudanças podem ser classificadas formalmente como “fixes”, mas argumentou que várias delas são irrelevantes o suficiente para seguir primeiro para a árvore linux-next, onde poderiam amadurecer antes de serem integradas durante a próxima merge window. A linux-next funciona como uma área de preparação e testes para mudanças que podem entrar em versões futuras do kernel.

O ponto que chamou atenção foi a menção explícita à inteligência artificial. Torvalds afirmou que várias dessas séries de alterações foram acionadas por revisões de código feitas com IA. Na prática, isso indica que ferramentas automatizadas podem estar ajudando desenvolvedores a identificar pequenos problemas, mas também podem estar aumentando o volume de contribuições de baixa prioridade em momentos inadequados do ciclo de desenvolvimento.

Torvalds disse que passará a ser mais “duro” com esse tipo de movimentação desnecessária em fases avançadas do lançamento. Para ele, pull requests tardios devem ser avaliados com mais rigor, especialmente quando não tratam de regressões reais ou de problemas suficientemente sérios para justificar inclusão imediata.

A preocupação central é a estabilidade de longo prazo do kernel Linux. Mesmo correções aparentemente simples podem introduzir novos problemas. Torvalds ressaltou que uma chance baixa de falha não significa chance zero, e que semanas de rc muito grandes não contribuem para a estabilidade do projeto.

O alerta também expõe uma tensão crescente no uso de IA em desenvolvimento de software. Ferramentas de análise automatizada podem acelerar a identificação de problemas, mas, quando usadas sem critério, podem gerar ruído operacional, duplicidade de relatórios e pressão desnecessária sobre mantenedores. Em projetos críticos e altamente distribuídos como o Linux, o desafio não é apenas encontrar falhas, mas decidir quando, como e se uma correção deve ser incorporada.

Essa não foi a primeira crítica recente de Torvalds à influência da IA no fluxo de manutenção do kernel. Na semana anterior, ele já havia reclamado que o volume contínuo de relatórios gerados por IA tornou a lista de segurança quase impossível de gerenciar, com grande duplicação causada por diferentes pessoas encontrando os mesmos problemas com as mesmas ferramentas.

Ao encerrar sua mensagem, Torvalds orientou os colaboradores a revisarem melhor seus pull requests antes de enviá-los. A pergunta central, segundo ele, deve ser se a mudança realmente corrige uma regressão ou se é grave o suficiente para não esperar a próxima fase de desenvolvimento.