O teste de IA de Linus Torvalds encontrou 3 bugs ocultos

Nils Ollrogge, um desenvolvedor diligente, relatou recentemente um bug na implementação de assoc_array do kernel do Linux. Até o próprio Linus Torvalds admitiu que o código era "obscuro demais" para ser seguido, uma admissão franca do criador do Linux. A complexidade do TN/A preparou o terreno para uma intervenção inesperada da IA.

Torvalds, sempre pragmático, recorreu a um LLM moderno para desembaraçar o código convoluto. Ele encarregou a IA de decompor funções opacas em componentes legíveis e gerenciáveis. O resultado esclarecido passou então por testes rigorosos em um ambiente de user-space, provando a utilidade do LLM como um poderoso auxílio analítico.

O processo TN/A não apenas confirmou o bug original de Ollrogge, mas também revelou três defeitos adicionais de longa data. Esses problemas ocultos remontam diretamente ao commit inicial da biblioteca assoc_array em 2013. O LLM, portanto, funcionou não como um corretor de bugs autônomo, mas como um parceiro investigativo, aumentando significativamente a capacidade de Torvalds de entender e auditar códigos legados complexos.

A recém-descoberta apreciação de Torvalds por ferramentas de IA, no entanto, não se estende à enxurrada indiscriminada de submissões geradas por IA que atualmente sobrecarrega o kernel do Linux. No recente cume de mantenedores em Praga, colaboradores e mantenedores lidaram com uma maré crescente de patches, notavelmente de quase 800 colaboradores de primeira viagem apenas no Linux 7.3. O influxo de TN/A aponta para um problema crescente: o custo humano do desenvolvimento assistido por IA.

Números oficiais mostram que cerca de 1.800 das 18.500 mudanças no Linux 7.3 carregavam uma tag Assisted-by, apenas 10% do total de submissões. No entanto, os mantenedores estimam que o uso real de LLM seja muito maior, talvez 90%. Estas são estimativas, não uma auditoria precisa, mas destacam uma desconexão significativa entre transparência e prática.

A pressão real não é a ferramenta em si, mas sua aplicação inadequada. Patches de baixa qualidade ou mal compreendidos consomem o escasso tempo dos revisores, desviando-o do desenvolvimento crucial. A aceitação de Torvalds da IA para uso pessoal não endossa uma estratégia de submissão semelhante a spam. Como ele afirmou sem rodeios, os mantenedores esperam competência e compreensão, independentemente das ferramentas utilizadas.

A proposta de remoção da tag Assisted-by: gerou um debate acalorado, expondo uma divergência fundamental sobre divulgação e responsabilidade. Os mantenedores preocuparam-se em perder as salvaguardas, temendo um influxo de código gerado por IA não verificado. No entanto, a realidade era clara: apenas ~1.800 de ~18.500 commits que não eram de merge no Linux 7.3 carregavam a tag, enquanto estimativas sugeriam que 90% dos colaboradores usavam LLMs.

Linus Torvalds, como esperado, chamou as proibições de ferramentas de "completamente estúpidas". Ele desmantelou o argumento da divulgação com analogias potentes: "Aqui está uma nova regra para vocês: não usem compiladores para nenhuma de suas submissões ao kernel". Ele estendeu a lógica aos editores de texto, argumentando que ferramentas, sejam compiladores ou LLMs, não provam ou desmentem inerentemente a compreensão de um colaborador.

O ponto central de Torvalds é claro: a escolha da ferramenta é irrelevante; a responsabilidade é primordial. Um colaborador ainda deve verificar seu código, responder aos revisores e aceitar total responsabilidade sob o processo de submissão do kernel. O sistema exige competência e propriedade, não uma declaração de preferências de software. Para mais discussões sobre a governança do kernel, veja The 2026 Maintainers Summit.

Abandonar uma tag de divulgação difícil de aplicar pode reduzir a burocracia, mas cria um compromisso de governança. Os mantenedores ainda precisam de processos de revisão eficazes e responsabilidade clara dos contribuidores, mesmo que a exigência formal de Assisted-by: desapareça.

A distinção crítica não é se uma ferramenta foi usada, mas como. O desenvolvimento assistido por IA, onde um autor humano pode explicar, validar e revisar uma contribuição, contrasta fortemente com o copiar e colar cego ou o spam automatizado de patches. O uso de um LLM pelo próprio Torvalds para esclarecer o código assoc_array, e então executá-lo através de um conjunto de testes para encontrar três bugs ocultos que datavam de 2013, exemplifica a integração responsável de ferramentas.

Isso nos leva à principal conclusão para o código aberto: julgue as submissões por evidências, correção e responsabilidade do contribuidor, não pela cadeia de ferramentas. Embora os projetos possam avaliar os riscos de procedência e licenciamento de forma diferente, o teste definitivo continua sendo a propriedade do autor humano. Cada linha submetida ainda exige um humano competente e responsável por trás dela.

O que o LLM ajudou Linus Torvalds a descobrir?

Depois que Torvalds usou um LLM para tornar o código assoc_array do Linux mais fácil de entender e testar, o trabalho confirmou um bug relatado e revelou três bugs adicionais que datavam de 2013.

O código gerado por IA é proibido no kernel do Linux?

A discussão descrita aqui é sobre abandonar uma tag de divulgação obrigatória Assisted-by, não sobre proibir o uso de IA. Os contribuidores continuam responsáveis pelo código que submetem.

Por que o Linux considerou remover a tag Assisted-by?

Os defensores argumentaram que a tag era raramente usada e difícil de aplicar, enquanto os críticos temiam que abandoná-la pudesse enfraquecer as salvaguardas contra patches gerados por IA não revisados.

Qual é o principal argumento de Torvalds sobre ferramentas de codificação de IA?

Ele argumenta que os mantenedores devem julgar se um contribuidor entende e assume a responsabilidade pelo código, em vez de policiar quais ferramentas ajudaram a produzi-lo.