a inteligência artificial está inundando o ecossistema de segurança de código aberto em uma escala sem precedentes, com o projeto do kernel do linux arcando com a maior parte desse impacto. em sua mais recente atualização sobre o estado do kernel, linus torvalds afirmou de forma contundente: a lista de discussão de segurança atual quase entrou em colapso — ondas massivas de relatos idênticos de vulnerabilidades estão chegando, provenientes de diferentes usuários que utilizam a mesma ferramenta de ia para escanear repetidamente os mesmos trechos de código e submeter mecanicamente suas descobertas, sem qualquer julgamento contextual ou verificação de versão.
isso não é apenas “sobrecarga de relatórios”; trata-se de um colapso do mecanismo de confiança dos mantenedores. cada vez mais contribuidores tratam a ia como um gerador totalmente automatizado de patches ou de detecção de vulnerabilidades, pulando etapas cruciais, como compreender a causa raiz, reproduzir as condições e avaliar a extensão do impacto. o resultado é uma enxurrada de relatos com baixo sinal‑ruído que entopem a fila: bugs já corrigidos há muito tempo são relatados repetidamente, falsos positivos duvidosos são enviados como vulnerabilidades de alta gravidade e até mesmo “vulnerabilidades alucinadas”, ainda não verificadas, têm surgido.
esse problema é especialmente agudo em um projeto altamente iterativo e com múltiplas ramificações, como o kernel do linux. em apenas algumas semanas após a publicação de um candidato a lançamento (rc), defeitos relacionados já costumam ter sido incorporados e corrigidos; no entanto, varreduras em lote conduzidas por ia não conseguem acompanhar essa evolução dinâmica, fazendo com que patches de meses anteriores sejam repetidamente sinalizados como novas vulnerabilidades, sobrecarregando a equipe de manutenção. torvalds ressaltou com firmeza: “o valor da ia não está em gerar ruído, mas em ampliar o julgamento humano — se a saída de uma ferramenta não economiza esforço, mas acaba consumindo mais tempo de revisão, então ela não é uma ajuda, e sim um fardo.”
ele reiterou um princípio fundamental: o uso da ia é aceitável, mas a responsabilidade deve vir em primeiro lugar. ao deparar‑se com um possível problema, sempre verifique o registro de alterações, compare‑o com a versão rc mais recente e reproduza manualmente o erro para confirmá‑lo. se realmente for um defeito não corrigido, dê prioridade ao envio de um patch funcional, em vez de simplesmente anexar uma nota dizendo: “a ia detectou um possível problema”. todas as contribuições devem refletir o pensamento humano — fornecendo detalhes sobre o caminho que desencadeia o problema, a extensão do impacto, os métodos de teste ou uma justificativa para avaliar a sugestão da ia. a verdadeira colaboração começa pelo respeito ao tempo alheio, não por afogar o consenso na automação.
