Linus Torvalds raramente escreve patches de drivers de hardware nos dias de hoje. Por isso, já era notável quando ele corrigiu pessoalmente, na semana passada, um bug no driver de GPU Intel Xe. O que transformou o episódio em manchete foi o esforço por trás da correção: 24 patches de depuração, 18 reinicializações do kernel e um fix que se resumiu a trocar round_up() por round_down() — além de um assistente de IA que carregou a maior parte do trabalho e até escreveu a mensagem de commit final.
A sessão de depuração — que o próprio Linus chamou de “sessão de debug do inferno” — desencadeou uma verdadeira briga dentro da comunidade Linux sobre codificação assistida por IA, políticas do kernel e se elogiar uma ferramenta equivale a endossar seus custos. Para quem acompanha engenharia de IA, é o exemplo real mais claro até agora do que significa, na prática, “depuração com humano no loop”.
Um bug no driver Intel Xe que derrubava o gerenciador de exibição
O bug vivia no driver de GPU Intel Xe do kernel. Em uma GPU Battlemage G21, o driver calculava errado um limite de memória: o armazenamento reservado para o CCS (Compute Command Streamer) era exposto incorretamente como vRAM utilizável. O hardware podia então escrever em memória que nunca deveria tocar. Se essa região por acaso sustentasse uma tabela de páginas da GPU, as consequências seriam graves; mesmo em casos menos dramáticos, poderia corromper bitmaps silenciosamente e causar falhas intermitentes na tela. O sintoma mais visível era o gerenciador de exibição GDM travando e reiniciando em loop.
Uma linha para corrigir, 24 patches e 18 reinicializações para encontrar
Linus rastreou a causa raiz até um cálculo de offset do CCS que arredondava um endereço para cima em um limite de 128KB quando deveria arredondar para baixo. Essa única direção errada de arredondamento fazia um pequeno bloco reservado “contar” como vRAM disponível. A correção foi trivial: trocar round_up() por round_down(). Encontrá-la, não. A caçada exigiu 24 patches extras que adicionaram instrumentação de depuração e 18 testes de boot do kernel — tudo para localizar uma linha.
A IA quis desistir. Linus não deixou
A parte notável da história é a divisão do trabalho. Segundo Linus, a IA deu “enorme ajuda” e cuidou de boa parte do trabalho tedioso — mas não foi uma assistente obediente. Várias vezes ela disse claramente que o problema era insolúvel e sugeriu escrever um relatório em vez disso. Linus brincou que quem treinou o modelo “não era tão teimoso quanto eu”. Assim, a sessão virou uma colaboração inusitada: a IA declarava derrota repetidamente, Linus insistia em seguir em frente, e a IA diligentemente adicionava código de debug, analisava resultados e ampliava ou restringia a busca a cada nova descoberta. A mensagem de commit final também foi escrita pela IA, com Linus dando crédito explicitamente a ela.
Qual IA? A ferramenta sem nome virou parte da história
Linus nunca revelou qual IA usou, e esse silêncio virou assunto por si só. Alguns argumentaram que foi deliberado — se ele tivesse citado o nome, o barulho de marketing resultante seria insuportável. Outros tentaram adivinhar a ferramenta pelo comportamento: declarar repetidamente que o problema era “impossível” e admitir que não sabia o que fazer em seguida. A questão mais profunda é por que o uso de IA pelo Linus provoca tanta reação. Ele passou este ano defendendo publicamente as ferramentas de IA e rejeitando qualquer tentativa de transformar o Linux em um projeto “anti-IA”, mesmo enquanto o kernel vê um número crescente de problemas e correções surgirem por meio de revisão de código assistida por IA. Quando o fundador do projeto não apenas usa IA como escreve “a IA ajudou bastante” em um commit, alguns membros da comunidade entenderam que uma linha havia sido cruzada.
Política, QA e o verdadeiro debate sobre custos
A reação tem várias camadas. Um grupo cita a política oficial de IA do kernel, que exige que contribuições com IA carreguem a tag de atribuição Assisted-by e torna o submetedor legalmente responsável por todo código gerado por IA — argumentando que Linus, na prática, quebrou as próprias regras do Linux. Outro grupo ataca o processo de QA: se um erro de arredondamento de uma linha pode sobreviver à revisão de código e ser mesclado em um driver, onde estava o teste determinístico que deveria tê-lo capturado? Um terceiro grupo amplia a crítica para o custo social da IA: problemas que humanos competentes poderiam resolver sozinhos agora estão sendo resolvidos mais rápido com IA, à custa de energia, água e do que um comentarista chamou de “corrosão da cognição pública”. A divisão de fundo é simples: de um lado, quem vê uma ferramenta que encontra bugs mais rápido; do outro, quem teme que a eficiência da IA esteja transferindo silenciosamente custos para os mantenedores, o meio ambiente e a comunidade em geral.
O que isso revela sobre como a codificação com IA realmente funciona
A lição mais importante não tem nada a ver com qual modelo foi usado. Isto não foi “codificação no piloto automático da IA”. A IA não resolveu o bug; ela afirmou repetidamente que o bug era insolúvel. Quem insistiu em continuar, julgou os resultados experimentais e decidiu quando parar foi Linus. Esse é o retrato realista da engenharia assistida por IA em 2026: uma IA incansável, mas ocasionalmente derrotista, fazendo o trabalho pesado, enquanto o humano fica com o julgamento, a direção e o resultado. É também um sinal claro de que a IA começou a entrar na manutenção de infraestrutura crítica — o tipo de código em que uma direção errada de arredondamento pode corromper a memória de milhões de máquinas. Junto com iniciativas como transmitir ao vivo o treinamento aberto de um modelo de 535B, mostra a IA saindo da criação de demos para a manutenção dos sistemas de que todos dependem.
O que os engenheiros podem levar daqui
Três lições práticas. Primeira: use a IA como copiloto de debug, não como oráculo — dê a ela builds instrumentados e deixe-a estreitar o espaço de busca, mas mantenha o julgamento final sobre direção e encerramento em mãos humanas. Segunda: trate “isso é impossível” como um dado, não como um veredito — Linus ultrapassou exatamente esse tipo de resposta. Terceira: mantenha a atribuição honesta — siga a política do seu projeto sobre contribuições com IA (o kernel exige tags Assisted-by) e assuma a responsabilidade pelo código gerado como submetedor. E se esse episódio expõe um ponto fraco no seu próprio QA, corrija-o antes que chegue à produção: um bug de limites de uma linha que sobrevive à revisão geralmente significa que faltam testes de limites, e não que a IA é o problema. É também um estudo de caso útil para a transição de ferramentas individuais de IA para agentes de IA em nível de sistema que coordenam trabalho entre máquinas.
FAQ
Qual ferramenta de IA Linus Torvalds usou para depurar o kernel Linux?
Ele nunca revelou o nome. Com base nas repetidas afirmações de que o problema era insolúvel, muitos observadores arriscaram palpites, mas Linus deixou a ferramenta deliberadamente anônima — a IA inclusive escreveu a mensagem de commit descrevendo a sessão.
Quantos patches e reinicializações a correção exigiu?
24 patches de debug e 18 reinicializações do kernel, tudo para mudar uma linha: round_up() para round_down() no cálculo de offset do CCS do driver Intel Xe, que expunha memória reservada como vRAM utilizável e derrubava o gerenciador de exibição.
Usar IA no desenvolvimento do kernel Linux é contra as regras?
Não é proibido, mas é regulamentado. A política de IA do kernel exige uma tag de atribuição Assisted-by e considera o submetedor legalmente responsável pelo código gerado por IA. O caso de Linus provocou um debate sobre se o elogio público à IA cruza uma linha que a política pretendia traçar.
