A avalanche de relatórios gerados por IA já é um incômodo para os desenvolvedores do kernel Linux. Mas o problema não é exatamente a IA, mas a postura de quem “contribui”.
3 curtidas
O Linus Torvalds está coberto de razão nessa crítica, e qualquer um que lide com suporte ou desenvolvimento entende perfeitamente o desabafo dele.
(Para quem quiser ler a matéria completa e a nota oficial do Linus, as fontes estão no Diolinux e no Tecnoblog).
Existe uma diferença brutal entre usar a tecnologia para organizar dados reais e usar a IA para fabricar relatórios genéricos. O que o Linus está atacando é aquela galera que não entende nada de hardware, roda scanners automáticos repetitivos, pede para uma IA gerar um texto inflado e joga nas listas de discussão de segurança do Kernel apenas para tentar minerar recompensas ou colocar ‘contribuidor’ no currículo. Isso gera uma avalanche de relatórios duplicados e redundantes, consumindo o tempo precioso dos mantenedores com trabalho inútil de triagem.
A IA deve ser uma ferramenta de produtividade para ajudar a formatar, traduzir ou organizar informações complexas, mas o combustível principal de um reporte legítimo precisa ser humano e real: logs físicos extraídos da máquina (dmesg, journalctl), testes práticos de regressão e o isolamento detalhado do problema no hardware (como testar via Live-USB ou analisar falhas específicas no retorno da suspensão).
Quando o reporte traz evidências reais colhidas na bancada e conta com a união e engajamento de usuários afetados que testam o problema juntos, ele se torna um documento de valor técnico essencial.
O recado do Linus é claro: menos automação barata de texto de ‘faz de conta’ e mais responsabilidade e testes práticos na hora de contribuir. O Open Source agradece!
1 curtida
Então haja Bugs no Linux! 
1 curtida
Haja bug e, pior ainda, haja paciência, EdyLima !
Mas o pior dessa história toda que o Linus expôs não é nem a existência dos bugs em si — afinal, qualquer software com milhões de linhas de código vai ter problemas. O verdadeiro ‘fogo no parquinho’ é que a IA virou uma máquina de fazer SPAM fantasiado de relatório técnico.
O que está acontecendo é que tem uma galera que não sabe nem abrir o terminal, bota uma IA para inventar um texto bonito e manda pros mantenedores do Kernel dizendo: ‘Acho que tem um problema de segurança aqui, me dá minha recompensa em dólar?’.
Aí o desenvolvedor sênior, que devia estar gastando o tempo dele corrigindo os bugs reais (tipo a nossa novela das GPUs AMD voltando da suspensão), perde horas e horas abrindo relatório falso para descobrir que o texto foi inventado por um bot.
Ou seja: bug sempre vai existir, mas o ‘Turismo de IA’ no Open Source está conseguindo a proeza de deixar a correção deles ainda mais lenta. O Linus ligou o lança-chamas e foi é pouco! 
O cURL teve que encerrar o programa de recompensas por relatórios de bugs no início deste ano pelo mesmo motivo.
1 curtida
O furo é um pouco mais embaixo. O que tem sido divulgado, da a entender que as pessoas estão fabricar relatórios falsos, mas não é exatamente esse o problema.
Some of the documentation updates might be worth highlighting: the
continued flood of AI reports has basically made the security list
almost entirely unmanageable, with enormous duplication due to
different people finding the same things with the same tools. People
spend all their time just forwarding things to the right people or
saying “that was already fixed a week/month ago” and pointing to the
public discussion.
Ou seja… Ok… Muitos reporsts são reais, mas há um desalinhamento, especialmente com como funciona a security list:
Which is all entirely pointless churn, and we’re making it clear that
AI detected bugs are pretty much by definition not secret, and
treating them on some private list is a waste of time for everybody
involved - and only makes that duplication worse because the reporters can’t even see each other’s reports.
Ou seja, resumindo:
- Bugs encontrados com IA não fazem sentido na private list de segurança.
- Legal você achou um bug legitimo com IA… Não escrevo o report com as coxas!
- Verifica se o bug já foi reportado / corrigido nas discussões públicas;
- Siga a documentação de como contribuir a risca (mande um patch, já tenha ambiente que reproduz o bug fácil de replicar, se isso for possível, etc).
- Legal, você tem um monte de log verdadeiro de máquina que de fato demonstram o problema, não manda! A gente quer evidência digerida!
Até apaguei meu post anterior 
.
A questão aqui é realmente administrativa.
Bem, de qualquer forma, IA é uma ferramenta que veio para ficar… e vai gerar bastante ruído ainda. Resta a todos aprender a usar.
Contar com o bom senso de quem está reportando é, como o Tolvards disse “entirely unmanageable”. Seguir os passos corretos de relatório e verificar a existência e status de problemas iguais ou semelhantes, sem dúvidas, são passos fundamentais, mas difíceis de serem seguidos num sentido coletivo.
A própria ferramenta de comunicação deve ser esse primeiro filtro? De forma que os passos sejam rigorosamente cumpridos antes de chegar a equipe?
2 curtidas
Tranquilo 
, não precisava ter apagado, honestamente, isso é algo normal. Eu só levantei a questão pois eu fui ler o e-mail mais a fundo e vi que o entendimento do que estava acontecendo não estava muito claro, e acho que existe algo mais importante de fundo.
O que eu acho que vale tirar deste caso, é que a cognição humana é assim, opera por atalhos, heurísticas, vieses, generalizações apressadas, etc. Psicólogos como Daniel Kahneman já mostraram isso, inclusive bem antes do surgimento de LLMs, e bom… A IA foi desenvolvida para mimetizar a cognição humana, é a única que temos como base de treinamento.
Quem se propor a estudar mais a fundo, vai chegar em teorias interessantes sobre a cognição e sistemas de informação em geral, coisas como “borda do caos” e possivelmente uma compreensão mais sutil, de que o erro não é um defeito da cognição, é o motor, dependendo de como você usa esse erro.
Eu acho que este tipo de caso tem um valor peculiar para quem está interessado em compreender não só o que dá para tirar de IAs, mas também os limites da cognição humana, como ela se dá em equipes de N pessoas trabalhando em um projeto, enfim… Como você põe uma rédea no caos produtivo, o que alguém que se propõem a gerir um projeto pode fazer para tentar evitar que o projeto não só descarrilhe, mas também não freie de vez.
O lado bom é que a gente tem muito estudo sobre como por rédeas na cognição (teoria cientifica, engenharia de processos, etc). O problema foi identificado, agora é hora de pensar em processos e etapas que façam as pessoas gerando informação se conformarem a uma geração virtuosa.
Como já foi apontado pelo @Capezotte, uma decisão inicial seria reduzir incentivos que possam ser abusados como por exemplo, programas de recompensa, mas tem muita coisa que pode ser feita, só vai depender do que a equipe do projeto achar viável, algo que não freie demais nem de menos a contribuição.
1 curtida
Telemetria e tão ruim não e ?! kkkkkkkkk Isso e bom pra aprender a melhorarem o jeito de report e não confiarem em comunidade/usuario…
Linus alias tem que parar com o vibe code… ta fazendo muita cag4da ja.