O uso de inteligência artificial no desenvolvimento de software continua gerando debates acalorados dentro da comunidade open source. Agora, um dos projetos mais importantes do ecossistema Linux está considerando revisar sua postura sobre o assunto.
O QEMU, software de virtualização utilizado por soluções como o KVM e amplamente presente em distribuições Linux, pode abandonar sua proibição total a contribuições geradas com auxílio de inteligência artificial. A mudança foi proposta por Paolo Bonzini, engenheiro da Red Hat e um dos principais mantenedores do KVM.
A ideia não é abrir completamente as portas para o código produzido por modelos de linguagem como ChatGPT, Claude ou Copilot, mas sim criar regras mais específicas para situações consideradas de baixo risco.
De proibição total para uma abordagem mais pragmática
Até agora, a política oficial do QEMU era bastante direta: qualquer contribuição que pudesse ter sido criada ou derivada de conteúdo gerado por IA era rejeitada. A justificativa nunca foi técnica, mas jurídica.
Projetos de código aberto dependem do chamado DCO (Developer Certificate of Origin), um mecanismo que exige que os autores garantam possuir os direitos necessários para contribuir com determinado código. Como ainda existe incerteza sobre a origem dos dados usados no treinamento de muitos modelos de IA, também existe dúvida sobre a situação legal do conteúdo produzido por eles.
Segundo Bonzini, essa preocupação continua válida, mas o cenário mudou.
Em uma proposta enviada à lista de desenvolvimento do projeto, o mantenedor argumenta que a probabilidade dos riscos se concretizarem parece menor do que se imaginava inicialmente. Além disso, diversos projetos e empresas já vêm aceitando conteúdo assistido por IA sem enfrentar problemas legais significativos. Isso não significa que qualquer código gerado por IA será aceito.
O uso de IA seria permitido em atividades consideradas mais fáceis de revisar, substituir ou remover caso algum problema seja descoberto futuramente.
Entre os exemplos citados estão:
- Pequenas correções de bugs;
- Testes automatizados;
- Alterações mecânicas e repetitivas;
- Documentação.
Para correções de bugs, a sugestão é limitar as contribuições geradas por IA a mudanças de até 20 linhas de código, excluindo os testes. Já áreas mais sensíveis do projeto continuariam restritas.
Componentes centrais do QEMU, especialmente aqueles dos quais outras partes do software dependem, permaneceriam proibidos para contribuições assistidas por IA sem aprovação prévia de um mantenedor.
A lógica é: se um problema de licenciamento for descoberto anos depois, remover uma documentação ou um pequeno teste é relativamente fácil. Já substituir partes fundamentais da infraestrutura de virtualização pode ser uma tarefa muito mais complexa.
Outro problema: o desgaste dos mantenedores
Embora as discussões sobre direitos autorais costumem dominar o debate sobre IA, Bonzini chama atenção para outro efeito colateral que já está sendo sentido por diversos projetos open source.
O aumento da carga de revisão.
Segundo ele, ferramentas de IA reduziram drasticamente o esforço necessário para criar patches. No entanto, o custo de analisar, compreender e validar essas contribuições continua praticamente o mesmo e em alguns casos pode até aumentar.
Quando um desenvolvedor escreve manualmente uma alteração, normalmente espera-se que ele tenha refletido sobre cada linha do código enviado. Já com conteúdo gerado por IA, os revisores precisam verificar com mais cuidado se o autor realmente compreendeu aquilo que está submetendo.
Essa preocupação aparece em diversos projetos de software livre e vem sendo apontada como uma das possíveis causas para o aumento do desgaste entre mantenedores.
Em outras palavras, a IA pode aumentar a quantidade de contribuições recebidas sem necessariamente aumentar a qualidade delas.
Transparência passa a ser requisito
Para tornar o processo mais transparente, a proposta também introduz uma nova marcação nos commits. Contribuições que utilizarem IA de forma relevante passariam a incluir um campo chamado AI-used-for:
Esse marcador permitiria informar em quais partes a inteligência artificial foi utilizada.
Alguns exemplos sugeridos incluem:
AI-used-for: code
AI-used-for: tests
AI-used-for: docs
AI-used-for: research
O objetivo não é identificar qual ferramenta foi utilizada nem obrigar o envio dos prompts empregados durante o desenvolvimento. A intenção é oferecer contexto adicional para que os revisores possam avaliar melhor a contribuição. Mesmo com essa identificação, a responsabilidade continua sendo totalmente do autor.
O desenvolvedor que envia o patch ainda precisa assinar o tradicional “Signed-off-by”, declarando que entende e assume responsabilidade pelo conteúdo enviado ao projeto.
A discussão dentro do QEMU mostra como o relacionamento entre projetos open source e inteligência artificial está evoluindo. Nos primeiros anos da popularização dos LLMs, muitas comunidades adotaram proibições totais por precaução. Agora, conforme as ferramentas se tornam mais capazes e passam a fazer parte do fluxo de trabalho de cada vez mais desenvolvedores, alguns projetos começam a buscar soluções intermediárias.
Fique por dentro das principais novidades da semana sobre tecnologia e Linux: receba nossa newsletter!