Linus Torvalds Diz que a IA Tornou Enormes Atualizações do Kernel Linux o Novo Normal

Linus Torvalds aceitou uma nova e difícil realidade: revisões assistidas por IA estão produzindo mais correções para o kernel Linux do que os mantenedores tradicionalmente lidavam no fim de um ciclo de lançamento. A mudança voltou a ficar evidente durante os testes do Linux 7.2, quando atualizações excepcionalmente grandes continuaram até o sexto e o sétimo candidatos a lançamento.

A história que se espalha pelo Google News não é simplesmente que a IA encontrou bugs no Linux. As ferramentas de IA mudaram o volume e o momento das correções propostas, criando um conflito entre uma descoberta mais ampla de bugs e uma engenharia de lançamento controlada.

Esse conflito importa porque o Linux está na base de plataformas de nuvem, dispositivos Android, servidores, equipamentos de rede, ambientes de desenvolvimento e sistemas embarcados. Mais defeitos descobertos podem melhorar esses sistemas, mas cada alteração aceita também cria outra oportunidade para regressões.

Por isso, Torvalds não adota nem uma posição anti-IA nem uma posição de automação irrestrita. Sua regra emergente é mais exigente: usar IA, compreender suas descobertas, enviar trabalho útil e preservar a responsabilidade humana durante todo o processo.

Linux 7.2 Tornou Visível a Nova Carga de Trabalho

O tamanho dos candidatos a lançamento tardios do Linux 7.2 mostra que a revisão assistida por IA se tornou uma questão operacional, não um debate sobre o futuro.

Torvalds chamou o Linux 7.2-rc6 de “enorme” em sua atualização de 2 de agosto. Ele disse que, pelo número de commits, parecia ser o maior sexto candidato a lançamento em anos.

Um candidato a lançamento, ou RC, é uma versão de teste publicada antes de um lançamento estável do kernel. Normalmente, os candidatos mais tardios devem restringir o trabalho restante a regressões e defeitos graves.

O volume não voltou a níveis familiares uma semana depois. Na mensagem que anunciava o Linux 7.2-rc7, Torvalds disse não estar satisfeito com seu tamanho.

Ainda assim, ele descreveu a atualização como o “novo normal”, com muitas correções resultantes de revisões feitas por diversas ferramentas de IA. O relatório sobre o Linux 7.2 também observou que as correções estavam distribuídas entre drivers, sistemas de arquivos, rede e código específico de arquitetura.

A maioria das alterações era pequena. Torvalds identificou três áreas maiores envolvendo suporte criptográfico s390, infraestrutura do Btrfs e conjuntos de IP do Netfilter, mas não descreveu o candidato como perigoso.

Essa distinção é importante. Um grande conjunto de patches não é automaticamente um mau conjunto de patches, e um defeito descoberto por IA não é automaticamente uma correção escrita por IA.

A preocupação imediata é o risco cumulativo. Centenas de alterações individualmente modestas podem exigir amplo trabalho de revisão, testes, encaminhamento e acompanhamento.

O desenvolvimento do Linux distribui essa carga entre mantenedores de subsistemas. Esses mantenedores entendem áreas específicas, reúnem patches, avaliam-nos e enviam pull requests para o kernel principal.

A IA pode acelerar a descoberta sem ampliar essa estrutura de revisão humana no mesmo ritmo. Ela pode produzir pistas o tempo todo, enquanto os mantenedores continuam tendo atenção limitada e prazos de lançamento.

Torvalds não considerou as mudanças do Linux 7.2 graves o bastante para justificar um adiamento. Ele esperava que o lançamento estável chegasse no fim de semana seguinte, a menos que surgisse um novo problema significativo.

Essa decisão separa volume de gravidade. O Linux 7.2 era grande, mas suas alterações conhecidas continuavam administráveis o suficiente para o processo de lançamento estabelecido.

Ela também transforma o lançamento em um teste útil. Se um grande candidato influenciado por IA for lançado sem regressões sérias, os defensores ganharão evidências de que o fluxo de trabalho pode absorver mais descobertas.

Se problemas surgirem depois, o debate se voltará para controles mais rígidos de prazo e aceitação. A questão central já não é se a IA pertence ao desenvolvimento do kernel. É onde o trabalho gerado por IA se encaixa no calendário de lançamentos.

Por Que as Revisões por IA Estão Criando Mais Alterações no Kernel

A IA muda a economia de encontrar código suspeito, mas não elimina o trabalho caro necessário para validar e integrar uma correção.

Antes, um desenvolvedor precisava de tempo considerável para inspecionar código desconhecido, rastrear o fluxo de controle e procurar casos extremos negligenciados. Uma ferramenta de IA agora pode sugerir condições questionáveis em uma base de código muito maior.

Alguns sistemas funcionam como assistentes de revisão de código. Outros combinam modelos de linguagem com fuzzing, um método de teste que envia entradas inesperadas ao software para expor falhas ou erros de memória.

Essas ferramentas são especialmente adequadas para encontrar pequenas inconsistências. Elas podem identificar verificações ausentes, caminhos de erro incomuns, padrões repetidos e pressupostos incompatíveis entre funções relacionadas.

O Linux contém muitas dessas oportunidades porque oferece suporte a uma variedade extraordinária de hardware e cargas de trabalho. Seus drivers, sistemas de arquivos, componentes de rede e código específico de processadores refletem décadas de decisões de engenharia.

A IA não precisa inventar um novo subsistema para aumentar o volume de patches. Basta encontrar uma condição negligenciada em cada um de muitos componentes existentes.

Esse mecanismo explica por que a atualização atual pode ser ao mesmo tempo enorme e composta principalmente por pequenas correções. A automação amplia a superfície de busca e, então, envia mais defeitos potenciais aos fluxos de trabalho humanos estabelecidos.

Greg Kroah-Hartman, mantenedor do kernel Linux estável, forneceu um exemplo concreto. Seu caçador de bugs assistido por IA, operado localmente, teria contribuído para quase duas dúzias de patches integrados desde abril.

O sistema funcionava em um desktop Framework com um processador AMD Ryzen AI Max+. Segundo um relato sobre o caçador de bugs local, ele testava componentes do kernel localmente, em vez de enviar código a um serviço de nuvem.

Essa implementação importa para projetos que lidam com código sensível ou ainda não publicado. Modelos locais podem reduzir a exposição de dados, embora não resolvam questões sobre dados de treinamento, licenciamento ou qualidade das saídas.

O fluxo de trabalho de Kroah-Hartman também ilustra a divisão de trabalho. A ferramenta teria encontrado problemas candidatos, enquanto ele revisava os resultados, preparava correções e assumia a responsabilidade pelos envios.

Suas divulgações de patches usavam uma tag “Assisted-by”. Essa tag registra o envolvimento da automação sem fingir que o software pode assumir as consequências de uma alteração ruim.

A abordagem está muito distante de pedir a um chatbot que gere um patch e encaminhar sua resposta sem alterações. Ela trata a IA como um instrumento de teste extraordinariamente produtivo.

Essa distinção muitas vezes desaparece nas manchetes do Google News sobre programação com IA. “Código gerado por IA” pode descrever várias atividades com perfis de risco muito diferentes.

Um modelo pode resumir um patch, sinalizar código suspeito, produzir um reprodutor, propor uma correção ou escrever a maior parte de um novo componente. Reunir essas atividades sob um único rótulo obscurece os controles reais de engenharia.

Para o Linux, o caso de uso inicial mais forte parece ser a assistência delimitada. Um mantenedor escolhe um alvo, executa uma ferramenta, examina as evidências, escreve ou verifica a correção e a envia pela revisão normal.

O caso de uso mais fraco é a descoberta casual. Uma pessoa aponta um modelo de uso geral para código público, encaminha tudo o que ele relata e deixa os mantenedores determinarem se o problema é real.

Ambos os fluxos de trabalho aumentam o número de mensagens. Apenas um adiciona consistentemente o contexto e a responsabilidade necessários para transformar uma observação de máquina em software confiável.

A Capacidade dos Mantenedores Agora É o Verdadeiro Gargalo

A principal restrição passou de encontrar defeitos potenciais para decidir quais descobertas merecem a escassa atenção dos mantenedores.

O Linux há muito usa um processo de revisão hierárquico porque nenhuma pessoa pode avaliar todas as alterações. Os colaboradores trabalham com mantenedores de subsistemas, que filtram e consolidam patches antes que Torvalds os receba.

A IA pode gerar descobertas mais rápido do que essa hierarquia consegue recrutar revisores experientes. O descompasso resultante pressiona os mantenedores, e não os modelos que produzem a saída inicial.

A pressão se torna mais visível no fim de um ciclo de lançamento. O desenvolvimento do kernel normalmente começa com uma janela de integração para trabalho planejado, seguida por candidatos a lançamento cada vez mais voltados à estabilização.

Uma correção válida, mas não urgente, ainda pode ser inadequada durante um candidato tardio. Alterar código estável para lidar com um caso extremo antigo pode introduzir uma regressão pouco antes do lançamento.

Torvalds destacou esse ponto durante o desenvolvimento do Linux 7.1. Após um quinto candidato excepcionalmente grande, ele disse que se tornaria mais seletivo em relação a pull requests que contivessem correções de baixa prioridade.

Várias séries de patches haviam sido acionadas por revisão de IA. Sua preocupação não era que os defeitos identificados fossem imaginários, mas que o momento deles criava agitação desnecessária.

O alerta de fim de ciclo enfatizou que até correções triviais carregam risco diferente de zero. Torvalds queria que os mantenedores diferenciassem regressões de problemas mais antigos que poderiam esperar por outra janela de integração.

Trata-se de engenharia de lançamento convencional aplicada a um aumento incomum de descobertas. A resposta correta não é necessariamente menos correções. É um agendamento melhor.

O mesmo princípio deve importar para equipes de engenharia corporativas que adotam revisão por IA. A capacidade de uma ferramenta encontrar problemas adicionais não significa que todo resultado pertença ao lançamento atual.

As equipes precisam de limites de gravidade, regras de responsabilidade, deduplicação e prazos para alterações não críticas. Sem esses controles, taxas mais altas de descoberta podem enfraquecer a previsibilidade da entrega.

Os fornecedores de IA frequentemente avaliam ferramentas de programação por medidas de conclusão de tarefas. Os mantenedores enfrentam outro conjunto de resultados: tempo de revisão, falsos positivos, trabalho duplicado, regressões e acompanhamentos não resolvidos.

Essas medições operacionais determinam se um revisor de IA oferece valor líquido. Uma ferramenta que identifica dez defeitos reais enquanto consome semanas de atenção especializada pode ter desempenho pior que um sistema mais restrito.

A experiência do Linux também desafia a suposição de que a produtividade de programação com IA pertence aos desenvolvedores individuais. A velocidade local importa menos quando a fila compartilhada de integração fica sobrecarregada.

Um colaborador pode gerar mais patches, mas o projeto ainda precisa de alguém de confiança para inspecioná-los. O ganho de produtividade só se torna real depois que todo o sistema de revisão processa o trabalho.

Isso cria um difícil problema de incentivos. A pessoa que envia um relatório automatizado recebe o crédito visível pela descoberta, enquanto os mantenedores absorvem grande parte do custo de verificação.

Os projetos podem responder exigindo envios mais robustos. Um relatório útil pode precisar de um reprodutor, versões afetadas, análise técnica, um patch proposto e evidências de que o relator verificou duplicatas.

A IA também pode auxiliar nessas tarefas. O requisito importante é que quem envia permaneça envolvido, em vez de transferir uma saída de máquina não processada para voluntários.

Para leitores que acompanham o tema pelo Google News, “mais correções” parece uma melhoria sem ressalvas. Dentro de um projeto de software maduro, mais correções também significam mais decisões sobre risco, momento e responsabilidade.

A Manchete do Google News Oculta uma Política de IA de Dois Lados

Torvalds aceita a IA como uma ferramenta útil de engenharia, ao mesmo tempo que rejeita fluxos de trabalho que transferem seus erros e duplicações para os mantenedores.

Sua posição pode parecer inconsistente quando vista por meio de declarações isoladas. Ele criticou o ruído gerado por IA, defendeu o direito de usar IA e atribuiu à revisão automatizada a descoberta de defeitos reais.

Juntas, essas declarações formam uma política coerente. O mérito técnico importa mais do que se um humano ou uma máquina foi o primeiro a perceber um problema, mas os colaboradores humanos continuam responsáveis pelo que chega ao projeto.

Em maio, Torvalds afirmou que uma enxurrada de relatórios de segurança gerados por IA tornou a lista privada de segurança do kernel quase impossível de administrar. Várias pessoas estavam encontrando os mesmos problemas com ferramentas semelhantes.

Relatórios duplicados criam mais do que desordem na caixa de entrada. Alguém precisa compará-los, localizar discussões anteriores, identificar o subsistema correto e determinar se uma correção já existe.

Torvalds argumentou que muitos bugs detectados por IA não deveriam entrar automaticamente em um canal privado. Se várias ferramentas públicas conseguem encontrar o mesmo problema, tratar cada resultado como segredo pode impedir que os relatores vejam o trabalho já existente.

Sua crítica foi direcionada diretamente à falta de valor agregado. A sobrecarga de relatórios de segurança mostrou-o pedindo aos colaboradores que entendessem a documentação, criassem patches e desenvolvessem o resultado automatizado.

Dois meses depois, ele traçou um limite igualmente firme contra a oposição generalizada. Torvalds afirmou que o Linux não era um projeto anti-IA e disse aos opositores que o código aberto lhes permitia fazer um fork do código.

Ele descreveu a IA como uma ferramenta, embora capaz de causar problemas aos mantenedores e revelar bugs constrangedores. A solução, em sua visão, é fazer com que as ferramentas ajudem os mantenedores.

Isso não é um endosso ao desenvolvimento autônomo do kernel. É um endosso ao uso da automação sob os padrões técnicos do projeto.

O principal conflito, portanto, é entre automação útil e automação sem responsável. A origem de uma descoberta importa menos do que a qualidade das evidências e a responsabilização por trás dela.

Essa estrutura se assemelha ao tratamento dado pelo kernel a outras ferramentas. Compiladores, analisadores estáticos, fuzzers, suítes de testes e transformações por scripts podem gerar ou influenciar alterações.

Nenhuma delas se torna um mantenedor. Uma pessoa identificada ainda envia o patch, explica-o, responde às críticas, revisa o código e lida com problemas posteriores.

Modelos de linguagem complicam esse arranjo porque sua saída pode parecer convincente sem estar fundamentada no comportamento real do código. Eles também podem gerar explicações em uma escala que sobrecarrega os revisores.

A divulgação ajuda, mas, por si só, não pode garantir qualidade. Uma tag “Assisted-by” informa aos revisores que uma ferramenta participou; ela não prova que o colaborador compreendeu o resultado.

As proibições enfrentam o problema oposto. Um projeto pode proibir assistência de IA, mas detectar o uso não divulgado continua sendo difícil. Proibições rígidas podem incentivar a ocultação sem reduzir submissões de baixa qualidade.

Torvalds já argumentou anteriormente que a documentação do kernel deveria se concentrar em colaboradores responsáveis, em vez de se tornar uma declaração política sobre IA. A disputa sobre a documentação mostrou sua preferência por tratar a IA como mais uma ferramenta, enquanto aplica os padrões existentes.

Essa postura evita um teste insolúvel de autoria. Em vez disso, os revisores podem fazer perguntas que já entendem: o patch está correto, é necessário, foi testado, está claramente explicado e foi enviado no momento certo?

A política continua exigente porque a IA reduz o custo de produzir respostas plausíveis a essas perguntas. Os mantenedores precisarão de evidências, não de prosa bem polida.

Um reprodutor, caso de teste, benchmark ou rastreamento tem mais peso do que uma explicação confiante. Colaboradores que usam ferramentas devem mostrar como verificaram suas alegações.

Essa é a nuance que um breve resumo do Google News pode deixar passar. Torvalds não está nem entregando o desenvolvimento do Linux aos modelos nem protegendo-o de todo envolvimento da IA.

Ele está permitindo que a automação amplie a visão do projeto, ao mesmo tempo que insiste que os humanos continuem a exercer seu julgamento.

Mais Correções Não Significam Automaticamente um Kernel Mais Seguro

A descoberta assistida por IA pode melhorar a segurança, mas o volume de patches, por si só, não pode demonstrar que o kernel resultante é mais seguro ou estável.

Um bug descoberto é apenas o início de um processo de reparo. Os engenheiros devem confirmar o comportamento, avaliar seu impacto, projetar uma correção, testar as configurações afetadas e examinar se a alteração cria outro problema.

O Linux torna esse trabalho particularmente difícil porque um patch pode afetar muitas arquiteturas, compiladores, dispositivos e cargas de trabalho. Uma correção testada em uma máquina pode se comportar de forma diferente em outro lugar.

Pequenas alterações ainda podem alcançar caminhos de código sensíveis. Tratamento de erros, propriedade de memória, concorrência e transições de estado de hardware frequentemente produzem falhas que aparecem apenas em condições raras.

Ferramentas de IA podem identificar padrões que sugerem um defeito sem compreender todas as restrições de execução. Portanto, suas descobertas devem ser tratadas como hipóteses até que testes as sustentem.

Falsos positivos consomem tempo, mas a falsa confiança é o perigo maior. Um patch plausível pode silenciar um sintoma enquanto deixa a causa raiz intacta.

A automação também pode criar erros correlacionados. Se muitos pesquisadores usam o mesmo modelo ou método de varredura, podem relatar descobertas idênticas e ignorar classes idênticas de problemas.

Essa concentração reduz a diversidade da revisão. Dez relatórios automatizados não oferecem dez perspectivas independentes quando compartilham as mesmas premissas subjacentes.

A divulgação de segurança acrescenta outra complicação. Relatar publicamente uma vulnerabilidade reproduzível antes que uma correção esteja pronta pode ajudar atacantes tanto quanto defensores.

Torvalds argumentou que colocar automaticamente todas as descobertas de IA em uma lista privada de segurança cria duplicação. No entanto, movê-las para canais públicos exige julgamento cuidadoso sobre explorabilidade e usuários afetados.

Nenhuma regra universal de encaminhamento funcionará. Os colaboradores precisam de experiência suficiente para distinguir uma questão inofensiva de correção de uma falha de segurança que exige tratamento coordenado.

A IA pode eventualmente ajudar nessa triagem, mas automatizar a etapa de classificação cria outra camada que os mantenedores devem verificar. O gargalo muda de lugar em vez de desaparecer.

Também há evidências públicas limitadas que conectem os candidatos a lançamento maiores à confiabilidade de longo prazo. Torvalds atribuiu muitas correções à revisão por IA, mas essa observação não quantifica sua gravidade nem o benefício para os usuários finais.

A contagem de commits é um sinal de carga de trabalho, não uma pontuação de segurança. Um reparo de alto impacto pode importar mais do que muitas correções cosméticas.

A mesma cautela se aplica a relatos de que a IA se tornou indispensável. As ferramentas estão produzindo descobertas úteis, mas seus custos totais incluem hardware, operação de modelos, revisão humana, submissões duplicadas e risco de regressão.

O Linux 7.2 oferece um teste no mundo real, embora não seja um experimento controlado. Os desenvolvedores podem observar se sua série maior de candidatos leva a regressões graves, correções emergenciais ou uma carga de trabalho incomum na ramificação estável.

Eles também devem examinar quais alterações assistidas por IA sobrevivem à revisão. Taxas de rejeição e históricos de revisão revelariam mais do que o número bruto de descobertas geradas.

Uma avaliação responsável deve separar várias perguntas. A IA localizou um problema real? Ela explicou o problema corretamente? Um humano criou o patch final? Os testes mostraram que o patch resolveu o problema com segurança?

Condensar essas etapas em “a IA corrigiu o Linux” deturpa o trabalho. Isso também apaga os mantenedores cujo julgamento transforma a saída da máquina em código aceito.

As evidências atuais sustentam uma conclusão mais restrita. A IA se tornou boa o bastante para alterar o volume da revisão do kernel, mas ainda não confiável o suficiente para eliminar a supervisão especializada.

O Que Desenvolvedores e Líderes de Engenharia Devem Observar em Seguida

A próxima fase será medida pela estabilidade dos lançamentos, pela qualidade das submissões e pelas mudanças no fluxo de trabalho dos mantenedores, e não por mais um debate sobre a ideologia da IA.

O primeiro sinal é o comportamento do Linux 7.2 após o lançamento. Correções na ramificação estável, regressões e reversões urgentes mostrarão se a série excepcionalmente grande de candidatos permaneceu controlada.

Um período rotineiro após o lançamento reforçaria o argumento de Torvalds de que conjuntos maiores de atualizações influenciados por IA podem se encaixar no desenvolvimento do Linux. Um aumento nas regressões apoiaria limites mais rígidos no fim do ciclo.

O segundo sinal é a qualidade das submissões assistidas por IA. Tags de divulgação, casos de teste completos, reprodutores funcionais e acompanhamento pelos colaboradores indicariam que os usuários estão adotando fluxos de trabalho responsáveis.

Relatórios duplicados sem análise apontariam na direção oposta. Eles mostrariam que a descoberta continua mais fácil de automatizar do que a participação responsável.

O terceiro sinal são as ferramentas dos mantenedores. Os colaboradores do Linux podem criar ou adotar sistemas que eliminem duplicações, encaminhem relatórios ao subsistema correto, classifiquem a gravidade provável e reconheçam defeitos já corrigidos.

Esses sistemas precisam de projetos conservadores. Um filtro que suprima incorretamente um problema grave pode ser mais prejudicial do que uma caixa de entrada transbordando.

As empresas devem acompanhar esses desenvolvimentos porque seus repositórios internos enfrentam o mesmo problema de capacidade. Adicionar revisão por IA sem mudar as regras de triagem pode inundar as equipes com trabalho durante períodos críticos de entrega.

Uma implantação útil começa com um escopo limitado. As equipes podem escolher um subsistema, definir as evidências aceitas, acompanhar falsos positivos e atribuir um responsável humano para cada submissão assistida por máquina.

Elas devem medir todo o caminho, da descoberta ao reparo verificado. O resultado relevante não é quantos comentários uma ferramenta produz, mas quantas correções confiáveis chegam à produção sem aumentar as regressões.

As organizações também precisam de regras de timing. Descobertas não críticas de IA devem entrar no backlog normal de desenvolvimento em vez de interromper um candidato a lançamento ou ciclo de patch emergencial.

As equipes de segurança devem estabelecer procedimentos separados para vulnerabilidades suspeitas. A confiança de um modelo jamais deve determinar se um relatório permanece privado.

Os desenvolvedores precisam de expectativas claras de responsabilidade. Qualquer pessoa que submeta trabalho assistido por IA deve entender o código, reproduzir o problema, defender a alteração proposta e permanecer disponível após a integração.

A documentação pode apoiar esse comportamento, mas não pode substituir o julgamento. A experiência do Linux sugere que o desenho do fluxo de trabalho importa mais do que uma simples permissão ou proibição.

A gestão do conhecimento torna-se relevante à medida que a revisão automatizada aumenta. As equipes precisam de registros pesquisáveis de descobertas anteriores, relatórios rejeitados, decisões de subsistemas e padrões conhecidos de duplicação.

Uma base de conhecimento de engenharia pode ajudar a preservar esse contexto entre revisões de código, notas técnicas e discussões de lançamento. O objetivo é evitar que cada nova execução de ferramenta reinicie a mesma investigação.

O Google News continuará enquadrando o debate por meio de declarações memoráveis de Torvalds. A história mais importante se desenrolará dentro de listas de discussão, históricos de patches e registros de lançamentos estáveis.

Observe se os colaboradores assistidos por IA começam a entregar trabalho de engenharia completo em vez de observações isoladas. Observe se os mantenedores ganham ferramentas que reduzem os custos de encaminhamento e duplicação. Mais importante ainda, observe se o Linux absorve um volume maior de alterações sem enfraquecer a estabilidade.

A comunidade do kernel já superou a discussão sobre se os desenvolvedores usarão IA. A questão mais difícil agora é relevante para todas as equipes de software: a descoberta automatizada pode crescer mais rápido do que a revisão humana sem transformar achados úteis em mudanças descontroladas?