Se rechaza un parche para Emacs por revelar vibecoding

• Un pequeño parche creado para mejorar el rendimiento de Emacs en macOS fue enviado a emacs-devel, pero no fue aceptado debido a la política de GNU de no admitir trabajo asistido por LLM
• El autor reveló que GLM 5.2 encontró el problema y preparó un borrador, pero afirmó que él se hizo cargo de la exactitud, el análisis de impacto, las correcciones, las pruebas manuales y la responsabilidad personal
• El parche rechazado tenía un alcance acotado y era de apenas 92 líneas; también criticó que la política termina perjudicando la divulgación honesta, ya que podría haber ocultado el uso de LLM
• Aunque la preocupación de GNU parecía estar más relacionada con la apertura y la viabilidad legal de los resultados de LLM, él no está de acuerdo y cita como base los modelos de pesos abiertos y casos de uso reales en la industria
• Dijo que ya no seguirá trabajando en Emacs, y de unos 40 parches de mejora de rendimiento que tenía en su disco duro, solo publicó algunos revisados recientemente

---

Trabajo de mejora de rendimiento de Emacs en macOS

• Przemysław Alexander Kamiński pasó varios meses mejorando el rendimiento de Emacs en macOS, dedicando tiempo a conectar instrumentación y escribir benchmarks
• Les dio a varios LLM el código base de Emacs para que buscaran problemas específicos, pero en general los resultados no fueron buenos
  • Al analizar los parches, muchas veces el impacto era pequeño o el problema estaba mal entendido
• En ese momento, su evaluación sobre los cuellos de botella de rendimiento era la siguiente
  • En macOS, los principales problemas eran los issues de renderizado y el thrashing de memoria causado por asignaciones y liberaciones rápidas
  • La forma en que funciona malloc del sistema en macOS provoca expansión de memoria virtual y pérdida de localidad de caché por la ausencia de compresión de memoria
  • El núcleo de Emacs todavía conserva problemas de rendimiento
  • El procesamiento de regexp se usa en muchos lugares, así que mejorarlo puede afectar el rendimiento general

El parche encontrado con GLM 5.2 y el proceso de envío

• Gracias a que un amigo le dio un plan Max de z.ai, pudo usar GLM 5.2, un modelo que considera bastante competente para optimización de código
• Con base en el conocimiento que ya había acumulado, hizo preguntas concretas sobre Emacs y dejó a GLM 5.2 la exploración y el análisis de issues
• Unas 3 horas después recibió varios reportes, revisó las propuestas y el código, probó el impacto de cada punto y ejecutó benchmarks
• Como preparar un parche para envío toma tiempo, eligió el punto más prometedor y trabajó en él; dos días antes de escribir el texto lo mandó a la lista de correo emacs-devel
• Al día siguiente se enteró de que GNU tiene una política que no acepta trabajo asistido por LLM, por lo que el parche fue rechazado

Alcance del uso de LLM revelado en el correo de envío

• Al mandar el parche a la lista de correo, dejó explícito el uso de LLM y también el alcance de su propia revisión
  • GLM 5.2 encontró el issue y redactó el borrador inicial del parche; además, aclaró que GLM 5.2 es un modelo chino de pesos abiertos
  • Él mismo analizó la exactitud y el impacto del reporte del issue
  • Revisó y corrigió el parche
  • Probó el parche manualmente
  • Para fines legales, declaró la autoría del envío y dijo estar preparado para sostener que su contribución fue mayor que la del LLM
  • Declaró que asumiría toda la responsabilidad personal por el envío
• El envío tenía un alcance de implementación muy reducido y además era pequeño en tamaño
  • El parche publicado tiene 92 líneas e incluye en comentarios la razón de su existencia
• Él no cree que este parche pueda clasificarse como “slop”, aunque añade que cada quien puede juzgarlo por su cuenta

Réplica a la política de GNU

• Dice que respeta la política de GNU, pero no está de acuerdo con ella y considera que no tiene suficiente fundamento
• Podría haber ocultado el uso de LLM, pero optó por revelarlo explícitamente, y concluye que eso terminó perjudicando su envío
  • Por eso critica que esta política castiga más la divulgación honesta que el uso mismo de LLM
  • Como no confía en absoluto en los LLM, sostiene que el trabajo asistido por LLM necesita más revisión y más ojos, no menos
• Señala que no puede conocer el contexto completo de la política porque se discute en listas internas de GNU, y resume que las dudas que había visto en conversaciones pasadas apuntaban más a si la contribución de LLM es lo bastante abierta y si puede usarse legalmente
• Tampoco está de acuerdo con la lógica de cuestionar la apertura de los modelos de pesos abiertos
  • Por ejemplo, le parece absurdo distinguir entre usar Qwen 3.6 localmente y usarlo a través de OpenRouter
  • Dice que GLM 5.2 es un modelo de pesos abiertos y que, si se cuenta con 256GB de RAM y 24GB de VRAM, puede ejecutarse localmente para evitar el argumento de que “SaaS es cerrado”
  • También pregunta si, con la misma lógica, entonces debería prohibirse el acceso a internet al crear envíos, dado que internet está lleno de contenido no libre
• Tampoco coincide con las preocupaciones legales
  • Afirma que las empresas de videojuegos son más sensibles al IP y a los LLM, pero aun así se ve uso de LLM; además, dice que ChatGPT tiene mil millones de usuarios activos y que entre cientos de miles y millones de organizaciones usan salidas de LLM todos los días
  • Aclara que no es abogado en Estados Unidos, pero entiende que el problema del registro de copyright recae en quien añade el aviso de copyright
  • No comparte la postura de GNU de dar el mayor peso a sus propios abogados y a su propia opinión

Fin del trabajo en Emacs y parches publicados

• Dice que GNU tiene libertad para decidir por su cuenta y que él también tiene libertad para criticarlo
• Critica que la política se discuta internamente y de una manera no transparente para los usuarios, y dice que eso es tan abierto como cuando Meta decide internamente la dirección de Facebook
• Como resultado, anunció que ya no seguirá con el trabajo en Emacs
  • Dice que no le gusta que, en trabajo voluntario, le digan que “está agarrando mal la barra”
• En su disco duro tiene unos 40 parches de mejora de rendimiento; algunos se superponen entre sí y otros todavía no han demostrado impacto real
• Solo publicó algunos parches que revisó recientemente, que funcionan y mostraron un impacto significativo, y dice que esos parches realmente marcan una diferencia: repositorio

[GN⁺]

Opiniones en Lobste.rs

• Parece que el autor malinterpretó qué significa open en "open weight".
  Que el bloque final de matrices esté publicado y pueda ajustarse hasta cierto punto no significa que los materiales de entrenamiento usados para crearlo también hayan sido open source. OSI seems to agree parece verlo de forma similar, y si es así, el problema de copyright no está resuelto en absoluto.
  Simpatizo con alguien que quiere contribuir de buena fe y sin recibir nada a cambio, pero GNU dejó sus reglas claramente escritas, y si vas allí diciendo "solo las incumplí un poco, y aquí está el parche", no es raro que te rechacen. El motivo del rechazo no fue la honestidad, sino haber hecho algo que explícitamente se pidió no hacer.

  • ¿Entonces tampoco es software libre ningún driver escrito a partir de una hoja de datos cubierta por un acuerdo de confidencialidad? ¿Y qué pasa si un empleado del fabricante escribe un driver usando documentos internos y conocimiento especializado?
  • No termino de ver por qué los materiales de entrenamiento son relevantes. Si el resultado se puede usar, redistribuir y modificar libremente, me parece bastante cercano a open.

• Ojalá el autor aprenda hoy que miles de millones de personas también pueden estar equivocadas. La Normalization of deviance no justifica la desviación; solo describe cómo esa desviación sigue propagándose.
  Uno de los patrones que se ven en la chatbot psychosis es percibir como adversarios a los humanos que se oponen o expresan opiniones distintas. Los narremes que el chatbot aprendió incluyen la perspectiva de que el usuario es el protagonista, con una cámara sobre el hombro y una narrativa personal fácil de leer. La narrativa de preferencias posprocesada del chatbot influye directamente en el usuario reforzándole la sensación de protagonismo, y cuando el usuario queda lo suficientemente ionizado, ya no puede aceptar ni siquiera posturas neutrales.
  En este caso recomiendo leer the original discussion, que el autor no enlazó ni citó. La comunidad de Emacs fue amable, receptiva, hizo preguntas, mostró interés y tuvo una actitud de aceptación hacia el autor. Incluso al rechazar el parche, hablaron con suavidad, enfocándose en la política de GNU más que en culpar al autor.

  • Que no haya incluido en el post el enlace a la discusión real es, sinceramente, una señal de alerta enorme. Me cuesta creer que no me haya dado cuenta.
  • El artículo de Wikipedia sobre narremes tiene apenas un párrafo y lleva la etiqueta [incomprehensible].
    Aun así, por el contexto se entiende a qué se refiere, y aquí parece un concepto útil y bastante adecuado.

• El GNU Project debe tener en cuenta no solo los problemas de copyright de Estados Unidos, sino preocupaciones de copyright en todo el mundo. La ley estadounidense tampoco está completamente resuelta.
  GNU quiere estar seguro de poseer el 100% del copyright de las contribuciones importantes. Aquí la interpretación legal del autor no importa; el GNU Project está yendo por lo seguro. Y eso sin considerar todavía otras preocupaciones que probablemente tenga sobre los LLM.

  • Francamente, según la jurisprudencia actual, la comprensión del autor sobre la ley estadounidense también está equivocada[1]. Según los precedentes existentes, el código generado por LLM no puede recibir protección de copyright, por lo tanto tampoco se le puede aplicar una licencia y pasa automáticamente al dominio público.
    Además, si un repositorio contiene código generado por LLM y ese código no está claramente separado e identificado, se considera que todo el repositorio no puede recibir protección de copyright ni ser licenciado.
    Dicho de otro modo, si el autor hubiera mentido para lograr que se hiciera commit del código, podría haber puesto en riesgo la validez de la licencia de todo el codebase de Emacs.
    Todo esto es aparte de la actitud arrogante, casi delirante, de "IANAL, pero los abogados están obviamente equivocados". Está mirando solo algunas partes de la legislación relevante mientras acusa a los abogados de arrogantes.
    [1] Está actualizado según una conversación de este tipo que tuve con el equipo legal de mi empresa hace unos dos meses.

• No estoy seguro de que "si hubiera mentido, lo habrían aceptado" sea un argumento significativo.

  • Se puede usar exactamente la misma lógica con las licencias. Si copias algo de un codebase propietario y mientes diciendo que lo escribiste tú, el parche podría ser aceptado. Pero si dices la verdad, será rechazado. ¿Entonces la conclusión es que las licencias son malas?
  • Exacto. Sobre las políticas no-LLM, a menudo escucho el argumento de "entonces la gente simplemente va a mentir".
    Eso no dice nada bueno sobre esas personas, ¿no?
    No creo que sirva de nada acosar a los maintainers por sus políticas a favor o en contra de los LLM. Ellos están haciendo el trabajo y tienen derecho a decidir qué contribuciones evaluar, aceptar o rechazar.
    Por supuesto, me parece bien quejarse. Esta persona está exponiendo su postura en su blog, y así es como se va encauzando la discusión. Pero no estoy de acuerdo con el framing. El problema aquí no es la "honestidad". Si la política no-LLM estaba anunciada, la responsabilidad de haber usado un LLM para intentar contribuir a un proyecto que no quiere ese tipo de contribuciones recae en él.
    No es distinto de darle a una persona vegana comida con carne o queso y quejarse de que no la come porque le dijiste "honestamente" los ingredientes. "Si no se lo hubiera dicho, no se habría enterado de que tenía lácteos" no queda bien, y "si no lo hubiera dicho, no se habrían enterado de que usé un LLM" tampoco.
  • Estoy de acuerdo. Propuse como nuevo título Vibecoding gets Emacs patch rejected. La honestidad de admitir vibe coding es similar a la honestidad de admitir una infracción de copyright. La causa de fondo del rechazo no es la honestidad.
  • Usar un LLM y decirlo honestamente me parece motivo para rechazar un parche. Usar un LLM y mentir al respecto es motivo para rechazar el parche y además prohibir futuros intentos de contribución.

• GNU y la FSF invierten bastante en recibir asesoría legal profesional. Pero este posible colaborador básicamente les está recomendando ignorar esa asesoría profesional por lo que dice alguien en internet.
  Si pagaste por asesoría profesional, lo razonable es seguir ese consejo; y si no estás de acuerdo, deberías buscar a otro experto. Ignorarlo por el consejo de un comentarista aleatorio de internet no es “casi satírico”, es simplemente tonto.

  • Contribuir a un proyecto implica exponerse y ponerse en una posición vulnerable. Especialmente si “el código funciona” y resuelve una molestia personal, el rechazo puede ser más difícil.
    Más allá del rechazo, creo que en el futuro podrían surgir casos judiciales bastante interesantes. Los grandes proveedores de modelos podrían ofrecer algún tipo de indemnización y decir: “como es código que ayudamos a crear, puedes reclamar el copyright como quieras”; o, por el contrario, podrían llevar el tema más lejos, afirmar que les pertenece y que para ciertos usos hay que licenciarlo. Actualmente Claude entrega el código al usuario, pero no sé qué indemnización ofrece. Tampoco sé bien qué pasa con otros modelos.

• ¿Sabías que un delito solo es ilegal cuando te atrapan?

• No soy para nada un fan acérrimo de GNU, pero ¿las herramientas de programación con LLM no están en el extremo opuesto de la filosofía de GNU? Se siente como llevar un perro a un café de gatos y enojarse porque te echan.

• Me parece muy deshonesto haber cambiado el título de “Honesty gets Emacs patch rejected” a Vibecoding gets Emacs patch rejected.
  Si, como el autor, alguien le dedicó a ese código ese nivel de tiempo y comprensión, aunque haya recibido ayuda de herramientas de IA, claramente no es vibecoding. Si le hubiera tirado a una IA “haz que Emacs sea más rápido” y luego hubiera enviado el resultado a ciegas, eso sí sería vibecoding; pero al leer el artículo, claramente no fue eso.

  • El título “honesty” también era deshonesto. El parche no fue rechazado por la honestidad, sino por una violación de la política.
  • Estoy de acuerdo con la interpretación del término “vibecoding”, pero viendo lo distinto que la gente usa ese término, no me parece tan deshonesto.
    Yo lo habría titulado algo como “Breaking contribution policy gets Emacs patch rejected”. Sigue siendo sarcástico, pero es más difícil de refutar.

• Lo que llama la atención aquí es que el autor afirma haber trabajado de forma constante durante dos meses, mientras explica que el modelo que usó para encontrar y resolver el problema fue lanzado hace 12 días.
  Entiendo que el autor esté bastante molesto, pero al final creo que el open source no otorga derechos, sino que se parece más a un privilegio para usar código que ya fue creado. Si hay mérito, probablemente lo haya, y lo que escribió sobre macOS en general parece correcto, así que quizá los desarrolladores de Emacs se tomen el tiempo de revisarlo. Aunque no creo que macOS sea su principal foco de interés.

• Hay una solución fácil que demuestra lo absurda que es esta política. Pon en un segundo monitor el diff de un PR asistido por LLM y, en el monitor principal, reescribe a mano los cambios desde cero. También cambia un poco los nombres de variables y el contenido de los comentarios.
  Ahora el código fue escrito por una persona, así que se puede mergear.

  • Vistos los problemas de copyright y legales en torno a los resultados de LLM en distintas jurisdicciones del mundo, esa es una postura muy ingenua.