Linus Torvalds defende o vibe coding para brincar, mas não para o kernel: o que separa as duas coisas

Existe um tipo de conselho que funciona melhor quando quem dá admite a própria limitação. Foi o caso de Linus Torvalds no Open Source Summit Europe (abre em nova aba), em Praga, no início de outubro de 2026: o criador do Linux disse, em conversa com Dirk Hohndel, da Ericsson Software Technology, que gosta de usar IA e que recorre a ela justamente para "as coisas que eu sou ruim". A frase, relatada pela ZDNET (abre em nova aba), soou estranha de primeira — o homem mais cético da indústria elogiando ferramentas que boa parte do ecossistema open source trata com desconfiança. Mas é justamente esse contraste que merece ser destrinchado, porque a declaração tem duas camadas muito diferentes e muita gente vai colar as duas.

A primeira camada é a pessoal. Torvalds contou que não programa kernel como antigamente: ele é mantenedor, o ponto de coleta do trabalho dos outros, e se diverte com projetos paralelos — no caso citado, um pedal de guitarra. Para esses brinquedos, ele defendeu o que chamou de uma forma de achar alegria em programar: "muita gente zoa o vibe coding, mas eu acho uma forma maravilhosa de achar alegria na programação". Segundo o relato da ZDNET, ele disse que a prática permite a um programador novato fazer coisas que, de outro jeito, teria enorme dificuldade de fazer.

A segunda camada é a do kernel. Nela, o tom muda por completo. Torvalds disse que é preciso ter muito cuidado ao usar IA "quando você está fazendo algo real e importante". E descreveu o impacto da IA no projeto como "disruptivo": os mantenedores estão recebendo muito mais patches aleatórios — alguns apontando para problemas de segurança reais e sérios, outros mexendo em código que ninguém toca há vinte anos.

O que é fato documentado

Vamos separar as camadas com cuidado, porque a maior parte do barulho em torno dessas declarações vem de misturá-las.

• Torvalds falou isso numa entrevista conduzida por Hohndel no Open Source Summit Europe, em Praga, e os relatos disponíveis vêm de coberturas jornalísticas — a ZDNET e The Stack (abre em nova aba) reportaram as mesmas falas no mesmo dia. Não há, até o que se sabe, transcrição oficial integral publicada, o que significa que as citações em circulação são a leitura de repórteres sobre o que foi dito no palco.
• Ele afirmou usar IA pessoalmente, em projetos pequenos, para tarefas em que se considera fraco — e classificou isso como algo positivo.
• Ele disse que a IA está, no conjunto, melhorando a base de código do kernel, mas que isso também está estressando os mantenedores "a ponto de ser um problema". Segundo a ZDNET, ele atribuiu à discussão do Linux Kernel Maintainer Summit do dia anterior a estimativa de que três quartos dela trataram de tornar a geração e revisão por IA menos estressantes e mais úteis.
• Existe um sistema agêntico de revisão de código do kernel, chamado Sashiko, cujas revisões públicas já aparecem na lista de e-mails do kernel (a LKML). Segundo o relato da ZDNET, alguns mantenedores de subsistemas já esperam que um patch tenha passado por esse tipo de revisão antes de aceitá-lo — o que, como o próprio relato adverte, não significa que todo pull request precise passar por revisão por IA.

Repare no detalhe: a parte mais interessante não é a opinião de Torvalds sobre brinquedos pessoais. É a descrição de um processo real, com nome, efeito colateral documentado (o estresse dos mantenedores) e um número que ele mesmo apresentou como balanço de uma reunião interna. Isso é bem mais concreto do que o clichê de "criador do Linux opina sobre IA".

O que é opinião — e por que a opinião dele pesa e não pesa

A defesa do vibe coding como fonte de alegria é opinião. Também é opinião a avaliação de que a IA está "melhorando a base de código" no conjunto — é o julgamento dele sobre um fenômeno que ele observa de um posto privilegiado, mas um julgamento ao fim.

O peso disso é assimétrico. Quando Torvalds fala do que gosta de fazer no fim de semana com um pedal de guitarra, a opinião dele vale o que vale a de qualquer engenheiro experiente: pouca coisa generalizável. Quando ele descreve o efeito dos patches gerados e revisados por IA no fluxo do kernel, a opinião vem acompanhada de observação direta de um dos maiores pontos de convergência de código do mundo — e aí ela informa, ainda que não prove, uma tendência.

Há um termo aqui que merece definição, porque o debate inteiro depende dele. Vibe coding é a prática de descrever o que se quer em linguagem natural e aceitar o código gerado pelo modelo com pouca ou nenhuma inspeção linha a linha, o programador "sente" se está funcionando em vez de verificar formalmente. O termo nasceu com Andrej Karpathy (abre em nova aba), que o cunhou para descrever justamente esse modo solto, de prototipagem, de programar com modelos generativos. Torvalds usou a expressão nesse sentido lato, como sinônimo de programar com IA de forma leve e exploratória, e não necessariamente com o rigor com que a comunidade técnica costuma discutir o termo quando fala de código de produção.

A parte que quase ninguém leu: o custo humano

O que mais me interessa nessa história não é a defesa do vibe coding, essa é quase óbvia. É a admissão, feita em público, de que a adoção de IA no kernel está estressando os mantenedores "a ponto de ser um problema". É raro um projeto desse porte reconhecer num palco que sua maior dor não é técnica, mas de capacidade humana de triagem.

O mecanismo é compreensível. Modelos generativos reduziram a zero o custo de produzir código. Mas o custo de revisar código não caiu na mesma proporção, revisão exige leitura, contexto histórico, entendimento de arquitetura e responsabilidade. O kernel recebe agora um volume maior de patches, alguns de altíssimo valor (apontando falhas de segurança reais, diz Torvalds) e outros de ruído puro. A fila de triagem cresce; o número de pessoas qualificadas para triar, não.

E a resposta do projeto não foi proibir: foi institucionalizar a revisão. O Sashiko, sistema de revisão agêntica, aparece como tentativa de absorver parte dessa carga, e, segundo a ZDNET, alguns mantenedores já tratam essa revisão automatizada como pré-condição informal para aceitar patches. É uma mudança cultural silenciosa: a IA deixa de ser só geradora e passa a ser filtro. Se isso é bom, depende de quão boa é a IA como revisora, e essa pergunta, até onde se sabe, ainda não tem resposta consolidada no ecossistema.

O que essa declaração não autoriza

Aqui mora o risco de leitura apressada. "Linus usa IA" não é avaliação genérica para nenhum contexto. O que ele descreveu tem fronteiras claras:

• Contexto pessoal, baixo risco, sem produção: o pedal de guitarra, projetos de brinquedo, exploração. É o território onde ele defende o uso sem cerimônia.
• Contexto de produção crítica (kernel e afins): cautela explícita. Ele disse literalmente que é preciso ser muito cuidadoso quando o que está em jogo é "real e importante".
• Triagem e revisão assistida: em uso, com efeitos mistos, melhora o código no agregado, segundo ele, mas pressiona quem mantém.

Para quem desenvolve software de produção, e aqui entra qualquer time sério, do fintech brasileiro ao mantenedor de biblioteca open source, , a lição útil é que o tipo de tarefa define o regime de uso, não a ferramenta em si. Um script interno, um protótipo descartável, uma migração mecânica: território de vibe coding com supervisão. Autenticação, concorrência, código que toca dinheiro ou dado sensível: território onde a revisão humana linha a linha continua sendo o padrão, e "o modelo escreveu" não é desculpa aceitável em post-mortem.

A distorção contrária também existe: times que proíbem IA inteiramente por medo do pior caso acabam abrindo mão dos ganhos reais que o próprio Torvalds reconheceu, inclusive em código de qualidade, com patches apontando falhas de segurança sérias. O meio termo não é moral, é engenharia: definir explicitamente em que camadas de risco a IA gera, em quais revisa e em quais nenhuma das duas coisas dispensa um humano responsável.

Convergência: dois fios, uma conclusão

Há dois fios nessa história. O primeiro é o do hobbyista: IA como forma de recuperar o prazer de programar, de baixar a barreira para quem está começando, Torvalds chegou a chamá-la de uma espécie de "droga de entrada" maravilhosa para novos desenvolvedores, no relato de The Stack. O segundo é o do mantenedor: IA como força que aumenta volume, exige novos filtros e cobra um preço em burnout que o próprio projeto reconheceu publicamente.

O que os dois fios têm em comum é uma tese implícita: IA não substitui julgamento, ela muda onde o julgamento é necessário. No hobby, o julgamento quase não é necessário, então dá pra relaxar. Em produção, ele migra do autor para o revisor, e é aí que os mantenedores estão sentindo o peso.

O conselho mais honesto que se extrai daí não vem da frase de efeito sobre o vibe coding, mas do detalhe quase burocrático: três quartos de uma cúpula de mantenedores passaram um dia discutindo como tornar IA menos estressante e mais útil. Isso é o sinal real de maturidade, não o entusiasmo, não o ceticismo, mas a tentativa de administrar o custo humano da automação. E é disso que a gente lembra quando o assunto volta à mesa daqui a seis meses.

Perguntas frequentes