A internet está fervendo com mais uma daquelas polêmicas que dividem a comunidade de software livre: o uso de inteligência artificial no desenvolvimento do kernel Linux. É o tipo de debate que mistura medo do futuro, nostalgia do passado e opinião forte de todos os lados, trazendo discussões sobre ética, qualidade de software e o que significa contribuir para um projeto do porte do kernel Linux.

☢️ Disclaimer: Este post reflete exclusivamente a minha opinião pessoal sobre o tema. Antes que venha qualquer hate, deixo claro que essas ideias vêm das vozes na minha cabeça, e não de nenhuma autoridade ou consenso da comunidade. É só uma reflexão provocativa para debater, não uma verdade absoluta.

O que está acontecendo é que foi adicionado um documento na documentação do kernel Linux (coding-assistants.rst 1) que define com detalhes as condições para aceitar contribuições assistidas por IA. Ele exige que o desenvolvedor que estiver usando uma ferramenta de apoio baseada em LLM (mais conhecida por “Lero-Lero Machine (LLM)” no Mastodon) assuma total responsabilidade e faça a revisão completa do código para garantir aderência à licença GPLv2, além de adicionar uma tag específica de atribuição, como Assisted-by: AGENT_NAME:MODEL_VERSION. Ainda por cima, o commit deve ser assinado pelo desenvolvedor com seu DCO (“Developer Certificate of Origin”), reforçando que a autoria humana permanece inalienável.

As reações da comunidade e o pânico compreensível

A internet explodiu nos últimos dias, com parte da comunidade open source reagindo com bastante energia ao fato, como vist por exemplo no post de nixCraft: “…so more slop is allowed to add directly to the Linux kernel” 2, uma reação que captura o sentimento de uma parte da comunidade que rotula o código gerado por IA como “slop” e temem uma invasão de contribuições sem qualidade no kernel. Sites como OSTechNix 3 relataram a novidade como uma “política oficial”, destacando o risco de edge cases mal tratados por LLMs atuais.

Esse receio é legítimo. Modelos de linguagem ainda falham em contextos complexos, e o kernel ainda é um dos pontos mais importantes da construção de uma distribuição, de um sistema operacional. No entanto, proibir o uso não resolve o problema: desenvolvedores continuariam integrando sugestões de IA em segredo, sem tags ou revisões declaradas, o que comprometeria ainda mais a integridade do processo.

Comparando com a legalização da Maconha: uma falácia que ilustra um ponto válido

Difícil não cometer essa falácia da falsa analogia, mas acho importante colocar lado a lado essa discussão. As semelhanças existem, no sentido de “uso de algo controverso cujos benefícios e riscos dependem de contexto” e, por conta disso, o paralelo retórico aqui funciona para expor a lógica central.

O paralelo que me interessa aqui é bem específico: em ambos os casos, há algo controverso que já está sendo usado na prática, gostemos ou não. A proibição total não erradica o uso; ela o oculta, empurra para a informalidade, onde não há rastros, eliminando mecanismos de regulação e fiscalização de qualidade.

Quando se legaliza com regras, o objetivo não é “aprovar moralmente” o uso, mas criar mecanismos de visibilidade, responsabilização e correção. Legalizar permite mitigar danos por meio de accountability.

Por que a regulação traz mais controle que a proibição

Uma proibição rígida cria um cenário de hipocrisia: ferramentas como GitHub Copilot ou Claude Code seriam usadas nos bastidores, com código “limpo” de metadados que entregariam a essência da assistência de código. Com a nova política, cada uso torna-se explícito, permitindo que revisores e mantenedores possam avaliar com um excrutínio diferenciado e avaliem a qualidade real do commit.

Essa mesma estrutura não libera um cheque em branco para usuários de assistência de código. Pelo contrário, impõe auditoria explícita. A identificação de uma violação dos termos resulta em rejeição imediata do patch. A proposta surgiu a partir de um consenso em um Maintainers Summit 4 e reflete uma visão madura de governança, priorizando a visibilidade sobre a ilusão de pureza absoluta.

Há também o problema do licenciamento, que não dá para ignorar. Modelos de linguagem são treinados em conjuntos de dados enormes, muitas vezes opacos, e existe um risco real de um “patch assistido” introduzir trechos cuja origem não é claramente compatível com a GPLv2. A política não resolve isso sozinha, mas ao exigir que quem usa IA assuma responsabilidade explícita e marque os commits, ela pelo menos deixa claro quem pode ter misturado código de origem duvidosa, cria base para reverter mudanças problemáticas e dá munição para discutir publicamente padrões de uso inaceitáveis, em vez de se descobrir somente anos depois que metade do código veio de um autocomplete obscuro.

Isso não significa, porém, que a política resolva magicamente o problema. Sempre haverá quem use IA sem marcar, quem marque mas revise mal, e mantenedores que simplesmente não terão tempo ou energia para investigar a fundo cada patch suspeito. O próprio Greg Kroah-Hartman reconhece 5 6 que, à medida que relatórios e patches gerados por IA aumentam, o volume de coisas para revisar cresce junto, e a comunidade precisa de ferramentas auxiliares para dar conta desse fluxo.

Na prática, a regulação reduz a hipocrisia, mas não elimina o “slop”. A diferença é que, com tags e diretrizes explícitas, o lixo deixa de ser invisível por padrão: há sinais no commit, contexto na discussão e base ética para recusar contribuições sistematicamente ruins. O custo de revisão sobe, mas ao menos sobe em um ambiente onde todos sabem o que está acontecendo.

Isso alinha a assistência da IA ao status de outras ferramentas estabelecidas, como compiladores otimizados ou linters de código. Na minha visão, o kernel Linux prosperou por sua capacidade de absorver inovação sem perder rigor; essa política é um passo nessa direção, confiando na maturidade dos contribuidores para filtrar o ruído.

No fim, a escolha não é uma concessão à IA, mas a defesa da rastreabilidade em um ecossistema onde a confiança se constrói com fatos, não com dogmas.

Se (ou melhor, quando) o Linus se manifestar, aí o debate ganhará ainda mais força.

Minha opinião

No fim do dia, essa é a minha visão sobre o assunto: a abordagem pragmática adotada no kernel é correta. Regular o uso de ferramentas de IA com transparência total e responsabilidade individual é, sem dúvida, superior à uma proibição cega, que só serviria para esconder a prática embaixo do tapete, sem qualquer mecanismo de controle.

Isso não significa que eu ache essa solução “boa” em termos absolutos. Na minha leitura, ela é apenas o caminho menos pior dentro de um cenário em que as pessoas já estão usando IA de qualquer forma. E, como em qualquer outro experimento de governança em software livre, nada disso é irreversível: se ficar claro que essa política causa mais dano do que benefício, sempre existe a opção de reverter commits problemáticos ou, no limite, de um grupo de desenvolvedores fazer fork e seguir por outro caminho.

Isso não quer dizer, também, que eu acredite que só porque existe uma documentação bonitinha de regras para IA, todo mundo vai virar cidadão exemplar. Vai continuar existindo código assistido por IA sem tag nenhuma, commits mal revisados com Assisted-by de fachada e mantenedores sobrecarregados tentando separar o que presta do que é lixo. Algum “slop” vai passar, como já passa hoje sem IA. A diferença é que, com uma política explícita, pelo menos existe uma linguagem comum para poder apontar o elefante na sala de estar, rejeitar padrões de uso irregulares e pressionar socialmente quem tenta burlar as regras.

Como já disse Sasha Levin, autor da proposta, em discussões iniciais:

…in time, developers adopted better programming languages and became more productive. An LLM is just another step in that direction; it is not a perfect tool, but it is good enough to improve productivity 4 7

Dito isso, pra mim ignorar ferramentas úteis só por serem baseadas em machine learning é contraprodutivo. Eu prefiro um ecossistema onde as contribuições feitas por ferramentas de assistência sejam visíveis e possam ser discutidas abertamente, em vez de um submundo de commits com código gerado às escondidas. Afinal, o open source sempre venceu pela clareza, não pela obscuridade.

Referências

  1. AI Coding Assistants {Github, 06/01/2026} (coding-assistants.rst) ↩

  2. @nixCraft@mastodon.social {nixCraft, 11/04/2026} (Link) ↩

  3. New Rules for AI Coding Assistants in Linux Kernel Development: A Proposal from Sasha Levin (NVIDIA) {OSTechNix, 28/07/2025} (Link) ↩

  4. Toward a policy for machine-learning tools in kernel development {LWN, 11/12/2025} (Link) ↩ ↩2

  5. One-month mutation leaves Linux kernel guru bewildered: Last month it was “AI junk,” but this month AI bug reports suddenly seem reliable? {36Kr, 01/04/2026} (Link) ↩

  6. Greg Kroah-Hartman can’t explain the inflection point, but it’s not slowing down or going away {Stacker News, 27/03/2026} (Link) ↩

  7. [PATCH v2] docs: add AI Coding Assistants documentation {Kernel Mailing List, 23/12/2025} (Link) ↩