Torvalds: sem LLM treinado, nem reviso kernel

LLM no kernel virou questão de sobrevivência

LLM no kernel Linux deixou de ser curiosidade para virar ferramenta de trabalho. Quem já tentou acompanhar a fila de patches sabe o peso real: centenas de e-mails por semana, código desigual, contexto espalhado em mais de 30 anos de histórico e discussões que nunca cabem em uma thread. Foi nesse cenário que Linus Torvalds afirmou no Maintainers Summit 2026, em Praga, que está 'unwilling to work without an LLM'. Sem rodeio, ele admitiu que não quer mais operar sem um modelo bem ajustado ao seu fluxo. E se ele, que criou o sistema, não dá conta sozinho, fica claro que o problema não é preguiça. É escala.

O encontro reuniu cerca de 30 desenvolvedores convidados por um dia para tratar de temas que o e-mail não resolve. Diferente de outros anos, não havia uma pauta rígida. A conversa fluiu solta e foi dominada por IA, mas também passou por bugs de segurança e sucessão de liderança. O recado geral foi duro: parem de culpar o modelo e olhem para quem usa o modelo sem entender nem de IA nem de kernel.

O fato em Praga

Torvalds foi direto: culpar LLMs pelos problemas da comunidade está errado. O problema são usuários de LLM que não sabem usar a ferramenta e não conhecem o funcionamento do kernel. Um modelo bem treinado, segundo ele, é útil de verdade, mas leva muito tempo para chegar a esse ponto. Não é plug and play. É treinamento, ajuste, curadoria e paciência. Essa frase muda o eixo do debate. Sai do campo moral do pode ou não pode usar IA e entra no campo operacional do sabe ou não sabe usar.

Na mesma linha, o grupo decidiu que contribuições de baixa qualidade de novatos devem receber prioridade baixa. A comunidade deve parar de tentar tornar a contribuição fácil. Vários mantenedores repetiram que tentar mentorar esses novatos quase sempre é perda de tempo porque eles não ouvem. É uma fala áspera, mas reflete fadiga real. Junto a isso, dois sinais práticos: o sistema de revisão automatizada Sashiko não vai mais reportar bugs preexistentes encontrados ao revisar um patch, eles vão para um banco separado à disposição dos mantenedores, e a exigência da tag Assisted-by para patches criados com LLM será removida, embora os mantenedores ainda queiram saber como o patch foi feito.

O terceiro bloco do fato é segurança e futuro. A comunidade está lutando para acompanhar a enxurrada de patches de segurança e vai continuar assim por um bom tempo. Alguns fixes mais urgentes podem pular mantenedores e ir direto para Torvalds. Houve ainda um alerta para não contar ao empregador sobre vulnerabilidades antes da divulgação pública. E, no fim, Torvalds pediu para começarem a pensar em sucessão de liderança, para existir um plano quando, daqui a alguns anos, ele decidir se aposentar.

Como funciona na visão de operador

Pense em arquitetura, não em mágica. Um LLM útil para kernel não é um chatbot genérico. É um sistema acoplado ao fluxo de e-mail, ao git, ao histórico de commits e à cultura de revisão. Na prática, isso significa um modelo com contexto longo, afinado com estilo de código do subsistema, mensagens de commit passadas, discussões da lista e regras implícitas que nunca foram documentadas. Ele serve para resumir threads gigantes, apontar regressões prováveis, sugerir testes ausentes e rascunhar respostas de review. A latência importa aqui: se a resposta demora ou alucina, o mantenedor perde confiança e volta ao grep e ao conhecimento próprio.

O caso do Sashiko mostra bem o custo operacional. Quando ele analisava um patch e listava todos os problemas preexistentes no arquivo tocado, a intenção era boa, mas o efeito era travar o contribuidor. Ninguém quer receber uma lista de faxina para poder fundir uma mudança pontual. Mover esses achados para um banco separado é uma decisão de produto sensata: separa o sinal do ruído, reduz atrito no caminho crítico e ainda preserva o dado para quem cuida daquele subsistema. É inferência plausível que esse banco vire insumo para futuros modelos e dashboards de saúde de código, sem punir quem está só tentando corrigir um bug específico.

Tem ainda a questão de custo e recursos. O Summit deixou claro: ninguém será obrigado a usar LLM para trabalhar na comunidade, mas quem usar precisa ter recursos suficientes para gerar resultados aceitáveis. Isso é um recado econômico importante. Rodar inferência decente, com contexto grande e de forma privada, custa GPU, memória, engenharia de prompt e tempo de ajuste. Quem tenta economizar com modelo fraco e gera patch mediano transfere o custo para o revisor. E há a sombra dos kernels privados mantidos por empresas com ajuda de LLM, um risco de fragmentação que ninguém sabe bem como conter.

O que isso muda na prática

Quem ganha com isso são mantenedores experientes com modelo próprio bem treinado. Eles filtram mais rápido, escrevem reviews melhores e aguentam o volume. Quem perde são contribuidores eventuais que mandam patches gerados sem entender o subsistema e esperam tutoria gratuita. Empresas com infraestrutura para treinar e hospedar modelos ganham vantagem silenciosa, enquanto desenvolvedores independentes sem GPU ou sem acesso a dados curados ficam para trás. O kernel sempre foi meritocrático e áspero, agora ele fica também intensivo em computação.

• Treine seu assistente local antes de submeter: monte um fluxo com histórico do subsistema alvo, leia pelo menos 200 commits recentes e use o LLM para explicar o porquê de cada padrão, não só para gerar código.
• Declare o uso sem depender da tag extinta: mesmo sem o Assisted-by obrigatório, diga no cover letter o que o modelo fez, quais testes você rodou e o que revisou manualmente. Transparência acelera review.
• Pare de cair no ciclo de ajuste e reenvio rápido: se o Sashiko ou um revisor apontar algo, entenda a causa raiz antes de reenviar. Reenvio ansioso queima sua reputação mais rápido que qualquer bug.

O ajuste imediato para quem quer contribuir é parar de esperar acolhimento. Leia documentação do subsistema, observe como o mantenedor responde, mande patches pequenos e bem testados. Para mantenedores, o ajuste é definir políticas claras de uso de IA no seu tree: o que você aceita, o que você rejeita, qual nível de teste é inegociável. Sem isso, você vai afogar em revisões rasas.

A tensão que fica

Aqui está a dúvida real: isso escala ou só move o gargalo? Um LLM bem treinado ajuda um Torvalds a processar mais, mas também permite que mil novatos gerem mil patches ruins em uma tarde. O ciclo de tweak-and-resend que o Sashiko alimenta é o sintoma. O modelo acelera a geração e a correção superficial, mas não cria entendimento do sistema. Se a barreira para gerar código cai e a capacidade de revisar continua humana e limitada, o gargalo não some. Ele muda de lugar, da escrita para a revisão, que é justamente a parte mais cara e escassa.

Existe ainda a tensão dos kernels privados. Se empresas conseguem manter forks internos com ajuda de LLM sem devolver nada para upstream, o kernel público pode virar apenas referência, enquanto a inovação real acontece em silos. Isso não é novo, mas IA barateia essa estratégia. Somado à fadiga com segurança e à falta de sucessores claros, o quadro é de um projeto crítico sustentado por pouca gente, com ferramenta poderosa na mão de poucos e ruído crescente na porta de entrada. Resolve ou só adia o colapso do modelo atual de manutenção?

Conclusão

No fim, Praga não oficializou o uso de IA, apenas admitiu o óbvio: sem LLM bem treinado, manter o kernel hoje é inviável. A pergunta que fica para quem constrói é simples e incômoda, você está investindo tempo para ter um modelo que realmente entende seu código ou só está gerando patch mais rápido para sobrecarregar quem revisa?