Flathub não permitirá envios baseados em LLM

• Nas revisões de envios do Flathub, aumentou o número de envios de baixa qualidade baseados em LLM, ampliando a carga sobre os revisores voluntários e motivando a clarificação da política
• As exceções provavelmente se aplicarão a projetos com participação da comunidade, ciclo de lançamentos, CI e sinais de que não são resultados de baixo esforço feitos em pouco tempo
• Só os critérios existentes de histórico de desenvolvimento e saúde do projeto não reduziram a carga de revisão; apenas aumentaram as disputas sobre a interpretação das regras
• A nova política não busca proibir aplicativos FOSS maduros que usaram LLM em parte nem todos os aplicativos proprietários existentes, mas sim bloquear envios de baixo esforço
• Alguns temem a volta da fragmentação da distribuição no ecossistema Flatpak e a evasão do Flathub por empresas, sugerindo cobrança de taxa em vez de proibição total

---

Mudança na política de envios com LLM do Flathub

• O ponto central por trás da mudança é o aumento de envios de baixa qualidade baseados em LLM nas revisões de envios do Flathub, o que elevou a carga dos revisores voluntários
• Sjoerd Stendahl afirmou que havia muitos envios de “AI-slop” na lista de PRs do Flathub e que, pela escala do problema, essa medida pode ser a melhor escolha
• Bart Piotrowski disse que projetos com participação da comunidade, ciclo de lançamentos, CI e sinais de que não são resultados de baixa qualidade feitos em pouco tempo provavelmente serão exceção
• Já se tentava barrar envios de baixa qualidade com base em histórico de desenvolvimento suficiente e na saúde geral do projeto, mas isso não reduziu a carga de revisão e apenas gerou disputas sobre a interpretação das regras

Exceções e critérios de maturidade

• Nexi considera real o problema dos envios de baixo esforço no Flathub, mas acha excessiva uma proibição geral de todo código gerado ou assistido por AI
• Sugeriu que, se até projetos existentes como Firefox, VSCode e Chromium pudessem ser removidos sem exceção, seria mais adequado um indicador objetivo de maturidade do projeto para filtrar envios de baixa qualidade
• Bart Piotrowski respondeu que critérios de maturidade já existiam na prática, mas no fim não conseguiram reduzir a carga de revisão
• Nexi considera que os critérios de exceção deveriam aparecer com clareza na política, junto com a observação de que código de qualidade muito baixa pode ser rejeitado sem explicação adicional
• Sjoerd Stendahl entende que a nova política abre exceção para projetos maduros e bem mantidos e não pretende proibir aplicações FOSS validadas que usaram LLM em parte nem todos os aplicativos proprietários já existentes

Impacto no ecossistema e preocupações com os canais de distribuição

• Dmitry Mantis teme que a política volte a criar a fragmentação da distribuição no Linux que o Flatpak tenta resolver
• O fato de apps proprietários como Slack e Spotify estarem disponíveis no Flathub em formato sandbox é uma vantagem, e ele questiona se código fechado acabaria até favorecido por não ser possível saber como foi escrito
• Também surgiu o contraponto de que aplicativos proprietários de desenvolvedores novos e desconhecidos talvez não devessem ser publicados imediatamente no Flathub mesmo sem essa política
• A tendência de alguns apps antes distribuídos só como AppImage começarem a oferecer Flatpak oficial é positiva, mas há preocupação de que empresas passem a evitar entrar no Flathub após esse tipo de política
• Também foi sugerido que cobrar uma taxa de envios baseados em AI para cobrir o custo da revisão seria melhor do que uma proibição total
• Isso pode soar como um sinal para distribuir em outro lugar até atingir certo nível de usuários, e apps bem mantidos que usam LLM em parte para testes ou automação de documentação podem perder o incentivo de migrar para o Flathub se se estabelecerem em outros canais

Avaliações opostas sobre ferramentas LLM

• Thomas Fuchs vê o problema dos LLMs como algo mais ligado a pessoas e marketing do que à tecnologia em si
• Ele critica empresas de LLM por venderem LLM como se fosse mágica ou um escravo pessoal de trabalho, e por usuários acreditarem nessas promessas ao pé da letra
• Quando usado por pessoas experientes que conhecem seus pontos fortes e fracos e o aplicam em usos limitados, pode ser uma ótima ferramenta; mas, segundo ele, o setor promove isso agressivamente como se estivesse “distribuindo de graça uma motosserra em chamas para malabarismo”
• Wolkensteine não considera que LLM seja totalmente inútil, mas acha que na maioria dos casos não é útil e que ainda não existem modelos úteis criados de forma eticamente defensável
• Modelos on-device podem ajudar em previsão de palavras para corretor ortográfico ou autocorreção no teclado do celular, mas em geral as tarefas que conseguem fazer sem erro são tarefas que humanos conseguem fazer facilmente enquanto aprendem
• Ember argumenta que até esses usos potenciais já eram possíveis com ferramentas anteriores à AI generativa e que, em casos raros, ML especializado treinado com dados específicos pode ser melhor
• Kroc Camen afirma que, por causa de roubo de código, vieses embutidos e impacto ambiental, LLM não tem uso válido em lugar nenhum

Cultura comunitária e polarização do debate

• trisweb considera que a cultura em torno do código gerado por LLM e de seus usuários muitas vezes não combina com a postura gentil e colaborativa necessária para sustentar comunidades open source
• ragectl acha que novos apps talvez precisem de uma filosofia parecida com um período de resfriamento, sendo mais arriscados até acumularem vários lançamentos e um segundo colaborador humano
• Sjoerd Stendahl diz que é preciso cuidado para evitar caça às bruxas, mas considera que a promoção agressiva de LLM por big tech aumenta a reação contrária das pessoas
• Segundo ele, alguns empregadores exigem o uso de LLM no trabalho sob ameaça de demissão, até funções simples como busca foram prejudicadas, e o “Agentic future” atende a uma demanda muito estreita, embora vários produtos estejam virando resíduos que imitam trabalho humano
• razze avalia que usar LLM em busca ou chatbot é um problema diferente de usar em código, já que código é verificável e os trade-offs são claros, então os casos devem ser julgados separadamente
• Zeeshan Ali Khan apontou a agressividade do campo anti-LLM, e Bart Piotrowski respondeu que a polarização é forte tanto entre pro-LLM quanto anti-LLM, e que os “vibecoders” também agem como vítimas quando são criticados

[GN⁺]

Opiniões no Lobste.rs

• “Não permitir aplicativos que incluam código, documentação ou outro conteúdo gerado ou auxiliado por IA” parece uma posição bem dura
  O Flathub é um lugar extremamente popular para usuários de desktop Linux baixarem apps, se autodenomina uma “loja de aplicativos para Linux” e tem mais de 1000 aplicativos
  Isso significa mesmo que nenhum desses aplicativos pode usar código auxiliado por IA? Isso é realista? Não já é tarde demais?

  • A frase “exceções podem ser permitidas para projetos maduros e bem mantidos” faz parecer que a intenção é mais impedir que subam projetos feitos totalmente com vibe coding e depois abandonados
  • Nunca é tarde demais
    Mesmo projetos já publicados no Flathub podem ser removidos se for descoberto que foram feitos com vibe coding, e isso também pode passar uma mensagem clara
  • Acho que essa regra deve ser aplicada com discricionariedade
    Alguns aplicativos importantes já existentes provavelmente podem ser reconhecidos como exceção e, mesmo nesses casos, a restrição provavelmente se aplicará mais ao empacotamento Flatpak independente do que ao código do aplicativo em si

• Essa abordagem dura talvez não seja 100% aplicável na prática, mas, numa situação em que empresas estão forçando a adoção de LLM, a comunidade precisa de uma posição forte como essa como forma mínima de resistência

• Pensando nos incidentes recentes ligados à cadeia de suprimentos, isso parece uma decisão bastante razoável

• Apoio 100% a liberdade de um projeto decidir o que quiser, seja proibir LLMs, pessoas de cabelo grisalho ou pessoas com exatamente 160 cm de altura
  Não estou dizendo que essa liberdade deva ser limitada, mas gerenciamento de pacotes é um trabalho repetitivo típico que pode se beneficiar bastante da ajuda de LLMs
  Até entendo, em certa medida, quem vê seu código como produto de arte pura ou artesanato, mas qual seria a razão para não deixar automatizar justamente as tarefas mais tediosas?

  Lembro que, quando o AUR do Arch Linux ainda estava começando, havia pessoas mantendo com sucesso centenas de pacotes
  Estavam sempre atualizados e quase nunca quebravam, então obviamente deviam estar automatizando as atualizações
  Fazer o mesmo hoje com assistência de LLM quase certamente poderia tornar isso ainda mais robusto

  Talvez seja preciso proibir humanos no processo
  Além de ataques à cadeia de suprimentos, o que exatamente os humanos têm a acrescentar? Algum dia eu deveria criar uma distribuição com LLM para provar se estou certo ou errado
  Mas antes preciso terminar esta linguagem de programação haha