Patch do Emacs foi rejeitado após divulgação de vibecoding

• Um pequeno patch criado para melhorar o desempenho do Emacs no macOS foi enviado para a emacs-devel, mas não foi aceito por causa da política do GNU de não aceitar trabalho assistido por LLM
• O autor revelou que o GLM 5.2 encontrou o problema e criou o rascunho, mas afirmou que ele próprio assumiu a análise de exatidão e impacto, as correções, os testes manuais e a responsabilidade pessoal
• O patch rejeitado tinha escopo estreito e apenas 92 linhas; como ele poderia ter ocultado o uso de LLM, criticou a política por prejudicar a divulgação honesta mais do que o uso em si
• A preocupação do lado do GNU parecia estar mais ligada à abertura e à possibilidade de uso legal dos resultados de LLMs, mas ele discordou com base em modelos de pesos abertos e em casos reais de uso na indústria
• Ele disse que não trabalhará mais no Emacs e publicou apenas alguns patches verificados recentemente entre cerca de 40 patches de melhoria de desempenho que estavam em seu disco rígido

---

Trabalho de melhoria de desempenho do Emacs no macOS

• Przemysław Alexander Kamiński passou vários meses melhorando o desempenho do Emacs no macOS, dedicando tempo a conectar instrumentação e criar benchmarks
• Ele forneceu a base de código do Emacs a vários LLMs e pediu que encontrassem problemas específicos, mas, em geral, os resultados não foram bons
  • Ao analisar os patches, muitos tinham impacto pequeno ou entendiam mal o problema
• Na época, sua avaliação sobre os gargalos de desempenho era a seguinte
  • No macOS, os principais problemas são questões de renderização e thrashing de memória causado por alocações e liberações rápidas
  • A abordagem do malloc do sistema no macOS, por não ter compressão de memória, causa expansão de memória virtual e perda de localidade de cache
  • O core do Emacs ainda tem problemas de desempenho
  • O processamento de regexp é usado em vários lugares, então melhorias nele podem afetar o desempenho geral

Patch encontrado com o GLM 5.2 e processo de envio

• Ele recebeu de um amigo o plano z.ai Max e pôde usar o GLM 5.2, modelo que avaliou como bastante competente em otimização de código
• Com base no conhecimento que já havia acumulado, fez perguntas específicas sobre o Emacs e encarregou o GLM 5.2 de explorar e analisar problemas
• Depois de cerca de 3 horas, recebeu alguns relatórios; revisou as propostas e o código, testou o impacto de cada item e executou benchmarks
• Como preparar tudo para envio de patch leva tempo, escolheu o item mais promissor e trabalhou nele; dois dias antes de escrever o texto, enviou-o para a lista de discussão emacs-devel
• No dia seguinte, soube que o GNU tem uma política de não aceitar trabalho assistido por LLM, e que por isso o patch não seria aceito

Escopo do uso de LLM divulgado no e-mail de envio

• Ao enviar o patch para a lista de discussão, ele informou tanto o uso de LLM quanto o escopo de sua própria revisão
  • A descoberta do problema e o rascunho do patch foram feitos pelo GLM 5.2, que ele descreveu como um modelo chinês de pesos abertos
  • Ele analisou pessoalmente a exatidão e o impacto do relatório do problema
  • Revisou e corrigiu o patch
  • Testou o patch manualmente
  • Para fins legais, declarou a autoria da contribuição e disse estar preparado para defender que sua contribuição foi maior que a do LLM
  • Declarou que assumiria responsabilidade pessoal integral pela submissão
• A submissão tinha escopo de implementação muito estreito e também era pequena
  • O patch publicado tem 92 linhas e inclui em um comentário a razão de existir
• Ele não acha que esse patch possa ser classificado como “slop”, mas acrescenta que cada um pode julgar por si

Contestação da política do GNU

• Ele respeita a política do GNU, mas não concorda com ela e considera que não há base suficiente para a política
• Poderia ter ocultado o uso de LLM, mas o divulgou explicitamente, e avalia que isso acabou prejudicando sua submissão
  • Por isso, critica a política por punir a divulgação honesta mais do que o próprio uso de LLM
  • Como ele não confia em LLMs de forma alguma, acredita que trabalho assistido por LLM precisa de mais revisão e mais olhares, não menos
• O contexto completo da política é discutido em listas internas do GNU, portanto não é conhecido; ele resume que, em conversas anteriores, as dúvidas que encontrou pareciam estar mais relacionadas a se contribuições de LLMs são suficientemente abertas e se podem ser usadas legalmente
• Ele não concorda com a lógica de questionar a abertura de modelos de pesos abertos
  • Por exemplo, considera absurda uma distinção do tipo: usar o Qwen 3.6 em ambiente local seria aceitável, mas usá-lo via OpenRouter não seria
  • O GLM 5.2 é um modelo de pesos abertos e, com 256 GB de RAM e 24 GB de VRAM, poderia ser executado localmente para evitar o argumento de que “SaaS é fechado”
  • Como há muito conteúdo não livre na internet, ele questiona se, pela mesma lógica, o acesso à internet também deveria ser proibido ao criar submissões
• Ele também não concorda com as preocupações legais
  • Diz que empresas de jogos são mais sensíveis a IP e LLMs, mas ainda assim se vê uso de LLMs; que o ChatGPT tem 1 bilhão de usuários ativos; e que centenas de milhares a milhões de organizações usam saídas de LLMs todos os dias
  • Ressalvando que não é advogado nos EUA, entende que o problema de registro de direitos autorais recai sobre quem anexa a indicação de copyright
  • Não concorda com a postura de que o GNU acredita que seus próprios advogados e opiniões têm o maior peso

Fim do trabalho no Emacs e patches publicados

• Ele diz que o GNU tem liberdade para tomar suas próprias decisões e que ele também tem liberdade para criticá-las
• Critica o modo como a política é discutida internamente e sem transparência para os usuários, dizendo que isso é tão aberto quanto a Meta decidir internamente os rumos do Facebook
• Como resultado, afirmou que não trabalhará mais no Emacs
  • Diz não gostar de, em um trabalho voluntário, ouvir que está “segurando o bastão do jeito errado”
• Em seu disco rígido há cerca de 40 patches de melhoria de desempenho; alguns se sobrepõem entre si e, em alguns, o impacto real ainda não foi comprovado
• Ele publicou apenas alguns patches verificados recentemente que funcionam e mostraram impacto significativo, e afirma que esses patches realmente fazem diferença

[GN⁺]

Opiniões no Lobste.rs

• Parece que o autor entendeu errado o que significa o open de "open weight"
  Só porque o bloco final de matrizes está disponível publicamente e pode ser ajustado até certo ponto, isso não significa que os dados de treinamento usados para criá-lo também eram open source. O OSI seems to agree aparentemente vê isso de forma parecida, e, se for assim, a questão de direitos autorais não foi resolvida em nada
  Eu até simpatizo com alguém que quer contribuir de boa-fé e sem receber nada por isso, mas a GNU deixou as regras claramente escritas, e se alguém vai lá e diz "quebrei só um pouquinho, aqui está o patch", não é nada estranho ser rejeitado. O motivo da rejeição não foi a honestidade, e sim o fato de ter feito algo que estava explicitamente proibido

  • Então drivers escritos com base em datasheets cobertos por acordo de confidencialidade também não seriam software livre? E como ficaria o caso de um funcionário do fabricante escrever o driver usando documentação interna e conhecimento especializado?
  • Não entendo por que os dados de treinamento seriam relevantes. Se o resultado pode ser usado, redistribuído e modificado livremente, então eu diria que isso chega bem perto de ser open

• Espero que o autor aprenda hoje que bilhões de pessoas também podem estar erradas. Normalization of deviance não justifica o desvio; ela apenas descreve como esse desvio continua se espalhando
  Um dos padrões vistos em chatbot psychosis é perceber humanos que discordam ou apresentam opiniões diferentes como antagonistas. Os narremes aprendidos pelo chatbot incluem a perspectiva de que o usuário é o protagonista, com uma câmera sobre o ombro e uma narrativa pessoal fácil de ler. As narrativas preferidas pós-processadas do chatbot influenciam diretamente o usuário ao reforçar essa sensação de protagonismo, e, quando o usuário fica suficientemente ionizado, passa a não conseguir aceitar nem posições neutras
  Nesse caso, eu recomendaria ler a discussão original, que o autor não linkou nem citou. A comunidade do Emacs foi gentil com o autor, receptiva, fez perguntas, demonstrou interesse e teve uma postura acolhedora. Mesmo ao rejeitar o patch, falou de forma branda, focando na política da GNU em vez de atacar o autor

  • Honestamente, não colocar o link da discussão real no texto é um grande sinal de alerta. É difícil acreditar que eu não tenha percebido isso de cara
  • O artigo da Wikipedia sobre narremes tem só um parágrafo e está marcado com a tag [incomprehensible]
    Ainda assim, pelo contexto dá para entender o que significa, e parece um conceito útil e bem adequado aqui

• O GNU Project precisa considerar não só questões de copyright dos EUA, mas preocupações de copyright no mundo todo. Nem a lei dos EUA está completamente pacificada
  A GNU quer ter certeza de que detém 100% dos direitos autorais sobre contribuições importantes. A interpretação jurídica do autor aqui não importa; o GNU Project está escolhendo o caminho mais seguro. E isso sem nem começar a considerar outras preocupações que provavelmente já têm em relação a LLMs

  • Sinceramente, à luz da jurisprudência atual, o entendimento do autor sobre a lei dos EUA também está errado[1]. Pela jurisprudência existente, código gerado por LLM não pode receber proteção de direitos autorais e, portanto, não pode ser licenciado, entrando automaticamente em domínio público
    Além disso, se houver código gerado por LLM em um repositório e esse código não estiver claramente separado e identificado, então o repositório inteiro pode ser considerado impossível de proteger por direitos autorais ou de licenciar
    Em outras palavras, se o autor tivesse mentido para fazer o código ser aceito em commit, poderia ter colocado em risco a validade da licença de toda a base de código do Emacs
    Tudo isso é separado da atitude arrogante quase delirante de "não sou advogado, mas os advogados estão obviamente errados". Ele olha para apenas algumas partes das normas aplicáveis e, ao mesmo tempo, acusa os advogados de arrogância
    [1] Isso era o entendimento mais recente de quando tive essa conversa com o jurídico da empresa, há cerca de dois meses

• Não tenho certeza se "se eu tivesse mentido, teria sido aceito" é um argumento significativo

  • A mesma lógica pode ser aplicada a licenças. Você pode copiar algo de uma base de código proprietária e mentir dizendo que escreveu você mesmo, e o patch talvez seja aceito. Mas, se contar a verdade, ele será rejeitado. Então a conclusão é que licenças são ruins?
  • Exato. Ouço com frequência esse argumento de que, sobre políticas de no-LLM, "então as pessoas vão simplesmente mentir"
    Isso não diz nada de bom sobre essas pessoas, diz?
    Também não vejo por que seria bom importunar mantenedores por causa de políticas a favor ou contra LLM. Eles estão fazendo o trabalho deles e têm o direito de escolher quais contribuições avaliar, aceitar e rejeitar
    Claro, reclamar tudo bem. Essa pessoa está expondo sua posição no blog, e é assim que esse tipo de debate vai sendo alinhado. Só não concordo com o enquadramento. O problema aqui não é a "honestidade". Se a política no-LLM já tinha sido anunciada, então a responsabilidade por ter gasto tempo tentando contribuir com LLM para um projeto que não queria esse tipo de contribuição é da própria pessoa
    Isso não é diferente de oferecer a um vegano uma comida com carne ou queijo e depois reclamar que ele não quis comer porque você disse os ingredientes "honestamente". "Se eu não tivesse falado, ele nem teria percebido que tinha laticínio" não soa bem, e "se eu não tivesse falado, eles nem teriam percebido que usei LLM" também não
  • Concordo. Sugeri um novo título: Vibecoding gets Emacs patch rejected. A honestidade em admitir vibe coding é parecida com a honestidade em admitir violação de direitos autorais. A causa fundamental da rejeição não foi a honestidade
  • Acho que usar LLM e declarar isso honestamente já é motivo suficiente para rejeitar o patch. Usar LLM e mentir sobre isso é motivo não só para rejeitar o patch, mas também para impedir futuras tentativas de contribuição

• A GNU e a FSF investem bastante em consultoria jurídica profissional. Ainda assim, esse potencial colaborador está basicamente recomendando ignorar essa orientação profissional por causa do que alguma pessoa qualquer disse na internet
  Se você pagou por orientação especializada, o sensato é segui-la; se discorda, deve procurar outro especialista. Ignorá-la por conselho de um comentarista aleatório da internet não é "quase satírico", é simplesmente burrice

  • Contribuir para um projeto significa se expor e se colocar numa posição vulnerável. Isso pode ser ainda mais difícil de recusar quando "o código funciona" e resolve um incômodo pessoal
    Independentemente da recusa, parece bem provável que vejamos alguns casos judiciais interessantes no futuro. Provedores de grandes modelos podem passar a oferecer algum tipo de indenização e dizer "foi um código que ajudamos a criar, então você pode reivindicar os direitos autorais como quiser", ou, ao contrário, podem forçar a barra e dizer que o código é deles e que certos usos exigem licença. O Claude atualmente entrega o código ao usuário, mas não sei que tipo de indenização ele oferece. Também não sei bem sobre os outros modelos

• Você sabia que crime só é ilegal quando você é pego

• Não sou nem de longe um fã ardoroso da GNU, mas ferramentas de programação com LLM não são o completo oposto da filosofia GNU? Parece alguém levando um cachorro a um café de gatos e ficando bravo por ser expulso

• Acho muito desonesto ter mudado o título de "Honesty gets Emacs patch rejected" para Vibecoding gets Emacs patch rejected
  Mesmo que, como o autor, você tenha usado ajuda de ferramentas de IA, se investiu esse nível de tempo e compreensão no código, isso claramente não é vibecoding. Seria vibecoding se ele tivesse só jogado "deixe o Emacs mais rápido" para a IA e submetido o resultado de olhos fechados, mas pelo texto está claro que não foi isso que aconteceu

  • O título com "honesty" também era desonesto. O patch não foi rejeitado por honestidade, e sim por violar a política
  • Concordo com a interpretação do termo "vibecoding", mas como as pessoas usam esse termo de formas tão diferentes, não acho que chegue a ser tão desonesto assim
    Eu teria escolhido algo como "Breaking contribution policy gets Emacs patch rejected". Continua sendo uma alfinetada, mas é bem mais difícil de contestar

• O que salta aos olhos aqui é que o autor diz ter trabalhado de forma contínua por dois meses, mas explica que o modelo que usou para encontrar e corrigir o problema foi lançado há 12 dias
  Entendo que o autor esteja bem irritado, mas no fim das contas eu vejo open source menos como algo que te concede direitos e mais como o privilégio de poder usar um código que já foi criado. Se houver uma vantagem, provavelmente existe, e o que ele escreveu sobre o macOS está em grande parte correto, então os desenvolvedores do Emacs talvez reservem um tempo para analisar. Só que macOS provavelmente não é o foco principal deles

• Existe uma solução fácil para provar o quanto essa política é idiota. Basta deixar o diff do PR auxiliado por LLM no segundo monitor e, no monitor principal, reescrever manualmente todas as mudanças do zero. Também é só trocar um pouco os nomes das variáveis e o conteúdo dos comentários
  Agora virou código escrito por humano, então pode ser mesclado

  • Diante das questões autorais e legais envolvendo saídas de LLM em várias jurisdições ao redor do mundo, essa é uma visão bem ingênua