Modelos de inteligência artificial nunca encontraram tantas falhas reais no kernel Linux (o núcleo do sistema operacional que gerencia a comunicação entre hardware e software), aproximando o projeto da marca de 2.000 correções de vulnerabilidades por ciclo de lançamento. Esse mesmo ganho de produtividade na caça a bugs está forçando revisores veteranos a abandonar seus postos para conseguir trabalhar. Em 10 de novembro de 2026, Lorenzo Stoakes, engenheiro da Arm (abre em nova aba) que contribui desde 2014 para o subsistema de gerenciamento de memória (MM, a camada responsável por alocar, liberar e organizar o uso da memória RAM), enviou uma série de quatro patches (arquivos com alterações de código-fonte) reduzindo drasticamente suas funções de revisão. O motivo explícito na mensagem enviada à Linux Kernel Mailing List (abre em nova aba) foi a falta de banda para lidar com a vazão de código gerada por ferramentas automatizadas.
Um dia antes do anúncio de Stoakes, no lançamento do candidato a versão Linux 7.4-rc2, Linus Torvalds avaliou que o pior do dilúvio de submissões motivadas por IA talvez já tivesse ficado para trás. A leitura a partir da caixa de entrada de quem revisa memória linha por linha aponta na direção oposta. Para Stoakes, o volume de código de baixa qualidade gerado por IA, conhecido no jargão técnico como AI slop, passou de algo eventual para ocorrências semanais, depois a cada poucos dias, até compor metade ou mais de tudo o que chega para sua avaliação. Segundo o desenvolvedor, o tempo desperdiçado com esse material já passou do limite aceitável, e o processo está apenas no começo.
O que exatamente um revisor faz quando o gargalo deixa de ser encontrar falhas e passa a ser filtrar correções automatizadas?
No caso de Stoakes, a resposta veio na forma de exclusão de linhas no arquivo MAINTAINERS, o catálogo oficial na árvore de código do Linux que lista os responsáveis técnicos por cada área. Os quatro patches enviados por ele apagam suas entradas de revisor (R:) das seções MEMORY MANAGEMENT - CORE, MEMORY MANAGEMENT - MISC, da área de reclaim (recuperação de páginas de memória), de MEMORY MANAGEMENT - RUST e do código do alocador em Rust. A série adiciona um registro no arquivo CREDITS documentando seu período na manutenção de Transparent Huge Pages (THP, mecanismo que automatiza o uso de páginas de memória maiores para reduzir sobrecarga de endereçamento), área que agora conta com Zi Yan na co-manutenção. Stoakes manteve apenas as frentes que supervisiona diretamente, como KVM (Kernel-based Virtual Machine, a tecnologia de virtualização integrada ao kernel), além de finalizar séries próprias em andamento. David Hildenbrand, mantenedor do subsistema de memória, aprovou a mudança com um ACK (confirmação formal de aceite na lista) reconhecendo a gravidade da situação, enquanto Andrew Morton, responsável pela árvore principal de memória, perguntou em tom de brincadeira se tinha permissão para aplicar um NACK (rejeição formal) ao pedido de saída do colega.
O custo oculto de um patch quase certo
Para quem observa de fora, um gerador de código que acerta a maior parte das correções parece um avanço líquido para projetos de código aberto. Em março de 2026, Greg Kroah-Hartman, mantenedor das versões estáveis do kernel, relatou que os relatórios de falhas gerados por IA deixaram de ser lixo óbvio quase da noite para o dia: em lotes analisados por ele, cerca de dois terços dos patches estavam corretos e um terço estava errado, mas ainda assim apontava para um problema real no código. A qualificação que acompanha esse número explica onde a conta estoura. Mesmo os dois terços funcionais exigiam limpeza humana, reescrita de histórico de alterações (changelogs) e trabalho manual de integração.
Não precisava de muita imaginação para prever o que aconteceria quando o custo de gerar um patch caísse a zero e o custo de verificar sua segurança continuasse inteiramente humano. A explosão de volume ganhou tração extra a partir de abril de 2026, quando a Anthropic (abre em nova aba) lançou o modelo de detecção de falhas Mythos, permitindo que desenvolvedores localizassem vulnerabilidades em ritmo inédito. O impacto acumulado na infraestrutura humana do Linux ficou exposto em setembro de 2026, durante o ciclo da versão 7.3.
| Indicador de carga no kernel Linux | Patamar anterior documentado | Patamar registrado na era de patches por IA (2026) |
|---|---|---|
| Correções de CVE por versão lançada | Cerca de 500 (durante a série 6.x) | Próximo de 2.000 |
| E-mails de inclusão na árvore de memória (MM) | 920 (ciclo anterior ao 7.3) | 1.250 (ciclo 7.3, administrado por Andrew Morton) |
| Volume na janela de integração (Linux 7.3) | Variável abaixo do recorde histórico | 15.267 commits (segunda maior da história do kernel) |
O aumento das correções de CVE (Common Vulnerabilities and Exposures, o identificador público padronizado para falhas de segurança conhecidas) representa um ganho concreto de segurança de memória. O efeito colateral direto é a paralisia de desenvolvimento. Durante o ciclo 7.3, recursos da arquitetura ARM64 que deveriam ter entrado na versão 7.2 atrasaram porque os mantenedores consumiram seu tempo filtrando ruído. Na árvore de memória, o salto para 1.250 notificações levou o próprio Andrew Morton a recorrer ao modelo Gemini, do Google (abre em nova aba), para rascunhar resumos das séries de patches recebidas.
Por que correções sintaticamente válidas são rejeitadas como "slop"
Qual é a falha técnica exata que transforma uma contribuição assistida por IA em motivo de bloqueio imediato nos subsistemas do Linux?
A regra geral na engenharia de software de baixo nível exige que toda correção compreenda o estado global e o contrato do componente alterado; a exceção tolerada em triagens rápidas são pequenos ajustes isolados de condição de erro, onde Kroah-Hartman observa que a IA já gera dezenas de patches aproveitáveis. Quando desenvolvedores aplicam a lógica de correção isolada a subsistemas complexos sem dominar o código adjacente, o resultado é o bloqueio.
Em agosto de 2026, Johannes Berg, mantenedor do subsistema wireless do Linux, endureceu as regras contra submissões geradas por modelos de linguagem e desativou o envio de patches assistidos por IA provenientes do syzbot (um fuzzer, ferramenta automatizada que injeta dados inválidos ou inesperados no sistema para provocar travamentos e descobrir vulnerabilidades). Embora a equipe ligada ao syzbot tenha esclarecido que todo patch gerado por IA na ferramenta passava por pré-revisão e aprovação humana antes do envio, sem respostas automáticas na lista, Berg apontou um vício estrutural nessas submissões:
- **Correção míope (narrow, targeted fix)**: o modelo analisa o rastreamento de pilha (stack trace) do travamento e adiciona uma verificação pontual (como checar se um ponteiro é nulo ou validar um limite específico naquela função exata) apenas para silenciar o alerta do fuzzer.
- Parede de texto justificativa: o patch vem acompanhado de uma longa explicação gerada automaticamente que descreve o que a linha alterada faz, criando a ilusão de uma análise profunda.
- Cegueira semântica: o engenheiro humano que atua como intermediário não dá um passo atrás para perguntar qual deveria ser a semântica real do código. Se um valor inválido chegou àquela função, a validação deveria ocorrer ali ou na camada chamadora? Outros caminhos de execução sofrem do mesmo defeito estrutural?
Quando o autor da submissão transfere para o mantenedor a tarefa de investigar a arquitetura do subsistema, o patch deixa de ser uma ajuda e vira dívida de tempo. A área de staging (espaço do kernel para drivers e códigos em maturação) e o subsistema wireless passaram a recusar sumariamente pacotes com essa assinatura.
Como validar e submeter patches assistidos por IA sem sobrecarregar mantenedores
Se você utiliza assistentes de código ou modelos de detecção de falhas para contribuir com o kernel Linux ou projetos de infraestrutura crítica, a aceitação do seu código depende de substituir a repassagem automática por validação arquitetural. As diretrizes e ferramentas mencionadas pelos próprios mantenedores em 2026 estabelecem um protocolo claro para quem atua com ferramentas generativas.
Anatomia de uma submissão assistida por IA no kernel
Antes
O desenvolvedor roda um modelo de detecção ou pega um alerta do syzbot, pede ao LLM um patch para travar a condição de falha local, cola a explicação longa gerada pelo modelo no corpo do e-mail e envia para a lista sem declarar o uso de IA e sem checar como o restante do subsistema trata aquele estado.
Depois
O desenvolvedor usa o alerta da IA apenas como diagnóstico inicial, investiga a semântica do subsistema para corrigir a causa raiz em todos os caminhos equivalentes, reescreve um changelog conciso focado no motivo arquitetural da mudança, submete o patch à pré-análise de ferramentas como o Sashiko e inclui a tag formal Assisted-by.
1. Audite a semântica além do ponto de falha
Nunca envie a primeira correção pontual sugerida por um modelo para silenciar um aviso de memória ou travamento de fuzzer. Antes de gerar o arquivo de patch, verifique o contrato da função dentro do subsistema. Pergunte se a condição de erro tratada localmente não viola uma premissa que deveria ter sido garantida na inicialização ou na função chamadora, e verifique se outros módulos do mesmo diretório exigem validação idêntica.
2. Elimine paredes de texto e limpe o changelog
Revisores como Johannes Berg e Greg Kroah-Hartman apontam os textos longos e prolixos gerados por IA como um dos sinais mais claros de baixa qualidade. O texto de commit no kernel precisa explicar de forma enxuta qual é o problema real, qual é o impacto no sistema e por que a abordagem escolhida respeita a semântica do subsistema, descartando descrições óbvias do que o código em C ou Rust está fazendo linha a linha.
3. Declare o uso da ferramenta com a tag formal
A transparência sobre a origem do código tornou-se requisito formal no fluxo do kernel documentado no ciclo 7.3. Sempre que ferramentas de inteligência artificial forem utilizadas na elaboração ou diagnóstico do patch, inclua a marcação Assisted-by: nos metadados de assinatura do commit, permitindo que os mantenedores identifiquem imediatamente o ferramental envolvido naquela série.
4. Utilize a infraestrutura pública de pré-revisão (Sashiko)
Para reduzir a carga humana sobre revisores como Stoakes, a própria infraestrutura do kernel passou a integrar revisores automatizados. A peça central desse esforço é o Sashiko, ferramenta desenvolvida originalmente no Google e doada para a Linux Foundation (abre em nova aba). O sistema roda publicamente sobre quase todos os patches submetidos ao kernel e está disponível para consulta aberta.
Antes de disparar uma série de patches para subsistemas sob pressão, especialmente gerenciamento de memória, segurança e redes sem fio, passe suas alterações pelo escrutínio dessas ferramentas públicas e certifique-se de que você é capaz de defender cada decisão de design sem depender do texto gerado pelo modelo.