La primera serie de parches asistida por LLM de Linus Torvalds

Un destacado mantenedor del kernel de Linux ha usado un asistente de programación basado en LLM para redactar una serie de parches orientados al rendimiento, lo que ha desatado un debate sobre cómo encaja el código generado por IA con normas de larga data sobre revisión de código, copyright y licencias de open source. Los comentaristas sopesan las ganancias prácticas en productividad y exploración de código frente a preocupaciones sobre la calidad, la dependencia excesiva de servicios de IA propietarios, los impactos ambientales y sociales, y la mantenibilidad a largo plazo de una infraestructura crítica cada vez más tocada por código generado por máquinas.

Reacción general a los parches del kernel asistidos por LLM

  • A muchos no les sorprende que un mantenedor muy pragmático adopte los LLM, dado un cambio hacia la revisión/gestión más que la codificación práctica.
  • Otros sí se sorprenden, viéndolo como una ruptura con una imagen percibida de “vieja escuela” y con hostilidad previa hacia cosas como C++ en el kernel.
  • Algunos temen que esto se malinterprete como “si es lo bastante bueno para el kernel, es lo bastante bueno para cualquier cosa”, ignorando la experiencia y la revisión detrás de ello.

Calidad, fiabilidad y revisión

  • Se hace mucho hincapié en que la salida de un LLM solo es aceptable con revisión experta, pruebas y parches pequeños y comprensibles.
  • Los comentaristas señalan que los LLM a menudo producen código que parece correcto pero contiene errores sutiles (p. ej., condiciones de carrera).
  • Se establece una distinción entre usar la IA como asistente de programación y delegar programas complejos enteros haciendo solo una revisión superficial.

Cuestiones de copyright y licencias

  • Una línea de argumento: el código escrito por máquinas no es susceptible de copyright, por lo tanto no puede ser “open source” y debería excluirse del kernel.
  • Contraargumentos:
    • El contenido de dominio público o CC0 puede coexistir legalmente con licencias copyleft.
    • Pequeñas cantidades de código no susceptible de copyright o de dominio público son comunes y no son inherentemente “tóxicas”.
  • Un hilo aparte cita jurisprudencia previa a los LLM y posturas de la Oficina de Copyright de EE. UU. según las cuales solo los humanos pueden poseer copyright, reforzando el requisito de “humano en el circuito”.
  • Preocupación a largo plazo: si una base de código pasa a ser efectivamente no susceptible de copyright en exceso, su estatus legal podría volverse confuso.

Modelos cerrados frente a abiertos

  • Algunos están decepcionados de que un proyecto insignia de FOSS haya usado un asistente propietario en lugar de modelos de pesos abiertos.
  • Otros sostienen que los modelos abiertos actuales siguen siendo notablemente más débiles para la programación compleja de sistemas.
  • La justificación predominante es el pragmatismo estricto: elegir la herramienta que mejor funciona, sin importar si es abierta o no.

Actitudes más amplias hacia la IA en el software

  • Quienes la apoyan: ven mejoras rápidas, ganancias reales de productividad y consideran inevitable la asistencia de IA en infraestructura crítica.
  • Quienes son escépticos:
    • Les preocupa el “slopware”, el impacto ambiental, la expansión de los centros de datos y los efectos sociales a largo plazo (empleos, vigilancia, deepfakes).
    • Algunos hablan de boicotear proyectos asistidos por IA o de buscar sistemas operativos “libres de IA”.
  • Varios comentarios rechazan el encuadre de guerra cultural, distinguiendo entre usar la IA de forma responsable y abusar de ella.