Eu sempre achei perigoso tratar IA como religião: ou “salva tudo” ou “estraga tudo”. O ponto interessante aqui é que o próprio Linus Torvalds — segundo o Tecnoblog.net — deixou claro que ele não é “anti-IA”. Ele é anti-uso ruim: IA como ferramenta de apoio, com critérios, e não como fábrica infinita de relatórios e ruído. E isso muda bastante como eu penso o fluxo de desenvolvimento em projetos grandes.
O que Linus Torvalds defendeu sobre IA no kernel Linux
Segundo o Tecnoblog.net, Linus se posicionou numa discussão na lista de discussão do kernel sobre uma suposta resistência ao uso de LLMs. A mensagem dele é direta: ele sabe que existe gente que não gosta de IA, mas ele não vê o Linux como “anti-IA”.
Na prática, a visão é: inteligência artificial como ferramenta. Igual outras ferramentas que a gente usa no kernel (compiladores, sanitizers, linters, profilers). O critério não é modismo. É utilidade real.
IA não é “contra” o kernel — o problema é o abuso
O detalhe mais relevante na declaração é que Torvalds reconhece que IA pode ser problemática. O exemplo citado é a IA “ficar encontrando bugs constrangedores”. Em 7.1, ele reclamou do excesso de bugs reportados por ferramentas com IA, que sobrecarregaram desenvolvedores com notificações que:
- já tinham sido reportadas antes;
- não eram prioritárias naquele momento;
- às vezes até já tinham sido corrigidas.
Isso não é uma “falha da IA” apenas. É um problema de processo. Quando você integra uma ferramenta que gera saídas com baixa precisão sem guardas suficientes, o custo vira humano — e humano no kernel é caro.
Por que ferramentas de LLM falham (mesmo quando parecem convincentes)
LLMs são ótimos para sugerir texto, explicações e até patches “plausíveis”. Mas eles não têm garantia intrínseca de:
- correção semântica (o patch compila e passa testes)?
- consistência com invariantes do kernel (locks, ordering, memory model)?
- prioridade real (isso resolve o risco certo agora)?
- estado atual do repositório (mudanças recentes invalidam achados)?
Em projetos pequenos isso pode “passar”. Em projetos grandes, isso vira fila de revisão e fadiga de maintainer. E aí nasce a “resistência” que todo mundo percebe.
O “porquê” por trás da postura do Linus
Linus mantém um projeto que é mais do que código: é uma cadeia de decisões técnicas. Quando IA entra, ela precisa respeitar esse sistema. Se não respeitar, ela desorganiza o que já é escasso: tempo de revisão, contexto acumulado e disciplina de contribuição.
O lado humano é óbvio: não é só “consertar bugs”. É entender por que aquele código existe daquela forma e qual trade-off foi aceito.
Como usar IA com critérios no desenvolvimento de software (sem virar ruído)
Eu penso em IA como uma camada auxiliar no pipeline. Ela pode ajudar em três pontos: reduzir tempo, melhorar qualidade e aumentar cobertura de checagens. Mas para isso, você precisa de critérios de entrada e filtros de saída.
1) Trate IA como geradora de hipóteses, não como autoridade
LLMs tendem a falar com confiança. Em engenharia, confiança não é evidência. Então eu sempre oriento: use IA para gerar candidatos (hipóteses, descrições, caminhos de investigação), e depois valide com ferramentas determinísticas.
- Hipótese → teste, build, repro, logs.
- Descrição de bug → validação com repro ou instrumentação.
- Patch sugerido → compile + testes + revisão por contexto.
2) Coloque guardas no fluxo para evitar “spam de bugs”
Se você receber 50 “bugs” que não passam em validação, você transformou sua equipe em triagem. No dia a dia, isso aparece como:
- tickets duplicados;
- PRs superficiais;
- tempo perdido em “consertos cosméticos”.
No kernel (e em qualquer sistema crítico), isso é mortal. Por isso faz sentido que Linus seja contra o excesso de notificações e não contra IA em si.
3) Compare alternativas reais: LLM vs. checadores determinísticos
Eu gosto de colocar IA ao lado de ferramentas que não “chutam”. Por exemplo:
- Compiladores e warnings: determinísticos.
- Sanitizers (ASan/TSan/UBSan): evidência runtime.
- Static analyzers (Coverity/clang-tidy/coccinelle dependendo do projeto): regras e modelos mais verificáveis.
- Fuzzing (AFL++, libFuzzer): encontra comportamentos reais.
A IA entra como “assistente” para interpretar, propor testes, explicar hipóteses. Mas a verdade operacional vem dessas ferramentas.
Na Prática: um pipeline seguro para usar IA em PRs (com validação)
Aqui vai um fluxo que eu já usei em times para reduzir ruído e acelerar revisão sem cair no “modo brainstorm infinito”. A ideia é: IA sugere; automação prova.
Passo a passo
- Defina o objetivo: IA vai ajudar em revisão? ou gerar testes? ou sugerir diagnósticos?
- Limite o escopo do contexto: em vez do repo inteiro, passe apenas arquivos relevantes e logs.
- Gere hipóteses: peça “3 hipóteses prováveis” e “quais evidências faltam”. Não peça “o patch final”.
- Implemente validação: para cada hipótese, exija um comando determinístico (build/test/sanitizer).
- Crie um gate: só abre PR de patch se passar em compile + testes mínimos definidos no projeto.
- Registre o motivo: PRs gerados por IA devem apontar como cada mudança foi validada.
- Evite duplicação: compare contra issues/PRs anteriores (busca por trecho, hash de commit e descrição).
Exemplo funcional: gerando comandos de validação a partir do output da IA
Ao invés de aceitar “o bug está aqui”, eu faço a IA produzir uma lista de validações. Um script pega isso e executa. Exemplo simplificado:
#!/usr/bin/env bash
set -euo pipefail
# Suponha que você tenha um arquivo com hipóteses sugeridas por IA.
# Formato esperado (bem simples):
# hipótese: ...
# validação_cmd: make test
# validação_cmd: ./scripts/repro.sh --case=123
#
# Aqui a gente extrai linhas que começam com "validação_cmd:" e executa.
input_file="${1:-ia_hypotheses.txt}"
mapfile -t cmds < <(grep -E '^validação_cmd:' "$input_file" | sed 's/^validação_cmd:\s*//')
if [[ "${#cmds[@]}" -eq 0 ]]; then
echo "Nenhuma validação_cmd encontrada. Abortando."
exit 1
fi
echo "Executando validações sugeridas pela IA..."
for cmd in "${cmds[@]}"; do
echo "==> $cmd"
# Em produção, você colocaria whitelist/allowlist e sandbox.
eval "$cmd"
done
echo "Validações concluídas."Por que isso funciona? Porque transforma IA em um gerador de “plano de teste”, não em um gerador de “verdade final”. Você desloca o risco para validação determinística — exatamente o oposto do que gera “spam de bugs”.
Erros Comuns: o que evitar quando você integra IA no fluxo
Se você quer evitar o cenário que irritou Linus (excesso de relatórios e distração), aqui vão armadilhas clássicas que eu vejo em times:
1) Aceitar output sem validação
“A IA disse que é um bug” não é um critério. Sem repro e sem testes, vira conversa. E conversa não escala em projetos grandes.
2) Deixar a IA escolher prioridades
LLMs não sabem sua urgência real. Elas podem repetir padrões comuns e te bombardear com coisas “plausíveis”. Prioridade tem que vir de contexto: impacto, risco, histórico, roadmap.
3) Usar contexto demais (e perder precisão)
Quanto mais você manda, mais a IA “dilui” foco. Em engenharia, foco ganha de volume. Eu prefiro:
- arquivos mínimos;
- logs relevantes;
- stack traces;
- comandos de build.
4) Não controlar o custo de revisão
Mesmo que a IA ajude, ela não deve aumentar backlog. Se cada sugestão vira PR, você vai multiplicar trabalho humano.
5) Ignorar duplicação de achados
Esse é o ponto que conversa diretamente com a reclamação do kernel. Se você não verifica duplicidade contra issues/commits já existentes, você cria “bug ping-pong”.
Implicações práticas para quem programa todos os dias
Se eu resumisse a mensagem do Linus em termos práticos: IA só vale se diminuir tempo e aumentar sinal.
- Para devs: você consegue usar IA para explicar código, gerar testes e apontar caminhos — mas precisa de um “gate” para validar.
- Para leads/maintainers: você deve impor políticas (quais tipos de sugestões entram, quais testes são obrigatórios, como medir qualidade).
- Para equipes grandes: você precisa de métricas de ruído (quantos achados viram bugs reais? quantos PRs são rejeitados por falta de evidência?).
Na minha experiência, quando a IA é acoplada a pipelines determinísticos (build, testes, lint, sanitizers, fuzzing), a resistência diminui rápido. Quando ela vira um gerador “solto” de relatórios, a fadiga começa — e a analogia com o kernel é inevitável.
FAQ
IA no kernel é “permitida” ou isso é só opinião do Linus?
Segundo o Tecnoblog.net, o posicionamento do Linus é sobre abordagem: ele não é contra IA, mas contra uso desproporcional e sem utilidade clara. Isso não cria uma regra formal universal, mas sinaliza como ele e o projeto tendem a avaliar contribuição baseada em IA.
LLMs podem ajudar em segurança e bugs do kernel?
Podem, especialmente ajudando a interpretar traces, sugerir hipóteses, gerar testes e resumir mudanças. Mas segurança exige evidência: sanitizers, fuzzing e repros reais continuam sendo o “juiz”.
Como evitar que a IA gere relatórios duplicados?
Eu recomendo buscar por termos/stack traces já conhecidos, comparar com issues/PRs e exigir um “indicador de novidade” (ex.: hash do commit, versão do componente, condição de reprodução específica) antes de abrir novo ticket.
Vale a pena deixar IA gerar patches completos?
Eu só deixo gerar “candidatos” e sempre passo por gates: compilação, testes mínimos e revisão com contexto. Patches completos sem validação costumam virar ruído e trabalho extra.
Existe um jeito de medir se IA está ajudando ou atrapalhando?
Sim: meça taxa de “sinal” (achados que viram bugs reais/PRs aceitos), tempo até validação e taxa de rejeição por falta de evidência. Se esses números pioram, você não tem problema “com IA”; você tem problema de processo.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.