Prohibir código generado por LLM en las dependencias

• git-annex fue revisado durante el último mes, con unas 100 horas de trabajo, para asegurarse de que se compile sin dependencias que incluyan código generado por LLM
• Este trabajo deja en evidencia la realidad de tener que seguir monitoreando no solo código individual, sino todo el árbol de dependencias, lo que aumenta mucho la carga de mantenimiento
• Durante la revisión se detectaron casos como la reversión sin explicación de cambios grandes generados por LLM, un cambio de 10,000 líneas en una base de código de 26,000 LOC y un mensaje de commit incoherente de 1,489 líneas
• Es positivo haber obtenido información adicional sobre la calidad de las dependencias, pero sigue habiendo una visión escéptica sobre una respuesta a nivel organizacional de entidades como Software Freedom Conservancy o la FSF
• Aunque un LLM puede facilitar agregar configuración o hacer cambios de formato, esos commits pueden generar costos directos para la confianza en la colaboración y la participación en el proyecto

---

Revisión de dependencias de git-annex

• git-annex invirtió alrededor de 100 horas durante aproximadamente un mes para revisarse y asegurarse de poder compilarse sin dependencias que incluyan código generado por LLM
• Hasta ahora, parece que se alcanzó el objetivo
• Hay una página relacionada: git-annex no LLM code
• El punto central del problema está en la carga de tener que revisar continuamente todo el árbol de dependencias de un programa

Casos e impacto detectados durante la revisión

• Los casos identificados no son una simple cuestión de gustos, sino que derivan en problemas de mantenimiento y confianza
  • Un cambio grande generado por LLM fue revertido en la siguiente versión sin ninguna explicación
  • Se incorporó un cambio de 10,000 líneas en una base de código de 26,000 LOC, y el mensaje de commit tenía 1,489 líneas de contenido incoherente
  • Había un prompt para LLM que pedía copiar código de otro proyecto y, al parecer, se evitó por suerte una infracción de copyright
• Este trabajo permitió obtener información adicional sobre la calidad de las dependencias, y esa información podría influir en decisiones futuras
• Software Freedom Conservancy parece haber dejado pasar este problema en sus recomendaciones sobre IA generativa basada en LLM, y no está claro si la FSF lo hará mejor
• En medio de estos cambios, se está reconsiderando la participación en comunidades relacionadas, pero el trabajo y el soporte a usuarios continúan
• Darle a un LLM prompts como Add fourmolu config and restyled, neat o format a module y commitear el resultado puede parecer fácil, pero hay que considerar el impacto amplio de esa acción

[GN⁺]

Opiniones en Lobste.rs

• Hoy me enteré de que git-annex está escrito en Haskell, y eso está genial.

  Hoy, en el metro de vuelta a casa, la persona a mi lado estaba viendo YouTube Shorts al máximo volumen, y en un vagón silencioso y lleno eso era contaminación sonora, así que me irritó.
  Lo que más me irritó fue que el video que estaba viendo era contenido de baja calidad generado completamente por IA.

  Me resonó la anécdota de este artículo sobre autores de dependencias que crean cambios difíciles de entender con LLM.
  La parte más frustrante del mal uso de los LLM es que arruina nuestras interacciones entre personas.
  Antes, aunque en el trabajo revisara una propuesta pensada de forma floja, la idea central quedaba expuesta tal cual, así que era fácil detectarla y comentarla; ahora cualquiera puede meter un cambio flojo en un LLM y convertirlo en algo que parece bien armado por fuera, pero que al revisarlo está lleno de agujeros.
  Del mismo modo, también puede producir mal código que por fuera se ve bien.

  No es una queja nueva, pero cada vez empieza a molestar más.
  Siento que estamos perdiendo una parte esencial de la conexión humana que hacía que el trabajo y la vida fueran agradables y plenos.

  • Me gusta que un compañero me diga con honestidad “esto lo hizo 🤖”, porque así sé de antemano qué nivel de revisión esperar.
    Normalmente es documentación del proceso que usó para aprender mejor el codebase, así que puedo confiar en que mi compañero leyó la salida del LLM y quiere confirmar que aprendió correctamente.

  • Creo que lo que cambió el LLM es el precio relativo de la calidad.
    Con una analogía de casas: antes, una McMansion pésima, con goteras en el techo y malos cimientos, costaba 1000X, y una buena casa sin problemas ocultos costaba 2000X.

    Ahora, con tecnología de LLM, una persona experta puede delegar algunas tareas mecánicas y fáciles de verificar, y en teoría bajar el precio de una buena casa a 1500X.
    Pero la McMansion pésima cayó a 100X.

    Por eso es muy probable que las McMansions de baja calidad desplacen de forma horrible el trabajo de calidad.
    No tengo intención de molestar a los artesanos que bajan una buena casa de 2000X a 1500X, pero si las casas burdas de 100X desplazan del mercado a las mejores y crean un mercado de limones, los clientes podrían volverse mucho más desconfiados del software en general.
    Un mercado de limones es feo porque el comprador no tiene forma de distinguir la calidad de la basura.
    El ejemplo más famoso en software es el crash de los videojuegos de 1983, cuando una enorme ola de juegos basura quemó a muchos clientes y dejaron de comprar.

• Creo que esta postura es bastante razonable.
  Personalmente, creo que con el tiempo la mayor parte terminará siendo esfuerzo inútil, y en mi uso de software no me preocupa demasiado, pero desde un punto de vista subjetivo me parece una postura válida e interesante, y me parece bien que esta persona actúe así.

  Así como los optimistas de la IA exageran, el lado anti-IA también tiende a dramatizar demasiado los aspectos negativos.
  Este artículo en sí es más bien una excepción, pero creo que si se hubiera quitado la generalización apresurada del último párrafo, la intención y el mensaje general habrían quedado mucho más fuertes.

  Aun así, me gusta leer textos así y buscar lo interesante dentro de la emoción.
  Sería interesante tener una base de datos por proyecto del último código conocido 100% no LLM.
  También sería divertida una base de datos de slop influyente, donde “influyente” importe tanto en sentido positivo como negativo, y “slop” signifique salida no revisada.

  Uno podría hacer trampa más o menos tomando el archivo de GitHub de principios de 2023, pero sería más interesante que no fuera un simple snapshot de un momento específico, sino el snapshot del último commit por proyecto.
  Parece que de ese dataset podrían salir muchos resultados interesantes, y también ayudaría a quienes, como en este artículo, quieren construir un ecosistema solo con software no LLM.

  Como probablemente ya se imaginarán, soy usuario de LLM.
  Aun así, creo que estoy del lado razonable.
  Si les da curiosidad, pueden leer los textos de mi sitio web; prometo que el cuerpo de las entradas del blog fue escrito 100% por una persona.
  Creo que leer opiniones contrarias es una de las mejores formas de aprender y crecer, así que me gusta participar en intentos como este.

  • Hay un proyecto que se acerca a rastrear la última versión no LLM por proyecto.
    Lo administra gente entusiasta de tendencia anti-IA: https://codeberg.org/ethical-foss/open-slopware .
    Para algunos proyectos tiene la “última versión o ID de commit no contaminado”, pero no cubre todos los proyectos.

• Envié este artículo porque me gustó que el autor buscara directamente commits específicos que sugieren uso de LLM en sus dependencias y armara una página con sus hallazgos.

  Personalmente, no estaba seguro de si debía ponerle la etiqueta vibecoding, porque este artículo trata más sobre comunidad y prácticas que sobre vibe coding.

• Hay una parte que dice: “Sé que quizá a estas alturas estoy tratando de detener una marea que avanza”.

  Si el compilador del que depende el proyecto se ve afectado, no se puede ganar.
  Yo también estoy haciendo control de daños, pero al final llega un momento en que insistir con alternativas es peor y no queda más que ceder.

• Es un problema complicado.
  Por muy bien que se analice, probablemente sea difícil evitar el código de LLM.
  Por ejemplo, no se detecta el código que entró mediante autocompletado de código.

• Creo que la confianza se rompió no cuando estas bibliotecas empezaron a usar LLM, sino cuando aceptaron e integraron cambios enormes con mensajes de commit difíciles de leer e inútiles.

  Eso es un fracaso de ingeniería de software independientemente de si se usó LLM o no.

  Como referencia, me gustan Joey Hess y su software, y estoy del lado de que las contribuciones de código deben evaluarse por los méritos del resultado, sin importar con qué herramienta se hayan creado.

• La forma de explicarlo me decepciona un poco.
  No parece que el commit de persistent haya sido escrito por un LLM.
  Ojalá la gente no dijera que todos los commits con “Co-authored-by” son generados por LLM.

  El primer enlace de yesod es un cambio de CI, así que no creo que pueda considerarse código del que se dependa.
  Cuando leí “commit generado por LLM con un mensaje de commit de 1489 líneas”, pensé que el commit en sí iba a ser una locura, pero en realidad es un merge squash razonable; solo que el diff es enorme.

  El commit de cabal dice que el LLM solo generó tests, y me pregunto si eso también debería considerarse código del que dependo.
  El commit de git también es simplemente CI.

  No dudo de que algunas de estas dependencias usen LLM, pero cuesta decir que la evidencia presentada se sostenga lo suficiente.
  Por otro lado, es un trabajo en el que se puso mucho más esfuerzo de lo que esperaba, y está bien que haya algo concreto a lo que apuntar como razón para no usar ciertas dependencias.