# Linus Torvalds e IA no kernel Linux: o que muda

> Published 2026-10-12T22:56:09.474Z on https://www.crazystack.com.br/pt/p/linus-torvalds-e-ia-no-kernel-linux-o-que-muda/
> Source video: https://www.youtube.com/watch?v=XFSwfwiM8nk

A IA no kernel Linux não avançou por entusiasmo, e sim porque o custo de ignorá-la ficou alto: auditar bases grandes com mais olhos do que nunca é brutal. Linus Torvalds foi direto ao dizer que Linux não é um projeto anti-IA e que discordâncias sem argumento técnico não têm espaço na lista. O resto do artigo mostra o que sustenta essa posição.

## O que Linus Torvalds disse sobre IA no kernel Linux

Linus Torvalds declarou em lista de e-mail do kernel que o Linux não é um projeto anti-IA e que discordâncias puramente sociais não devem travar o uso de ferramentas por outros mantenedores. A posição dele é técnica: se você não tem argumento técnico, não tem argumento, e pode simplesmente não usar a ferramenta.

O contexto foi uma discussão em torno do [Sashiko](https://sashiko.dev/), um sistema de revisão de código agêntico voltado especificamente ao kernel Linux. O projeto revisa patches propostos com um protocolo próprio e prompts específicos de kernel, ingerindo patches de listas de e-mail ou de Git local.

A fala mais citada trata a IA como ferramenta comum, não como causa. Torvalds também admitiu que o uso é doloroso em parte das cargas de manutenção, principalmente quando a ferramenta encontra bugs embaraçosos que ninguém tinha visto. Isso é um custo real de adoção, não um detalhe retórico.

## Como a IA no kernel Linux é medida pelo Sashiko

O Sashiko reporta que encontrou 53,6% dos bugs em 1.000 commits upstream não filtrados com tags de correção, usando um modelo específico na execução divulgada. Esse número pertence ao próprio projeto e ao modelo testado, não ao kernel como um todo nem a qualquer ferramenta de revisão.

O dado tem uma leitura importante: 100% daqueles bugs passaram por revisão humana e foram aceitos na árvore principal. Ou seja, a revisão automatizada encontrou problemas que o processo humano não barrou, e isso não prova que ela é melhor que um mantenedor experiente em todos os casos.

A taxa de falso positivo é o ponto fraco da medição. O projeto afirma que ela ficou abaixo de 20% em revisões manuais limitadas, com a maior parte na zona cinzenta, e reconhece que a saída de qualquer ferramenta baseada em LLM é probabilística: a mesma entrada pode gerar achados diferentes.

## O que mudou nos relatórios de bug do kernel e do open source

Greg Kroah-Hartman, um dos principais mantenedores do kernel Linux, relatou uma mudança brusca na qualidade dos relatórios de segurança gerados por IA, de lixo para material legítimo. A reportagem que registra a fala é de março, então trate o relato como histórico datado, não como estado atual do projeto.

Antes disso, o kernel recebia relatórios de segurança obviamente errados e de baixa qualidade. O volume incomodava pouco em um projeto grande e distribuído, mas causou estrago em projetos pequenos: a equipe do curl, liderada por Daniel Stenberg, encerrou o programa de recompensas por bugs diante do volume de relatos inúteis.

Kroah-Hartman disse não saber explicar o ponto de inflexão e afirmou que o aumento não está desacelerando. A hipótese mais plausível, e é hipótese, é que modelos melhores entraram em uso real em empresas no fim de 2025 e que as ferramentas construídas em cima deles levaram alguns meses para chegar aos relatórios enviados ao kernel.

## Revisão automatizada: o que ela melhora de verdade

O ganho mais imediato da revisão automatizada é o tempo de retorno ao autor do patch, que recebe apontamentos antes de um mantenedor humano conseguir ler a proposta. Isso encurta o ciclo de correção: o desenvolvedor descobre cedo que precisa de outra versão e entrega a próxima iteração mais rápido.

Mantenedores já convivem com bots que rodam sobre patches. Quando esses bots falham, o mantenedor sabe que ainda não precisa olhar. A IA entra como mais uma camada desse filtro, não como substituta da leitura humana em projetos que exigem revisão cuidadosa.

A escala do problema de segurança é o que empurra a adoção. O kernel chegou a registrar 432 CVEs em um único dia, e o volume descrito na discussão é de itens pequenos, não de falhas estruturais. Sem automação na triagem, o gargalo vira a fila de análise, não a existência do bug.

## Quem paga a conta: manutenção de open source

Projetos pequenos absorvem muito pior um fluxo repentino de relatórios plausíveis do que o kernel, que tem equipe grande e distribuída. O kernel declara que aguenta o volume; a maior parte dos projetos de open source não tem essa folga, e é aí que a IA vira problema operacional.

Programas de auditoria e acesso gratuito a ferramentas oferecidos por fornecedores de modelos ajudam, mas chegaram tarde e cobrem poucos projetos. Do lado de quem usa essas ferramentas, o caminho prático é financiar mantenedores, contribuir de forma menos custosa ou doar créditos de inferência.

A leitura estrategista de que empresas construíram modelos em cima de código aberto e só depois retribuíram é uma interpretação editorial, não um fato documentado. O que dá para afirmar é que o ônus da triagem caiu sobre quem mantém, e que a distribuição desse custo segue desigual.

## O paralelo com TypeScript e o piso de qualidade

TypeScript, a linguagem criada por Anders Hejlsberg na Microsoft, enfrentou resistência parecida quando surgiu: os melhores desenvolvedores de JavaScript não viam necessidade, porque já escreviam código que funcionava como esperavam. O problema que ele resolve é orquestração em bases grandes, com muita gente de níveis diferentes sem conhecer o código inteiro.

O efeito prático é assimétrico. TypeScript eleva bastante o piso de qualidade de quem está começando em uma base grande e desce um pouco o teto de quem já domina tudo, como mostra a reclamação de Ryan Carniato, criador do [SolidJS](https://www.solidjs.com/), sobre APIs simples que viram meses de discussão de tipagem.

Ferramentas de IA produzem efeito parecido. Um dev especialista ainda escreve código melhor na área dele, mas quem entra em um domínio desconhecido, como o kernel, ganha muito mais do que perde ao usar assistência. O ganho está no piso, não no teto.

## Limites, riscos e o que não está resolvido

Execução local, filtragem e ausência de serviço obrigatório podem apoiar arquiteturas isoladas, mas não provam segurança, conformidade regulatória ou adequação a ambientes de saúde e finanças. Essas garantias vêm dos controles que a sua aplicação e a sua organização implementam, não da ferramenta de revisão.

A saída probabilística continua sendo o maior risco prático. A mesma entrada pode gerar achados diferentes, e a zona cinzenta de falsos positivos consome tempo de mantenedor, que é justamente o recurso escasso em projetos pequenos. Medir a sua própria taxa de acerto antes de escalar é obrigatório.

Também não existe evidência de que revisão automatizada substitua revisão humana em projetos que exigem leitura cuidadosa antes do merge. O que existe é evidência de que ela adiciona uma camada extra de verificação, com custo e com erro.

## Como aplicar isso no seu projeto hoje

Você pode usar IA na revisão do código que já escreveu, em testes e na triagem de pull requests, sem aceitar que ela gere o código que entra na árvore principal. Essa separação resolve o conflito entre velocidade e responsabilidade.

Um roteiro mínimo e testável:

1. Escolha um repositório com histórico de bugs corrigidos e monte um conjunto de avaliação com casos conhecidos.
2. Rode a ferramenta de revisão sobre esse conjunto e registre quantos bugs reais ela encontra e quantos apontamentos são falso positivo.
3. Compare com o seu processo atual de revisão, medindo tempo até o primeiro retorno ao autor e bugs escapados.
4. Defina um limite de ruído aceitável; acima dele, restrinja a ferramenta a pré-triagem e mantenha a leitura humana como filtro final.

Para quem programa em TypeScript, o formato de comparação que a comunidade brasileira usa é o Crazystack Typescript, com trilha de estudo em [crazystack.com.br](https://crazystack.com.br). É um ponto de partida para montar avaliação de ferramentas com critério, em vez de adotar por entusiasmo.

## FAQ

- **Linus Torvalds é contra ou a favor de IA no kernel Linux?**

Ele é a favor do uso como ferramenta e declarou que o Linux não é um projeto anti-IA. Torvalds afirmou que discordâncias de princípio, sem base técnica, não devem impedir outros mantenedores de usar os modelos. Ele também reconhece que o uso é doloroso em parte das cargas de manutenção.

- **O que é o Sashiko?**

Sashiko é um sistema de revisão de código agêntico voltado ao kernel Linux. Ele ingere patches de listas de e-mail ou de Git local, usa prompts específicos de kernel e não depende de ferramentas CLI externas de agentes. O projeto reporta 53,6% de bugs encontrados em uma amostra de 1.000 commits upstream com tags de correção.

- **Qual é a taxa de falso positivo do Sashiko?**

O próprio projeto afirma que a taxa ficou abaixo de 20% em revisões manuais limitadas, com a maior parte na zona cinzenta. Esse número não é uma medição independente nem cobre todas as configurações. Trate como estimativa do fornecedor.

- **Os relatórios de bug gerados por IA melhoraram mesmo?**

Greg Kroah-Hartman relatou uma mudança de qualidade, de relatos obviamente errados para material legítimo, em reportagem de março de 2026. Ele afirmou não saber explicar o ponto de inflexão e disse que o volume não está desacelerando. O relato é de um mantenedor do kernel, não de um estudo controlado.

- **IA substitui revisão humana de código?**

Não há evidência de substituição em projetos que exigem leitura cuidadosa antes do merge. O padrão observado é revisão automatizada como camada extra, somada ao processo humano. O ganho principal é feedback mais rápido ao autor do patch.

- **Por que projetos pequenos sofrem mais com relatórios de IA?**

Porque não têm equipe distribuída para absorver um aumento repentino de relatórios plausíveis. O kernel declara que aguenta o volume; o curl encerrou recompensas por bugs diante de relatos inúteis. Projetos menores enfrentam o mesmo fluxo com muito menos capacidade de triagem.

- **Quais modelos aparecem nessa discussão?**

A execução divulgada do Sashiko usou um modelo específico, e Torvalds já confirmou publicamente uso de ferramentas do Google em trabalho real. A discussão cita também [Claude Code](https://claude.com/product/claude-code), [Cursor](https://cursor.com/) e a família [Gemini](https://deepmind.google/models/gemini/). Não há medição pública comparando todos eles no kernel.

- **Dá para usar esse tipo de ferramenta em ambiente regulado?**

Execução local e ausência de serviço gerenciado obrigatório ajudam, mas não comprovam conformidade com HIPAA, regras bancárias ou qualquer norma específica. A adequação depende dos controles da sua aplicação e da sua organização. Avalie cada exigência do seu setor separadamente.

- **Como começar sem arriscar o seu repositório?**

Monte um conjunto de avaliação com bugs já corrigidos, rode a ferramenta sobre ele e compare o resultado com o seu processo atual. Se o ruído passar do limite que você definiu, mantenha a ferramenta apenas como pré-triagem. Nunca deixe a aprovação final com a IA.

- **O que a newsletter e os cursos do Dev Doido trazem sobre isso?**

O Bootcamp do Dev Doido cobre TypeScript e revisão de código com ferramentas de IA em trilhas práticas. Quem acompanha conteúdo do [Gustavo Dev Doido](https://www.youtube.com/@DevDoido) encontra discussões sobre adoção de IA no dia a dia e sobre o Crazystack Typescript. O material serve como base para montar seus próprios critérios de avaliação.

## Conteúdo de vídeo merece virar artigo

A discussão sobre IA no kernel Linux mostra uma coisa: quem tem experiência real de uso tem algo a dizer, mas esse conhecimento costuma ficar preso em vídeos longos e em threads de lista de e-mail. Se você grava entrevistas, aulas ou opiniões técnicas com evidência de primeira mão, o formato de vídeo limita quem consegue aproveitar esse material depois.

O [Skala Blog](https://skalablog.com) existe para essa passagem: você cola a URL do vídeo, o sistema transcreve o conteúdo e gera um artigo estruturado, pronto para revisão. O material que você já produziu em vídeo passa a circular também como texto pesquisável, sem refazer o trabalho do zero.

[Source video](https://www.youtube.com/watch?v=XFSwfwiM8nk)