O apoio de Linus Torvalds à programação com IA encontra o problema dos mantenedores do Linux

O apoio de Linus Torvalds à programação com IA agora soa incomumente entusiasmado, apesar de um conflito crescente em torno de contribuições geradas por máquinas em softwares de código aberto. Em uma palestra de 9 de outubro, o criador do Linux disse que agora “gosta muito de usar IA”, depois de anteriormente considerar a programação com IA pouco impressionante.

Esse apoio não foi uma permissão para enviar código sem verificação. Torvalds chamou a IA de uma forma útil de tornar a programação agradável, especialmente para iniciantes e projetos pessoais. Ele também alertou desenvolvedores para serem “muito cuidadosos” ao usá-la em trabalhos sérios.

A distinção importa porque o kernel do Linux já encontrou ambos os lados do desenvolvimento assistido por IA. Ferramentas automatizadas podem encontrar defeitos reais e ajudar desenvolvedores a trabalhar fora de suas linguagens mais fortes. Elas também podem inundar mantenedores com relatórios duplicados, patches superficiais e trabalho que humanos precisam verificar.

Portanto, o Linux apresenta uma questão mais difícil do que saber se a IA escreve código aceitável. Seu desafio é decidir quem arca com o custo de validar esse código. A resposta emergente combina uso permissivo de ferramentas com divulgação, revisão humana e responsabilidade pessoal.

Os comentários de Linus Torvalds sobre programação com IA estabelecem um limite claro

Torvalds apoia a IA como ferramenta de programação, mas esse apoio termina onde começa a saída não verificada.

Torvalds discutiu IA durante uma conversa com Dirk Hohndel no Open Source Summit Europe, em Praga. A Linux Foundation programou a sessão para 9 de outubro como parte do programa do 35º aniversário do projeto. A agenda da conferência posicionou a conversa ao lado de trilhas sobre Linux, IA aberta, confiança digital e software crítico para a segurança.

Sua posição representou uma mudança em sua experiência pessoal. Torvalds disse que antes acreditava que a programação com IA “simplesmente não era muito boa”. Desde então, chegou ao ponto de gostar de usá-la e de considerá-la uma ferramenta valiosa quando empregada corretamente.

Essa mudança não o transformou em defensor da geração autônoma de software. Torvalds enfatizou que é principalmente o mantenedor e ponto de convergência do kernel, e não alguém que escreve a maior parte de seu código. Seus próprios experimentos se enquadram em uma categoria de risco diferente da aceitação de mudanças em infraestrutura usada no mundo inteiro.

Ele descreveu a IA como particularmente útil para tarefas fora de sua experiência consolidada. Um exemplo envolvia um projeto pessoal de pedal de guitarra. Torvalds conseguia criar o firmware em C, mas a interface parecia ultrapassada. Então, usou IA para produzir uma implementação em Java, uma linguagem que normalmente não utiliza.

O resultado não foi apresentado como engenharia Java especializada. Ele mostrou como sua implementação conhecida em C se mapeava para outra linguagem e deu ao projeto uma interface funcional. O experimento ilustra um caso de uso delimitado, no qual o desenvolvedor entende o comportamento pretendido e pode inspecionar o resultado.

Torvalds também relacionou a IA à experiência de aprender a programar. Quando começou a codificar, em 1981, programas simples ainda podiam parecer significativos porque o software comercial era menos refinado. Hoje, novos desenvolvedores comparam seus primeiros projetos a aplicações maduras construídas por grandes equipes.

A IA pode reduzir essa barreira psicológica. Ela pode ajudar iniciantes a transformar uma pequena ideia em algo visível antes que dominem cada componente. Torvalds caracterizou esse processo como uma forma de encontrar alegria na programação e chegou a chamar a IA de uma “porta de entrada” para a área.

O alerta sobre trabalho sério muda o significado dessas observações. Uma interface de hobby gerada que se comporta mal causa inconvenientes. Um patch defeituoso para o kernel pode introduzir travamentos, perda de dados, falhas de segurança ou problemas de manutenção difíceis de identificar.

Torvalds, portanto, atribuiu a responsabilidade à pessoa que opera a ferramenta. Um desenvolvedor deve entender o que o software deve fazer e confirmar que a implementação gerada de fato o faz. Habilidade em prompts, por si só, não substitui julgamento técnico.

Esse é o limite central dentro do apoio de Linus Torvalds à programação com IA. A IA pode reduzir o esforço necessário para produzir um resultado inicial. Ela não elimina o trabalho exigido para determinar se esse resultado pertence a uma base de código crítica.

Sua posição não é nem um apoio irrestrito nem uma rejeição ideológica. Ela trata a IA como outras ferramentas de desenvolvimento, ao mesmo tempo em que reconhece que sua saída fluente pode ocultar erros de forma mais convincente do que ferramentas tradicionais.

Essa posição prática intermediária corresponde de perto às regras em desenvolvimento do kernel para contribuições. O projeto aceita assistência de sistemas automatizados, mas não permite que um agente de IA assuma as responsabilidades legais ou técnicas de um colaborador.

O kernel do Linux permite assistência, não automação anônima

As regras do kernel se concentram em colaboradores responsáveis porque código gerado não pode certificar sua própria origem, licenciamento ou correção.

O kernel do Linux agora publica orientações dedicadas para assistentes de IA destinadas a colaboradores. Elas encaminham o trabalho assistido por IA pelo mesmo processo de desenvolvimento, padrões de codificação, requisitos de licenciamento e expectativas de revisão aplicáveis a patches escritos por humanos.

Essa continuidade é importante. O Linux há muito aceita código moldado por compiladores, analisadores estáticos, geradores de código, sistemas automatizados de refatoração e scripts. Uma contribuição não se torna aceitável apenas porque uma pessoa digitou cada caractere.

Da mesma forma, uma contribuição não se torna inaceitável apenas porque uma ferramenta produziu parte dela. Revisores se preocupam com comportamento, capacidade de manutenção, licenciamento e se o remetente pode defender a alteração.

Sistemas generativos complicam esse modelo estabelecido porque podem produzir código, explicações, mensagens de commit e comentários de revisão por meio de uma única interface. Suas saídas podem parecer completas mesmo quando seu raciocínio está incorreto ou sua procedência permanece incerta.

As orientações do kernel enfrentam essa incerteza por meio da responsabilidade humana. Agentes de IA não devem adicionar uma tag Signed-off-by. Essa tag pertence a um indivíduo que pode fazer a certificação exigida pelo Developer Certificate of Origin, normalmente chamado de DCO.

No processo de DCO do kernel, o signatário confirma que a contribuição tem uma origem aceitável e pode ser distribuída sob a licença do projeto. Um modelo de linguagem não pode fazer essa declaração legal.

A pessoa que envia trabalho assistido por IA deve revisar o código gerado, assegurar a conformidade de licenciamento, adicionar sua própria assinatura e aceitar total responsabilidade. Isso significa que “o modelo escreveu” não pode servir como defesa quando revisores encontram um problema.

As orientações também introduzem uma tag Assisted-by para divulgar envolvimento significativo de LLMs. Colaboradores podem identificar o uso de um LLM e de outras ferramentas especializadas de análise. A tag fornece aos mantenedores contexto útil sem fingir que a ferramenta é uma colaboradora legal.

As regras separadas para conteúdo gerado estendem o princípio para além dos arquivos-fonte. Elas podem abranger mensagens de commit, cartas de apresentação, documentação e traduções quando conteúdo gerado entra de forma material em uma submissão.

Essas regras incentivam colaboradores a explicar quais ferramentas usaram e, quando útil, quais entradas produziram o trabalho. O objetivo não é exigir uma transcrição de cada sugestão de preenchimento automático. É expor automação material que possa afetar a revisão, a procedência ou a responsabilidade.

A transparência se torna mais importante à medida que a assistência de IA fica menos visível. Um patch gerado pode ser reescrito manualmente. Um patch de autoria humana pode receber uma descrição gerada por IA. Um modelo pode encontrar um defeito enquanto a correção final vem de um mantenedor.

A abordagem do kernel reconhece esses fluxos de trabalho mistos. Ela evita a tarefa irrealista de classificar cada caractere como feito por humanos ou máquinas. Em vez disso, pergunta se uma ferramenta fez uma contribuição significativa e se um humano está preparado para responder pela submissão final.

Esse modelo oferece a empresas e outros projetos de código aberto um precedente útil. Equipes não precisam escolher entre proibir toda ferramenta de IA e aceitar saídas opacas de agentes. Elas podem definir limites de divulgação, preservar a assinatura humana e exigir evidências normais de testes.

No entanto, regras sobre atribuição resolvem apenas parte do problema. Elas identificam a responsabilidade depois que alguém cria uma submissão. Não impedem que a IA aumente o número de relatórios e patches que mantenedores precisam inspecionar.

Esse problema de volume é onde a posição permissiva do Linux enfrenta seu teste mais difícil.

A IA torna a contribuição barata enquanto a revisão continua cara

O conflito não é código humano versus código de máquina. É saída gerada abundante versus atenção escassa dos mantenedores.

Torvalds reconheceu que análises assistidas por IA estão encontrando problemas valiosos no kernel. Ele também descreveu um fluxo de patches aleatórios cobrindo desde falhas de segurança significativas até drivers que ninguém toca há 20 anos.

Um sistema automatizado não entende naturalmente qual defeito merece atenção humana escassa. Se for solicitado a procurar vazamentos de memória, ele pode produzir relatórios onde quer que sua análise detecte um padrão suspeito. Ele não se importa se o componente afetado é amplamente implantado, obsoleto ou já está sendo corrigido.

Essa falta de priorização transfere trabalho aos mantenedores. Alguém precisa estabelecer se um relatório é válido, determinar se duplica trabalho anterior, encontrar o responsável pelo subsistema correto, inspecionar a correção proposta e avaliar consequências mais amplas.

Um relatório plausível, mas falso, pode consumir mais tempo do que um obviamente fraco. Mantenedores precisam investigar contexto suficiente para refutá-lo. A pessoa que gerou o relatório pode ter gasto apenas alguns minutos instruindo um modelo.

Torvalds já havia alertado que um influxo de relatórios de IA estava tornando a lista de segurança do kernel difícil de administrar. Descobertas duplicadas agravavam a carga porque diferentes usuários podiam executar ferramentas semelhantes sobre o mesmo código e relatar independentemente o mesmo problema.

No evento em Praga, ele disse que a IA estava melhorando a base de código como um todo. Essa avaliação favorável veio com um alerta igualmente direto: ela estava pressionando os mantenedores “a ponto de se tornar um problema”.

A dimensão da preocupação ficou visível no encontro associado de mantenedores. Segundo Torvalds, cerca de três quartos das discussões trataram de tornar as ferramentas de IA para geração e revisão de código menos estressantes e mais úteis.

Esse detalhe coloca o debate além da preferência pessoal. Mantenedores não estão simplesmente discutindo se código gerado parece autêntico. Eles estão redesenhando fluxos de trabalho em torno de uma mudança de produção que já chegou.

A IA reduz várias barreiras ao mesmo tempo. Ela permite que desenvolvedores menos experientes esbocem patches, ajuda pesquisadores a examinar subsistemas desconhecidos e transforma um problema suspeito em um relatório bem elaborado. Essas capacidades podem ampliar a base de colaboradores e expor bugs que, de outra forma, permaneceriam despercebidos.

Ainda assim, a mesma conveniência incentiva participação pontual e superficial. Uma pessoa pode enviar um relatório sem entender o código ao redor e depois desaparecer quando um mantenedor pede etapas de reprodução, testes ou uma correção mais completa.

A fricção tradicional das contribuições antes filtrava parte desse comportamento. Preparar um patch, redigir uma explicação coerente e responder à revisão exigia esforço suficiente para sinalizar comprometimento. Ferramentas generativas podem imitar esses sinais antes que o usuário desenvolva o conhecimento correspondente.

A divulgação não consegue restaurar completamente esse sinal perdido. Uma tag Assisted-by informa ao revisor que a automação participou. Ela não revela se quem enviou a contribuição entende o subsistema ou continuará envolvido após a primeira resposta.

O kernel, portanto, precisa de filtros operacionais além da atribuição. Mantenedores precisam de meios para agrupar descobertas duplicadas, classificar o impacto prático, verificar alegações automaticamente e identificar contribuidores que enviam repetidamente trabalhos aproveitáveis.

Eles também precisam de permissão para rejeitar rapidamente resultados de baixo valor. Tratar todo relatório de IA bem redigido como uma contribuição completa transformaria o volume gerado em uma obrigação para revisores não remunerados ou sobrecarregados.

Essa preocupação afeta projetos menores de forma ainda mais intensa. O Linux conta com uma grande rede de contribuidores e mantenedores empregados por grandes empresas de tecnologia. Uma biblioteca gerenciada por um ou dois voluntários tem capacidade muito menor para absorver relatórios automatizados.

Esse desequilíbrio explica por que projetos de código aberto adotaram regras diferentes para LLMs. Uma proibição pode ser uma decisão de gestão de recursos, e não uma afirmação de que todo código gerado é defeituoso. Uma política permissiva pode funcionar quando um projeto possui infraestrutura de testes e revisores suficientes para aplicar seus padrões.

O Linux ocupa uma posição incomum. Ele pode se beneficiar da análise por IA em uma enorme base de código, mas cada mudança aceita afeta infraestrutura crítica. Sua escala cria tanto o motivo mais forte para usar automação quanto o motivo mais forte para restringi-la.

A Verdadeira Troca É Entre Acesso e Responsabilidade

A IA pode levar mais pessoas à programação, enquanto uma contribuição responsável continua exigindo conhecimento, persistência e senso de responsabilidade.

A parte mais atraente do argumento de Torvalds diz respeito ao acesso. Programar se torna mais fácil de explorar quando um iniciante pode descrever uma ideia, receber um rascunho funcional e modificá-lo por meio de conversa.

Esse ciclo de feedback pode manter o aprendiz engajado. Em vez de passar a primeira sessão resolvendo problemas de instalação ou memorizando sintaxe, a pessoa pode ver um resultado e, aos poucos, examinar como ele funciona.

Para desenvolvedores experientes, as mesmas ferramentas podem preencher lacunas menores de conhecimento. Um programador de kernel pode precisar de uma interface de usuário, um ambiente de testes ou um script em uma linguagem desconhecida. A IA pode fornecer um ponto de partida sem exigir semanas de especialização não relacionada.

Esse é um ganho legítimo de produtividade. Também é diferente de delegar a um modelo uma mudança inteira sensível à segurança. No primeiro cenário, o desenvolvedor já entende o sistema desejado e consegue limitar o componente desconhecido.

A distinção se enfraquece quando os usuários não conseguem avaliar a saída. Um iniciante pode acreditar que um programa funciona porque ele passa em um teste visível. Um engenheiro experiente pode deixar passar um erro fora de sua especialidade porque a explicação gerada soa convincente.

É por isso que “humano no circuito” pode se tornar uma garantia vazia. Uma pessoa aprovar a saída não garante supervisão significativa. O revisor precisa ter contexto, tempo e autoridade suficientes para detectar falhas.

A regra de aprovação humana do kernel define quem é responsável, mas não pode fabricar competência. Quem envia uma contribuição pode assinar um patch que não entende de verdade. Os mantenedores ainda precisam de evidências técnicas e participação responsiva.

O código gerado também levanta questões não resolvidas sobre proveniência. Modelos podem reproduzir padrões conhecidos sem fornecer um histórico claro para uma saída específica. Os contribuidores precisam garantir que o trabalho enviado atende aos requisitos de licenciamento GPL-2.0-only do kernel, mesmo quando o modelo não consegue explicar cada influência de seu treinamento.

A política do Linux não afirma resolver discussões mais amplas sobre dados de treinamento ou direitos autorais. Ela estabelece um limite para contribuições: o autor humano deve ser capaz de fornecer a certificação legal já existente.

A segurança introduz outra incerteza. Sistemas de IA podem descobrir bugs em caminhos de código esquecidos, o que beneficia o projeto. Eles também podem criar um pipeline eficiente para produzir alegações superficiais de vulnerabilidades em uma escala que sobrecarrega os canais de denúncia privados.

A divulgação pública cria riscos diferentes. A revelação imediata pode expor usuários antes que os mantenedores consigam preparar e distribuir uma correção. A denúncia privada protege a coordenação, mas se torna ineficaz se seus canais se enchem de descobertas duplicadas ou fabricadas.

Os comentários de Torvalds sugerem que o Linux não resolverá essa tensão rejeitando a IA de imediato. No início de 2026, ele argumentou que o Linux não era um projeto anti-IA e que as ferramentas deveriam ajudar os mantenedores em vez de lhes causar sofrimento.

Esse padrão pressiona os criadores de ferramentas. O sucesso não pode ser medido apenas pelo número de defeitos encontrados, patches produzidos ou comentários de revisão gerados. Um sistema útil deve reduzir o esforço humano total necessário para chegar a uma decisão correta.

Para um agente de busca de bugs, isso significa reproduções, avaliação de impacto, detecção de duplicatas e evidências ligadas a caminhos de código específicos. Para um gerador de patches, significa mudanças focadas, testes e explicações que resistam à revisão de especialistas.

Para agentes de revisão, utilidade significa identificar defeitos consequentes sem soterrar os mantenedores sob alertas especulativos. Precisão e priorização importam mais do que um grande número de comentários.

A mesma lição se aplica dentro de empresas que adotam sistemas de programação com IA. Medir linhas geradas ou sugestões aceitas pode recompensar volume sem revelar o custo de manutenção. As equipes precisam acompanhar tempo de revisão, regressões, retrabalho, taxas de incidentes e responsabilidade de longo prazo.

O entusiasmo pessoal de Torvalds não invalida essas preocupações. Ele as torna mais nítidas. Se um desenvolvedor que entende os riscos do kernel ainda considera a IA agradável e útil, uma rejeição total deixa benefícios relevantes de lado.

Se o Linux aceitasse toda saída gerada sem controles adicionais, transferiria os custos ocultos da tecnologia para os mantenedores. A direção atual do projeto tenta preservar a experimentação enquanto recusa essa transferência.

O Que a Comunidade Linux Precisa Demonstrar em Seguida

A política de IA do Linux só terá sucesso se as contribuições geradas se tornarem mais fáceis de verificar, priorizar e manter do que a atual enxurrada de entradas.

O primeiro sinal a observar é como o kernel aplica suas regras de divulgação na revisão cotidiana. A documentação formal importa, mas uma prática consistente determinará se os contribuidores entendem quando usar Assisted-by e quais informações os revisores esperam.

Uma divulgação excessivamente ampla poderia produzir metadados repetitivos com pouco valor. Uma divulgação fraca poderia ocultar automação relevante e privar os revisores de contexto. O equilíbrio útil surgirá por meio de submissões reais, feedback dos mantenedores e revisões das orientações.

O segundo sinal é se a automação de revisão reduz a carga criada pela geração. Torvalds observou que os projetos já estão usando IA para revisar patches assistidos por IA, criando às vezes a aparência de bots conversando com bots.

Esse ciclo não é automaticamente absurdo. A análise estática já verifica código gerado por máquinas e escrito por humanos. Um revisor de IA pode cumprir um papel semelhante se suas descobertas forem precisas, reproduzíveis e subordinadas a mantenedores responsáveis.

O perigo surge quando um sistema incerto valida outro e os humanos tratam a concordância como evidência. Vários modelos podem repetir a mesma suposição equivocada. Os pipelines de revisão devem se basear em testes, resultados de compilação, comportamento em execução e análise rastreável de código, em vez de consenso entre modelos.

Observe ferramentas que vinculam verificação concreta a cada descoberta. Um relatório que inclui um reprodutor, configuração afetada, resultado de teste e patch mínimo é mais valioso do que um parágrafo confiante descrevendo um possível defeito.

O terceiro sinal é a carga de trabalho dos mantenedores. Se os relatórios de segurança duplicados diminuírem, patches de baixo valor receberem triagem mais rápida e contribuidores úteis permanecerem engajados durante a revisão, o modelo de aceitação controlada do Linux parecerá sustentável.

Se as filas continuarem crescendo e mantenedores experientes entrarem em esgotamento, os projetos terão motivos mais fortes para impor limites mais rigorosos. O resultado relevante não é quanto código gerado por IA entra na árvore. É se a comunidade consegue preservar a qualidade da revisão sem esgotar as pessoas responsáveis por ela.

Fornecedores de ferramentas deveriam tratar esse resultado como um requisito de produto. Um agente que produz dez patches enquanto cria vinte horas de trabalho de revisão não entregou dez unidades de produtividade.

Os desenvolvedores também devem distinguir experimentação de contribuição. Vibe coding, isto é, programação iterativa por meio de prompts em linguagem natural, pode funcionar bem para um protótipo descartável. Enviar código upstream exige entender seu comportamento, histórico, testes e consequências de manutenção.

É nessa transição que o apoio de Linus Torvalds à programação com IA se torna mais útil como orientação. Comece com uma tarefa delimitada. Use IA onde ela ajudar. Inspecione o que ela cria. Teste o resultado, explique-o com suas próprias palavras e aceite a responsabilidade antes de pedir que outra pessoa o revise.

Iniciantes não devem interpretar a cautela como um motivo para evitar a IA. A metáfora da “droga de entrada” de Torvalds reconhece que ferramentas acessíveis podem criar a motivação necessária para aprender. O próximo passo é converter um sucesso gerado em compreensão genuína.

Engenheiros experientes não devem interpretar sua especialização como imunidade a erros. A fluência pode incentivar excesso de confiança, especialmente quando um modelo produz código plausível em um domínio desconhecido. Sistemas sérios exigem verificação independente mesmo quando o primeiro resultado parece refinado.

Já os mantenedores precisam de autoridade para definir que tipo de assistência realmente ajuda seus projetos. O Linux pode apoiar a IA sem exigir que todos os responsáveis por subsistemas aceitem trabalho ilimitado gerado por máquinas.

O modelo emergente do kernel é exigente, mas coerente. As ferramentas podem participar. Os humanos devem divulgar assistência material, cumprir as regras de licenciamento, entender suas submissões e permanecer responsáveis pelas consequências.

Essa abordagem não encerrará o debate do código aberto sobre conteúdo gerado por LLMs. Projetos diferentes têm riscos e capacidade de revisão distintos. Ela, porém, desloca o debate da identidade para as operações.

Os próximos meses devem revelar se o Linux consegue transformar esse princípio em um fluxo de trabalho administrável. Os desenvolvedores já podem ajudar a responder à pergunta: antes de enviar trabalho assistido por IA, verifique se ele economiza o tempo dos mantenedores, em vez de apenas economizar o tempo de quem o gerou.