Debian adia decisão sobre contribuições geradas por IA

• A comunidade Debian discutiu se deve permitir contribuições de código baseadas em IA ou LLM, mas encerrou a discussão sem chegar a uma conclusão
• O rascunho proposto permitiria o uso sob condições como divulgação explícita do uso de ferramentas de IA, clareza sobre a responsabilidade e proibição do uso de informações sensíveis
• Os desenvolvedores divergiram sobre a ambiguidade do termo “IA”, o escopo de uso de LLMs e questões de qualidade, direitos autorais e ética
• Alguns se posicionaram contra, citando prejuízo ao onboarding de novos contribuidores, condutas corporativas antiéticas e incerteza jurídica
• Por enquanto, o Debian manterá a avaliação caso a caso com base nas políticas existentes, deixando aberta a possibilidade de continuar a discussão no futuro

---

Visão geral da discussão do Debian sobre contribuições com IA

• O Debian conduziu um debate interno sobre aceitar ou não código gerado por IA, mas o processo foi encerrado sem a apresentação de uma Resolução Geral (GR)
  • A discussão começou quando Lucas Nussbaum apresentou um rascunho para esclarecer a posição sobre contribuições assistidas por IA
  • Após coletar feedback, ele considerou uma submissão formal, mas a discussão perdeu força e a resolução não foi proposta
• O rascunho incluía obrigação de divulgar código gerado por ferramentas de IA, definição clara da responsabilidade do contribuidor, garantia de conformidade com segurança e licenças e proibição do uso de informações não públicas

Debate sobre definição de termos e distinções técnicas

• Vários desenvolvedores apontaram a falta de clareza do termo “IA” e enfatizaram a necessidade de especificar tecnologias concretas, como LLMs
  • Russ Allbery observou que “IA” é amplo demais e inadequado para servir de base a uma política
  • Sean Whitton propôs distinguir o uso de LLMs por finalidade (revisão de código, protótipo, código de produção)
  • Andrea Pappacoda comentou que projetos como Claude’s C Compiler não deveriam ser incluídos no Debian
• Em contraste, Nussbaum argumentou que mais importante do que o tipo de ferramenta é o próprio ato de geração automatizada de código

Onboarding de novos contribuidores e questão de custos

• Simon Richter manifestou preocupação de que a IA possa substituir oportunidades de aprendizado para novos desenvolvedores
  • Ele observou que, mesmo com orientação, a IA não aprende, e os recursos investidos pelo projeto não resultam em transferência contínua de conhecimento
  • Também foi levantada a preocupação de que o uso de IA possa criar dependência de ferramentas pagas, reduzindo a acessibilidade para contribuidores
• Nussbaum reconheceu que hoje há acesso gratuito, mas admitiu a possibilidade de problemas de custo no futuro
  • Ele rebateu afirmando que a IA pode, ao contrário, aumentar a acessibilidade a tarefas complexas
• Ted Ts’o se opôs à exclusão de usuários de IA, afirmando que isso seria contraditório e poderia limitar a diversidade de contribuidores

Discussão sobre ética, direitos autorais e qualidade

• Matthew Vernon defendeu que o Debian deveria se posicionar claramente contra a IA por causa da coleta antiética de dados por empresas de IA e do impacto ambiental
  • Ele apontou efeitos colaterais como violação de direitos autorais, geração de imagens sem consentimento e relatórios falsos de segurança
• Jonathan Dowland propôs restringir a aceitação de conteúdo gerado por IA até que a incerteza jurídica seja resolvida
• Thorsten Glaser argumentou que projetos que incluam código baseado em LLM deveriam ser movidos para a área non-free, mas a ideia não recebeu apoio devido ao risco de excluir projetos importantes como Linux kernel e Python
• Allbery observou que a polêmica sobre a qualidade do código de IA é pouco útil, já que humanos também podem escrever código ruim
• Bdale Garbee enfatizou a necessidade de encarar a IA como uma etapa evolutiva e observar seus impactos no longo prazo

Debate sobre a “forma preferida para modificação”

• Nussbaum respondeu que o input (prompt) de um LLM seria a forma preferida para modificação, mas a discussão continuou por causa do problema da não determinismo
  • Alguns argumentaram que, por ser não determinístico, um LLM é inadequado para reproducible builds
  • Outros rebateram que seria possível reproduzir os resultados mantendo a mesma seed de PRNG e o mesmo ambiente
  • O debate se expandiu para detalhes técnicos como determinism, reproducibility e assincronia em computação com GPU

Conclusão: Debian adia a decisão

• Dentro do Debian, não há consenso nem mesmo sobre a definição de contribuição gerada por IA
• Muitos avaliaram que ainda não é o momento de levar uma resolução a voto e que o mais adequado é continuar a discussão no nível da mailing list
• Nussbaum comentou que “permitir IA com salvaguardas” provavelmente seria o compromisso mais realista
• Por ora, segue valendo a avaliação caso a caso com base nas políticas existentes, e permanecem indefinidos os critérios para modelos de IA, código de LLM e contribuições geradas por IA
• Em meio a mudanças técnicas complexas e opiniões diversas, manter o status quo foi visto como a opção mais prática

[GN⁺]

Comentários no Hacker News

• Programei a vida toda, mas depois de uma lesão no pulso que tornou digitar quase impossível, consegui voltar a produzir código de alta qualidade graças a LLMs, autocompletar com IA e desenvolvimento baseado em agentes
  As alucinações (hallucinations) da IA acabam até ajudando a refinar prompts e deixar a intenção mais clara
  Do ponto de vista de acessibilidade, a IA é uma ferramenta essencial para mim, e acho que mais importante do que “o bom compensa o ruim?” é a postura de aceitá-la de forma integrada no ecossistema

  • Como você disse, há gente que usa IA de forma razoável, mas é perigoso presumir que todos os usuários fazem isso
    Alguns projetos estão sendo inundados por PRs de baixa qualidade, e em muitos casos os contribuidores só querem inflar o perfil no GitHub
    No fim, o importante é se a contribuição é feita de boa-fé (good faith), e os projetos precisam deixar claro qual é o limite aceitável
  • Eu também sigo uma abordagem parecida. Em vez de passar problemas difíceis para a IA, dou a ela a solução técnica que eu já pretendia implementar e peço que gere o código
    Isso reduz o cansaço da revisão e me permite focar só no que saiu diferente do esperado
  • Também tenho dor no pulso e uso a combinação Whisper + LLM para entrada por voz e organização. Automatizei desde e-mails e escrita de documentos até classificação de recibos, e isso ajuda até na saúde
    Hoje em dia, eu quase não gostaria de trabalhar em uma empresa que bloqueasse esse tipo de recurso
  • Eu também tenho RSI, e o autocompletar com IA ajudou muito. Mas a IA do tipo agente não é tão útil em ambientes de C++/Rust em tempo real
    O aspecto de acessibilidade é muito importante, mas as questões de direitos autorais e responsabilidade continuam complexas
  • Se alguém pode assinar o código e colocar sua especialização e reputação em jogo, a IA é só uma ferramenta avançada de autocompletar e deveria ser vista como exceção às regras de “no AI”

• Acho que revisão de PR (pull request) no fim das contas é uma questão de confiança. É acreditar que quem submeteu fez o melhor possível
  Mais importante do que usar IA ou não é se ela foi usada com responsabilidade

  • Claro, também existem agentes maliciosos. Ameaças persistentes avançadas (APT) como o ataque ao XZ são uma realidade até no open source
    Várias contas falsas podem ser um único atacante, e código feito por LLM parece aceitável para o próprio LLM, então a verificação fica ainda mais difícil
    No fim, chegamos a uma situação em que avaliar um PR ficou mais difícil do que produzi-lo
  • Ainda assim, eu continuo achando que todo código deve ser tratado como um potencial cavalo de Troia e verificado
  • O processo de revisão precisa ser robusto o bastante para encontrar erros, venham eles de humanos ou de IA

• O debate sobre a qualidade das contribuições com IA é estranho. A qualidade sempre foi responsabilidade de quem submete
  Usar IA não dá imunidade a isso e, pelo contrário, políticas que restringem o uso de IA podem acabar prejudicando apenas contribuidores de boa-fé

  • O problema é que código de LLM pode parecer bom por fora, mas na prática ser código implementado sem compreensão real
  • O importante não é a ferramenta, mas se o contribuidor consegue explicar e defender seu código durante a revisão
    Eu mantenho um fork com 300 commits usando IA, mas reviso cada linha e consigo explicar tudo
    No fim, o essencial é a qualidade da participação, não o tipo de ferramenta
  • A verdadeira constante é a responsabilidade. Se você submeteu um patch, precisa se responsabilizar pelo design e pela manutenção dele
  • Mas a IA pode levar as pessoas a tentar escapar dessa responsabilidade

• No longo prazo, à medida que a IA evoluir, parece que vai ficar difícil distinguir entre resultados de humanos e de IA
  Quando chegar a um nível “bom o suficiente”, vai parecer obra humana; fico curioso sobre o que acontecerá então

  • Não dá para impedir perfeitamente, mas acho melhor ter políticas definidas do que não fazer nada
    Hoje a maioria dos PRs com IA é de baixa qualidade, mas mesmo que a qualidade melhore, ainda pode haver rejeição por motivos legais ou ideológicos
  • No fim, contribuições com IA precisam ser vistas como uma extensão do indivíduo. A conta deve pertencer a uma pessoa real, e sua reputação precisa estar em jogo
  • Se de repente aparece uma quantidade enorme de código, dá para suspeitar de uso de IA. O importante não é se houve IA, mas se a pessoa entende o problema
  • A IA ainda continua presa à previsão token por token, então continua diferente de código projetado por humanos
    Abstrações excessivamente fragmentadas e refatorações desnecessárias são comuns
    Não vejo problema em humanos usarem IA como ferramenta, mas ainda estamos longe de um ponto em que a IA substitua o humano
    Ainda assim, o abuso de vibecoding está aumentando rapidamente os custos de revisão e manutenção
  • No fim, o código de quem usa corretamente não se distingue do código humano. O problema não é a ferramenta, e sim como ela é usada

• Minha posição é: “se funciona, isso basta”
  Se o código atende aos critérios de funcionalidade, documentação, testes e correção, tanto faz se foi escrito por IA ou por uma pessoa
  O importante é definir claramente o que significa “funciona” e ter um sistema de revisão competente

• A IA pode gerar milhares de linhas de código de uma vez e abrir um PR, mas no fim isso precisa ser limitado a um tamanho revisável
  Mesmo que a IA passe nos testes, é arriscado se quem enviou não entende o conteúdo
  São necessários limites de escopo do trabalho e histórico prévio de contribuições manuais

• A política do Debian é simples — “vamos evitar que alguém se machuque”. É um bom princípio

• Houve quem perguntasse se o Debian tem uma regra que proíba enviar código de outra pessoa como se fosse seu
  Na prática, isso já é ilegal por violação de direitos autorais, então existe de forma implícita mesmo sem estar explicitado
  LLM não é pessoa, mas os direitos autorais daquele código continuam pouco claros

• Não ligo para vibecoding em webapps ou apps móveis, mas usar IA em software de infraestrutura crítica como kernel, compilador ou sistema operacional é arriscado
  Nessas áreas, são necessárias linguagens com verificação formal como Ada/SPARK
  Dá medo pensar se um dia vamos andar em um carro com sistema de frenagem feito por IA

  • Concordo. Sistemas críticos exigem atenção minuciosa, e LLMs não têm nem a atenção nem o perfil de risco de direitos autorais adequado
  • Na verdade, ouvi dizer que a indústria automotiva já tinha muito código gerado automaticamente mesmo antes da IA

• Em comparação com “submeter código no estilo YOLO”, “usei IA, mas validei o máximo possível o código” é muito mais aceitável