Proibição de código gerado por LLM em dependências

• O git-annex passou por uma verificação durante o último mês, com cerca de 100 horas de trabalho, para garantir que possa ser compilado sem dependências que contenham código gerado por LLM
• Esse trabalho expõe a realidade de que é preciso acompanhar continuamente não apenas códigos individuais, mas toda a árvore de dependências, aumentando muito o ônus de manutenção
• Durante a verificação, foram encontrados casos como a reversão sem explicação de grandes alterações geradas por LLM, uma mudança de 10.000 linhas em uma base de código de 26.000 LOC e uma mensagem de commit inconsistente com 1.489 linhas
• O fato de terem sido obtidas informações adicionais sobre a qualidade das dependências é positivo, mas ainda há ceticismo quanto a respostas em nível organizacional de entidades como a Software Freedom Conservancy ou a FSF
• Mesmo que LLMs facilitem adicionar configurações ou fazer mudanças de formatação, esses commits podem gerar custos diretos para a confiança na colaboração e para a participação no projeto

---

Verificação das dependências do git-annex

• O git-annex investiu cerca de 100 horas ao longo de aproximadamente um mês para garantir que possa ser compilado sem dependências que incluam código gerado por LLM
• Até o momento, o objetivo parece ter sido alcançado
• Há uma página relacionada: git-annex no LLM code
• O ponto central do problema está no ônus de ter que revisar continuamente toda a árvore de dependências de um programa

Casos identificados durante a verificação e impactos

• Os casos encontrados não são apenas uma questão de preferência, mas levam a problemas de manutenção e confiança
  • Uma grande alteração gerada por LLM foi revertida sem qualquer explicação na versão seguinte
  • Uma mudança de 10.000 linhas entrou em uma base de código de 26.000 LOC, e a mensagem de commit tinha 1.489 linhas de conteúdo inconsistente
  • Havia um prompt para LLM pedindo para copiar código de outro projeto e, aparentemente por sorte, uma violação de direitos autorais foi evitada
• Com este trabalho, foram obtidas informações adicionais sobre a qualidade das dependências, e essas informações podem influenciar escolhas futuras
• A Software Freedom Conservancy parece ter deixado essa questão de lado em suas recomendações sobre IA generativa baseada em LLM, e é incerto se a FSF fará melhor
• Em meio a essas mudanças, a participação nas comunidades relacionadas está sendo reconsiderada, mas o trabalho e o suporte aos usuários continuam
• Pode parecer fácil dar a um LLM prompts como Add fourmolu config and restyled, neat ou format a module e commitar o resultado, mas é preciso considerar os impactos amplos dessa ação

[GN⁺]

Comentários no Lobste.rs

• Descobri hoje que o git-annex foi escrito em Haskell, o que é bem legal

  Hoje, no metrô voltando para casa, a pessoa ao meu lado estava assistindo YouTube Shorts no volume máximo, e aquilo me irritou porque era poluição sonora em um vagão silencioso e lotado
  O que me irritou ainda mais foi que o vídeo que ela estava vendo era um vídeo de baixa qualidade totalmente gerado por IA

  A anedota do texto sobre autores de dependências criarem mudanças difíceis de entender com LLMs me pegou
  A parte mais frustrante do mau uso de LLMs é que ele estraga nossas interações uns com os outros
  Antes, mesmo ao revisar uma proposta mal pensada na empresa, a ideia central ficava exposta, então era fácil identificá-la e comentar; agora qualquer pessoa pode colocar uma mudança mal pensada em um LLM e transformá-la em algo que parece bem estruturado à primeira vista, mas que fica cheio de buracos quando revisado
  Da mesma forma, também dá para criar código ruim que parece bom à primeira vista

  Não é uma reclamação nova, mas está começando a incomodar cada vez mais
  Sinto que estamos perdendo uma parte essencial da conexão humana que tornava o trabalho e a vida prazerosos e completos

  • Gosto quando um colega avisa honestamente “isso foi feito por um 🤖”, porque assim já sei de antemão que nível de revisão esperar
    Normalmente é a documentação de um processo usado para aprender mais sobre a base de código, então posso confiar que o colega leu a saída do LLM e quer confirmar se aprendeu direito

  • Acho que o que os LLMs mudaram foi o preço relativo da qualidade
    Usando casas como analogia: antes, uma McMansion horrível, com telhado vazando e fundação ruim, custava 1000X, enquanto uma boa casa sem problemas ocultos custava 2000X

    Agora, com a tecnologia de LLMs, uma pessoa experiente pode delegar parte do trabalho mecânico e fácil de verificar, reduzindo teoricamente o preço da boa casa para 1500X
    Mas a McMansion horrível caiu para 100X

    Por isso, é bem provável que McMansions de baixa qualidade desloquem trabalhos de qualidade de uma forma feia
    Não quero perseguir artesãos que reduzem uma boa casa de 2000X para 1500X, mas, se casas toscas de 100X expulsarem opções melhores do mercado e criarem um mercado de limões, os clientes podem passar a desconfiar muito mais de software como um todo
    Um mercado de limões é feio porque o comprador não tem como distinguir qualidade de lixo
    O exemplo mais famoso em software é o crash dos videogames de 1983, quando muitos clientes foram queimados por uma onda enorme de jogos porcaria e pararam de comprar

• Acho essa posição bastante razoável
  Pessoalmente, acho que com o tempo a maior parte disso vai acabar sendo esforço em vão e, no meu uso de software, não me preocupo muito com isso; mas, de um ponto de vista subjetivo, é algo totalmente válido e interessante, e acho bom que essa pessoa aja assim

  Assim como os otimistas de IA exageram, o lado anti-IA também tende a dramatizar demais os aspectos negativos
  Este texto em si é quase uma exceção, mas acho que a intenção e a mensagem como um todo teriam ficado muito mais fortes se o último parágrafo não tivesse uma generalização apressada

  Ainda assim, gosto de ler textos assim e procurar os pontos interessantes no meio das emoções
  Seria interessante ter um banco de dados da última versão conhecida com 100% de código não-LLM por projeto
  Também seria divertido ter um banco de dados de slop influente, em que “influente” signifique tanto positivo quanto negativo, e “slop” signifique especificamente saída não revisada

  Até daria para trapacear pegando um arquivo do GitHub do começo de 2023, mas seria mais interessante se fosse um snapshot do último commit por projeto, não apenas um snapshot de um ponto específico no tempo
  Parece haver muitos resultados interessantes que poderiam sair desse conjunto de dados, e ele também ajudaria pessoas que, como neste texto, querem criar um ecossistema composto apenas por software não-LLM

  Como você provavelmente já imagina, eu sou usuário de LLMs
  Ainda assim, acho que estou no lado razoável
  Se tiver curiosidade, pode ler os textos no meu site; prometo que o corpo dos posts do blog foi escrito 100% por uma pessoa
  Acho que ler opiniões contrárias é uma das melhores formas de aprender e crescer, então gosto de participar de iniciativas assim

  • Existe um projeto que chega perto de rastrear a última versão não-LLM por projeto
    Ele é mantido por pessoas bastante anti-IA em https://codeberg.org/ethical-foss/open-slopware
    Alguns projetos têm uma “última versão não contaminada ou ID de commit”, mas ele não cobre todos os projetos

• O motivo de eu ter enviado este texto é que gostei do fato de o autor ter procurado pessoalmente commits específicos que sugerem uso de LLMs nas dependências e criado uma página organizando o que encontrou

  Pessoalmente, não tinha certeza se deveria colocar a tag vibecoding, porque acho que o texto trata mais de comunidade e práticas do que de vibe coding

• Há um trecho que diz: “Sei que talvez, a esta altura, eu esteja tentando conter uma maré que avança”

  Se o compilador do qual o projeto depende for afetado, não há como vencer
  Eu também estou fazendo contenção de danos, mas no fim chega um momento em que insistir nas alternativas é pior, e você acaba tendo que ceder

• É um problema difícil
  Por melhor que seja a análise, provavelmente será difícil evitar código de LLM
  Por exemplo, código inserido por autocompletar não será detectado

• Acho que a confiança foi quebrada não quando essas bibliotecas começaram a usar LLMs, mas quando aceitaram e integraram mudanças enormes com mensagens de commit difíceis de ler e inúteis

  Isso é uma falha de engenharia de software independentemente do uso de LLMs

  Para constar, gosto do Joey Hess e do software dele, e estou no lado de que contribuições de código devem ser avaliadas pelos méritos do resultado, não importa com quais ferramentas tenham sido produzidas

• A forma como isso é explicado é um pouco decepcionante
  O commit de persistent não parece ter sido escrito por um LLM
  Eu gostaria que as pessoas não dissessem que todo commit com “Co-authored-by” foi gerado por LLM

  O primeiro link de yesod é uma mudança de CI, então não acho que dê para considerá-lo código do qual alguém depende
  Quando li “commit gerado por LLM com uma mensagem de commit de 1489 linhas”, achei que o commit em si estaria em um estado absurdo, mas na verdade é um squash merge razoável; a diferença é que o diff é enorme

  O commit de cabal diz que o LLM gerou apenas testes, e mesmo isso me faz questionar se devo considerar como código do qual dependo
  O commit de git também é apenas CI

  Não duvido que algumas dessas dependências usem LLMs, mas é difícil dizer que as evidências apresentadas se sustentam bem
  Por outro lado, é um trabalho que exigiu muito mais esforço do que eu esperava, e é bom haver algo concreto para apontar como motivo para não usar certas dependências