Quando a IA produz código, mas transfere o trabalho: a advertência deixada pelo Linux 7.1

A Inteligência Artificial já se tornou parte do cotidiano de muitos desenvolvedores. Ela explica funções, sugere algoritmos, cria testes, revisa código, identifica possíveis vulnerabilidades e até escreve partes inteiras de uma aplicação.

Negar essas vantagens seria pouco razoável. Eu mesmo reconheço que a IA pode acelerar o aprendizado e tornar algumas atividades de desenvolvimento muito mais produtivas.

Entretanto, o ciclo de desenvolvimento do kernel Linux 7.1 trouxe uma questão que não pode ser ignorada:

Quando usamos uma IA para produzir uma contribuição, estamos realmente ajudando o projeto ou apenas transferindo para os mantenedores o trabalho de verificar algo que nós mesmos não compreendemos?

Essa pergunta é especialmente importante em projetos comunitários, nos quais centenas ou milhares de desenvolvedores compartilham recursos limitados de revisão, testes, comunicação e manutenção.

A IA consegue gerar conteúdo em segundos. A comunidade, porém, continua precisando analisar esse conteúdo no ritmo humano.

É justamente nessa diferença de velocidade que nasce um novo problema para o desenvolvimento colaborativo.

O que aconteceu durante o ciclo do Linux 7.1?

O kernel Linux 7.1 foi lançado oficialmente em 14 de junho de 2026. Como ocorre em cada versão, antes da publicação definitiva foram disponibilizadas várias versões candidatas, conhecidas como Release Candidates ou simplesmente RCs.

Essa etapa não é uma continuação comum do desenvolvimento de funcionalidades. Sua finalidade principal é estabilizar aquilo que já foi incorporado durante a janela de integração.

Em outras palavras, durante os RCs, o objetivo deve ser:

• identificar regressões;
• corrigir falhas introduzidas recentemente;
• estabilizar subsistemas;
• reduzir riscos;
• preparar a versão final.

Foi durante esse processo que Linus Torvalds demonstrou preocupação com o impacto do uso pouco criterioso de ferramentas de IA.

No anúncio do Linux 7.1-rc4, ele comentou sobre o fluxo contínuo de relatórios produzidos com auxílio de IA nas listas relacionadas à segurança. Muitos desses relatórios eram repetidos, já conhecidos ou encaminhados sem uma investigação humana suficiente.

No Linux 7.1-rc5, outro sintoma apareceu: a versão candidata ficou maior do que o esperado, em parte devido à quantidade de pequenas correções motivadas por revisões automatizadas.

Nem todas essas correções estavam erradas. Esse é um ponto importante.

O problema estava no contexto, na prioridade e no momento em que foram enviadas.

Muitas tratavam de problemas antigos e não críticos em drivers aleatórios. Embora pudessem representar melhorias legítimas, não eram necessariamente regressões que precisassem entrar nas últimas semanas de estabilização.

Uma pequena alteração continua sendo uma alteração. E toda alteração, por mais simples que pareça, introduz algum risco.

Uma correção de duas linhas pode afetar uma arquitetura pouco testada, um driver raro, uma condição de concorrência ou um comportamento que só aparece em determinado hardware. A probabilidade pode ser pequena, mas não é igual a zero.

Linus Torvalds não está simplesmente rejeitando a IA

Seria incorreto interpretar esse episódio como uma declaração de guerra contra a Inteligência Artificial.

A posição de Linus é mais pragmática.

A IA pode ser usada como ferramenta, assim como compiladores, analisadores estáticos, scripts, formatadores, sistemas de testes e mecanismos automatizados de refatoração. Entretanto, a responsabilidade não pertence à ferramenta.

Ela pertence ao desenvolvedor que envia a contribuição.

Isso significa que não basta dizer:

“A IA encontrou este problema.”

O desenvolvedor precisa ser capaz de responder:

• O problema realmente existe?
• Em que condições ele ocorre?
• Ele já foi relatado?
• Já existe uma correção?
• Trata-se de uma regressão?
• O comportamento apontado é realmente incorreto?
• A mudança respeita a arquitetura do subsistema?
• Quais equipamentos e configurações podem ser afetados?
• Como a correção foi testada?
• Por que ela precisa entrar nesta etapa do desenvolvimento?

A IA pode iniciar a investigação. Ela não pode substituir a responsabilidade técnica de quem assina o trabalho.

A diferença entre encontrar uma possibilidade e comprovar um problema

Modelos generativos são muito bons em encontrar padrões aparentemente suspeitos.

Eles conseguem observar um trecho de código e sugerir:

• possível uso após liberação de memória;
• ausência de validação;
• condição de corrida;
• vazamento de recursos;
• ponteiro potencialmente nulo;
• falta de tratamento de erro;
• comportamento indefinido;
• inconsistência em um comentário;
• oportunidade de simplificação.

Contudo, uma possibilidade sintática não é automaticamente um defeito real.

Código de kernel depende de contexto. Há contratos internos, mecanismos de sincronização, garantias dadas por funções anteriores, particularidades de hardware, estados impossíveis em condições normais e comportamentos históricos preservados por compatibilidade.

Uma IA pode identificar que um ponteiro não foi validado dentro de uma função. Entretanto, pode desconhecer que todas as chamadas dessa função garantem previamente que ele nunca será nulo.

Também pode recomendar a inserção de uma trava sem perceber que aquela região já está protegida por outro mecanismo de sincronização.

Pode sugerir a liberação de um recurso sem compreender que sua propriedade foi transferida para outro componente.

Pode produzir uma correção localmente convincente que viola uma decisão arquitetural tomada anos antes.

É por isso que a saída da IA deve ser tratada como hipótese, não como veredito.

O custo quase invisível imposto aos mantenedores

Há uma assimetria preocupante no uso da IA em projetos comunitários.

Para quem envia a contribuição, gerar um relatório pode levar poucos minutos:

1. executar uma ferramenta;
2. copiar a saída;
3. pedir a um chatbot que escreva uma descrição;
4. encaminhar o resultado para uma lista de discussão.

Para o mantenedor, a mesma mensagem pode exigir:

1. localizar o código afetado;
2. reconstruir o contexto;
3. consultar o histórico;
4. verificar se o problema já foi corrigido;
5. reproduzir a situação;
6. analisar o impacto;
7. responder ao autor;
8. encaminhar a mensagem para outro subsistema;
9. explicar por que o relatório não procede;
10. revisar uma eventual correção.

Em outras palavras, a IA reduz o custo de produzir uma demanda, mas não reduz necessariamente o custo de validá-la.

Quando isso acontece em grande escala, surge uma forma de externalização de trabalho: o autor economiza tempo, enquanto a comunidade absorve toda a investigação que deveria ter sido realizada antes do envio.

Uma contribuição não é gratuita apenas porque o autor não recebe pagamento. Ela consome atenção de outras pessoas.

Em projetos de código aberto, atenção é um recurso tão importante quanto infraestrutura e financiamento.

Relatórios duplicados não multiplicam a segurança

Uma das preocupações apresentadas durante o Linux 7.1 foi a repetição de relatórios encontrados por ferramentas semelhantes.

Quando vários pesquisadores executam os mesmos modelos ou analisadores sobre a mesma base de código, é natural que encontrem os mesmos padrões.

Se não houver pesquisa prévia e coordenação, dez pessoas podem relatar o mesmo suposto defeito.

Isso não significa que o projeto recebeu dez contribuições úteis. Significa que alguém terá de ler, classificar e responder dez vezes.

Em listas privadas de segurança, a situação pode ser ainda mais complicada, pois os pesquisadores nem sempre conseguem enxergar os relatórios já enviados. O sigilo, necessário para vulnerabilidades reais, pode acabar ampliando a duplicação de alertas pouco investigados.

O resultado não é necessariamente mais segurança.

Pode ocorrer exatamente o contrário: o excesso de ruído dificulta a identificação das falhas verdadeiramente graves.

Quando tudo é marcado como urgente, nada consegue receber a atenção adequada.

A IA facilitou o envio antes de ensinar a contribuição

Antes das ferramentas generativas, contribuir com um projeto complexo normalmente exigia um esforço inicial considerável.

O desenvolvedor precisava:

• estudar a documentação;
• compreender a organização do projeto;
• conhecer o subsistema;
• aprender as regras de submissão;
• ler discussões anteriores;
• construir e testar o código;
• escrever a justificativa da alteração.

Esse processo criava uma barreira, mas também funcionava como uma etapa de formação.

A dificuldade obrigava o colaborador a aprender antes de pedir o tempo dos mantenedores.

A IA reduziu essa barreira. Isso é positivo quando ajuda novos desenvolvedores a compreender o projeto. Torna-se negativo quando permite que alguém pule o aprendizado e chegue diretamente à submissão.

A facilidade de produzir um patch não significa que a pessoa esteja preparada para contribuir.

Uma colaboração tecnicamente válida não é apenas um arquivo de diferenças. Ela inclui conhecimento, justificativa, testes, contexto e disposição para acompanhar a revisão.

“Funciona” é um critério insuficiente

Em projetos pessoais ou protótipos descartáveis, pode ser aceitável gerar uma solução, testá-la rapidamente e mantê-la enquanto aparentemente funciona.

Em um kernel, uma biblioteca amplamente utilizada ou uma infraestrutura comunitária, esse critério é insuficiente.

Código mantido por muitos anos precisa ser:

• compreensível;
• previsível;
• testável;
• rastreável;
• compatível com decisões arquiteturais;
• justificável perante outros desenvolvedores;
• sustentável após a saída do autor.

O código gerado por IA pode passar nos testes atuais e ainda carregar problemas que só aparecerão no futuro.

Pode adicionar complexidade desnecessária, repetir padrões antigos, utilizar interfaces em processo de descontinuação ou resolver apenas o exemplo apresentado no prompt.

O desafio da engenharia de software não é somente fazer o código funcionar hoje. É permitir que outra pessoa consiga compreender amanhã por que ele existe e quais garantias oferece.

A responsabilidade não pode ser terceirizada para o modelo

Quando um desenvolvedor envia uma contribuição, ele está implicitamente afirmando:

“Eu compreendo esta mudança, considero-a adequada e estou preparado para responder por ela.”

Não é aceitável substituir essa afirmação por:

“O modelo sugeriu e os testes passaram.”

A IA não participa da lista de discussão. Não responde às observações dos revisores. Não assume compromissos de manutenção. Não investiga uma regressão meses depois. Não responde por problemas de licença ou autoria.

O nome presente no Signed-off-by é o nome de uma pessoa, não o nome de um chatbot.

Por isso, a responsabilidade precisa permanecer humana mesmo quando grande parte do trabalho foi assistida por ferramentas.

O desenvolvedor deve revisar cada linha, verificar a origem da solução, analisar os riscos e compreender as implicações.

Caso não consiga explicar a alteração sem recorrer novamente ao modelo, provavelmente ainda não está pronto para submetê-la.

Transparência é necessária, mas não resolve tudo

As diretrizes do kernel recomendam transparência quando uma quantidade significativa do conteúdo foi produzida por ferramentas.

Isso pode incluir informações como:

• qual ferramenta foi usada;
• quais partes foram geradas;
• quais prompts orientaram a geração;
• como o resultado foi modificado;
• como a alteração foi testada.

Essa transparência ajuda o revisor a avaliar o nível de atenção necessário.

Entretanto, apenas declarar o uso da IA não transforma uma contribuição ruim em boa.

Uma etiqueta como “gerado com auxílio de IA” não substitui:

• pesquisa;
• entendimento;
• reprodução;
• teste;
• análise de impacto;
• acompanhamento da revisão.

A transparência é o começo da responsabilidade, não o fim dela.

O mantenedor não é o sistema de validação da sua IA

Talvez esta seja a principal reflexão deixada pelo ciclo do Linux 7.1:

O mantenedor de um projeto não deve ser tratado como o operador humano responsável por depurar as respostas do seu chatbot.

Quando enviamos uma saída bruta ou superficialmente revisada, não estamos oferecendo produtividade ao projeto. Estamos pedindo que outra pessoa complete nossa investigação.

É muito fácil confundir atividade com contribuição.

Gerar vinte relatórios não representa necessariamente mais valor do que investigar profundamente um único problema, construir uma correção correta, testá-la e acompanhar sua integração.

A métrica relevante não deve ser a quantidade de mensagens, issues ou pull requests. Deve ser o valor líquido entregue depois de descontado o trabalho imposto à comunidade.

Uma contribuição que consome dez horas dos revisores para economizar vinte minutos do autor possui produtividade negativa.

Um filtro de bom senso para contribuições assistidas por IA

Antes de enviar uma contribuição gerada ou sugerida por IA, o desenvolvedor poderia aplicar um filtro simples.

1. Eu compreendo o problema?

Não apenas o texto produzido pelo modelo, mas a causa técnica, o contexto e as condições em que ocorre.

2. Consegui reproduzi-lo?

Um alerta abstrato tem valor limitado. Uma reprodução concreta transforma suspeita em evidência.

3. Pesquisei se ele já foi relatado?

É necessário consultar listas, issues, histórico de commits, documentação e versões recentes.

4. Sei por que a solução está correta?

Não basta observar que o código compila. É preciso justificar a decisão.

5. Realizei testes relevantes?

Além do caminho normal, devem ser considerados erros, limites, concorrência, arquiteturas e configurações afetadas.

6. A mudança é realmente necessária agora?

Uma melhoria válida pode estar sendo enviada na fase errada. Projetos maduros têm janelas e prioridades diferentes.

7. Consigo defender cada linha perante um mantenedor?

Se a resposta depender de perguntar novamente à IA, o entendimento ainda é insuficiente.

8. Permanecerei disponível após o envio?

Contribuir envolve responder, revisar, corrigir e eventualmente reconhecer que a proposta estava errada.

A IA deveria aumentar a qualidade, não apenas o volume

O melhor uso da IA em projetos colaborativos não é gerar o maior número possível de contribuições.

Ela deve ajudar o desenvolvedor a chegar mais preparado.

Pode ser utilizada para:

• explicar a documentação;
• resumir discussões antigas;
• mapear dependências;
• sugerir casos de teste;
• comparar abordagens;
• revisar uma hipótese;
• localizar pontos do código que precisam de investigação;
• ajudar a escrever uma descrição mais clara;
• apontar riscos que o autor deverá verificar.

Nesse modelo, a IA atua antes da contribuição, melhorando a qualidade do raciocínio humano.

No modelo inadequado, ela atua como uma fábrica de relatórios, patches e mensagens que são enviados sem filtragem.

A diferença não está apenas na ferramenta utilizada. Está na postura de quem a utiliza.

Projetos comunitários precisam considerar a capacidade de revisão

Uma fábrica pode aumentar a produção adquirindo novas máquinas. Entretanto, se não ampliar o controle de qualidade, o estoque e a logística, a eficiência geral pode piorar.

Algo semelhante ocorre no código aberto.

A IA multiplicou a capacidade de produzir código, mas não multiplicou na mesma proporção:

• o número de mantenedores experientes;
• o tempo disponível para revisão;
• os equipamentos de teste;
• o conhecimento acumulado;
• a capacidade de discutir decisões;
• a disposição para manter o código durante anos.

Portanto, o gargalo migrou.

Antes, produzir uma proposta era difícil. Agora, revisar milhares de propostas tornou-se o desafio central.

Isso exige políticas que não se limitem a perguntar se a IA é permitida. A pergunta mais importante é:

Esta contribuição reduz ou aumenta o trabalho total necessário para manter o projeto saudável?

Não precisamos escolher entre entusiasmo e rejeição

O debate sobre IA frequentemente é conduzido entre dois extremos.

De um lado, há quem apresente a tecnologia como substituta iminente do desenvolvimento humano. Do outro, há quem defenda sua rejeição completa.

A experiência do Linux 7.1 aponta para uma posição mais madura.

A IA pode ser útil. Pode encontrar defeitos reais, ajudar iniciantes, produzir testes e acelerar tarefas repetitivas.

Mas a utilidade potencial de uma ferramenta não garante a qualidade de todo conteúdo produzido por ela.

Precisamos avaliar cada contribuição pelos mesmos critérios fundamentais:

• correção;
• relevância;
• compreensão;
• testes;
• manutenção;
• responsabilidade;
• impacto sobre a comunidade.

Não devemos rejeitar um bom código apenas porque houve assistência de IA. Também não devemos aceitar um código ruim porque ele parece sofisticado ou foi produzido por uma ferramenta considerada avançada.

Conclusão

O lançamento do Linux 7.1 não demonstrou que a Inteligência Artificial é incompatível com o desenvolvimento de software livre.

Demonstrou algo mais importante: a capacidade de gerar conteúdo não pode ser confundida com a capacidade de contribuir.

Uma IA pode escrever um relatório, mas não possui compromisso com a comunidade. Pode sugerir um patch, mas não carrega a responsabilidade por sua manutenção. Pode encontrar um padrão suspeito, mas não conhece necessariamente todo o contexto que torna aquele comportamento correto ou incorreto.

O verdadeiro valor surge quando o desenvolvedor acrescenta aquilo que a máquina não oferece de forma confiável: compreensão, julgamento, prioridade, responsabilidade e bom senso.

Em projetos comunitários, ajudar não é apenas entregar mais conteúdo. É respeitar o tempo daqueles que precisarão analisá-lo.

A IA deve funcionar como amplificadora da competência humana, e não como multiplicadora de ruído.

Antes de enviar uma contribuição, talvez devamos fazer uma pergunta muito simples:

Estou entregando uma solução suficientemente investigada ou apenas repassando para a comunidade uma dúvida produzida pela minha ferramenta?

A resposta define a diferença entre utilizar IA para colaborar e utilizar uma comunidade para validar gratuitamente a saída de uma IA.