Octubre ha dejado varias decisiones en proyectos de software libre que tienen que ver con lo mismo: cada vez llega más código, más revisión y más informes de fallos producidos con modelos de lenguaje. Unas veces eso se traduce en errores serios encontrados antes de llegar a los usuarios; otras, en horas de mantenedores que se van en leer parches que nadie entiende del todo. Repasamos cinco casos a partir de lo que dicen los propios proyectos en sus commits, listas de correo y notas de versión.
Linux ya tenía reglas, y en octubre las simplificó
El kernel documenta desde enero cómo tratar el contenido generado con herramientas en Documentation/process/generated-content.rst, y tiene un segundo documento, coding-assistants.rst, dirigido a los asistentes de IA. La idea central es que la responsabilidad no se delega: «se espera que entiendas y puedas defender todo lo que envías», y si no es así, los mantenedores «pueden rechazar la serie sin una revisión detallada». Pide transparencia sobre qué herramientas se usaron y con qué instrucciones, y deja claro que un agente de IA no puede añadir la línea Signed-off-by, porque solo una persona puede certificar el Developer Certificate of Origin. Para quien use un asistente para buscar fallos, exige intentar reproducirlos, escribir y probar el arreglo y decir explícitamente qué no se ha podido comprobar, porque «los mantenedores pierden demasiado tiempo» con informes sin verificar.
El 14 de octubre se fusionó en la rama de documentación un cambio de Sasha Levin que elimina la etiqueta Assisted-by, la que pedía marcar los parches hechos con ayuda de un LLM. El commit explica por qué: solo un 10 % aproximadamente de los 18.533 commits de Linux 7.3 (hasta la rc7) la llevaba, cuando el uso real es mucho mayor, así que su ausencia no decía nada. En la Maintainers Summit de 2026 hubo un consenso «fuerte, aunque no unánime» para quitarla. Los mantenedores siguen queriendo saber cómo se hizo un parche, pero eso pasa a explicarse en la carta de presentación de la serie. El cambio ya está en Linux 7.4-rc1, publicada el 1 de noviembre.
OverlayFS: veinte arreglos, buena parte de una revisión con IA
El caso más claro del lado útil está en OverlayFS, el sistema de ficheros por capas que usan los contenedores. El 31 de octubre Linus Torvalds fusionó los arreglos que le envió uno de sus mantenedores, Amir Goldstein: 20 commits, y la primera línea del resumen dice que son «correcciones de fallos encontrados por la revisión con IA de Chris Mason, varios de ellos alcanzables por usuarios sin privilegios». Hay una fuga de información, accesos a memoria ya liberada (use-after-free), desreferencias de punteros nulos, un bloqueo en el recorrido RCU de rutas con capas remotas y una pérdida de datos con la opción nfs_export.
El mismo envío trae también arreglos que no vienen de ahí: un fallo con el atributo security.capability vacío, que cualquier usuario podía poner para bloquear la copia a la capa superior, una regresión de la opción override_creds desde Linux 6.16 y dos correcciones de casefold. Todo entra en 7.4-rc1.
Un taint contra los informes basura que duró un mes
El otro caso del kernel muestra el problema contrario. En septiembre, Greg Kroah-Hartman añadió TAINT_FORCED_BIND, una marca (la letra Y) que el kernel se ponía a sí mismo en cuanto alguien escribía en los ficheros bind y unbind de sysfs, los que permiten asociar a mano un dispositivo con un controlador. El motivo, según el commit: herramientas de fuzzing como syzbot asociaban controladores al azar con cualquier dispositivo y eso generaba «montones de errores innecesarios y parches del kernel sin sentido» escritos por desarrolladores nuevos. Con la marca, quien recibe un fallo sabe que se provocó forzando esa asociación.
Entró en la ventana de integración de 7.4 y salió antes de la rc1. VFIO, la pieza que se usa para pasar dispositivos PCI a máquinas virtuales, depende precisamente de bind/unbind, así que flujos de trabajo normales dejaban el kernel marcado. Kroah-Hartman lo revirtió el 28 de octubre y Danilo Krummrich lo llevó a Torvalds el 30, con la idea de volver sobre ello después de 7.4. En el texto de la reversión, Kroah-Hartman dice que syzbot ya no hace esas asociaciones aleatorias y espera que nadie vuelva a hacerlo, «aunque con esta locura de los LLM de estos días, no se puede estar seguro».
RADV pone por escrito su postura
En Mesa, Samuel Pitoiset propuso el 27 de octubre añadir a la documentación de RADV, el controlador Vulkan para GPU de AMD, una política sobre contribuciones con LLM, y se fusionó el 2 de noviembre. En la solicitud de fusión explicaba que empiezan a llegar «algo más de MR hechas con LLM por colaboradores externos» y que preferían dejarlo claro «antes de que nos inunden».
El texto es corto. Las solicitudes de fusión asistidas por LLM «requieren entender bien el código, y revisarlas tiene un coste real»; los revisores pueden cerrarlas a su criterio. Si alguien encuentra un fallo y no sabe arreglarlo, que abra una incidencia. Las incidencias escritas por un LLM se desaconsejan porque «suelen ser largas y difíciles de leer», así que piden describir el problema con palabras propias. En cambio, los programas de reproducción generados con LLM se aceptan si quien los envía los ha revisado y de verdad muestran el fallo.
PostgreSQL 19, más tarde de lo previsto
PostgreSQL suele publicar su versión mayor en septiembre. Esta vez no. El 10 de octubre, Jonathan Katz anunció en pgsql-hackers que la versión final de PostgreSQL 19 se mueve al 19 de noviembre, con una segunda release candidate el 12, porque «dado el volumen de correcciones» que han entrado en las ramas, el equipo de publicación quiere incluirlas antes. Él mismo lo describe como «un ciclo de versión mayor atípico». La RC1 salió el 15 de octubre.
El anuncio no menciona la IA, pero la lista de desarrollo llevaba semanas discutiéndolo. A finales de agosto, Robert Haas pidió a un modelo de lenguaje que ordenara los parches de la versión 19 según cuántos fallos habían necesitado tras la congelación de funciones, y abrió el debate sobre si revertir alguno. Melanie Plageman planteó si la facilidad con que los LLM permiten «poner a prueba las funciones» hace que se encuentren más fallos y antes; Amit Kapila lo vio bueno para la estabilidad a largo plazo aunque a corto plazo haya más parches de limpieza; Daniel Gustafsson recordó que las grandes funciones de la 19 se escribieron y revisaron antes de que estas herramientas fueran tan buenas. Bruce Momjian añadió otro factor: hay «una cantidad enorme» de correcciones de seguridad que está apartando a mucha gente de otro trabajo. Es decir, más fallos detectados, pero alguien tiene que revisarlos y arreglarlos.
FreeRDP 3.33: WebAssembly y una avalancha de pull requests
FreeRDP 3.33.0, la implementación libre del protocolo de escritorio remoto RDP, salió el 2 de noviembre. La novedad principal es el soporte de WebAssembly, con el que el cliente puede ejecutarse dentro del navegador. Hay también soporte experimental de UDP para conexiones directas sin pasarela, vuelve (experimental) el servidor shadow de Windows, el portapapeles de ficheros en macOS ya no necesita FUSE y se empieza a traducir mensajes. La versión corrige 13 avisos de seguridad.
Las notas dicen que «la afluencia de pull requests y de comentarios sobre fallos y regresiones fue enorme», tanto que habrá pronto una versión de parche con lo que quedó pendiente. No dicen a qué se debe. El buscador de GitHub da una idea del salto: entre el 12 de octubre y el 2 de noviembre se abrieron 255 pull requests en el repositorio, frente a 91 en las tres primeras semanas de agosto, y la lista de cambios de esta versión incluye 20 colaboradores nuevos.
Lo que tienen en común
Ninguno de estos proyectos prohíbe la IA. Lo que se repite es que la persona que envía el parche tiene que entenderlo y responder por él, y que el tiempo de revisión es lo que más escasea. Hay proyectos que van más lejos, como AlpineBSD, que aparta en un repositorio propio los paquetes con código generado por IA. Y del lado de la seguridad, Canonical ya contó cómo responde a la oleada de vulnerabilidades que descubren los modelos y cómo usa su propia herramienta, Redhound, para cazar fallos de lógica. Las versiones del kernel y sus fechas están en la ficha de Linux, y lo que trae 7.4 para RISC-V, en este artículo.
Fuentes: Documentation/process/generated-content.rst y coding-assistants.rst; commit «docs: remove Assisted-by references»; merge «ovl-fixes-7.3»; commits TAINT_FORCED_BIND y su reversión; commit de la política de RADV y MR !45668; «Updated PostgreSQL RC / GA dates», anuncio de PostgreSQL 19 RC 1 e hilo «scary patch contest» en pgsql-hackers; notas de FreeRDP 3.33.0.