Linux Foundation: los mantenedores ven 1 de cada 4 PR como AI slop

Los mantenedores de código abierto estiman que una de cada cuatro pull requests entrantes es «AI slop» de baja calidad, según un informe de la Linux Foundation publicado el 20 de octubre de 2026. La misma encuesta concluye que las herramientas de IA reducen en un 52 % el tiempo de escribir código, según las estimaciones. En conjunto, las cifras muestran que la IA acelera a los colaboradores, pero añade trabajo de revisión para los mantenedores que deben comprobar ese código.

El informe

El informe se titula «Navigating Open Source Software Development in the Generative AI Era» (El desarrollo de software de código abierto en la era de la IA generativa). LF Research lo publicó. Lo escribieron Sam Boysel, de la Linux Foundation, y Anni Lai, de la Generative AI Commons. Red Hat lo patrocinó, con el apoyo de Futurewei, la Open Source Security Foundation (OpenSSF) y LF AI & Data.

Una pull request, o PR, es un cambio de código propuesto que se envía a un proyecto para su revisión. «AI slop» es el término del informe para los cambios generados por IA que parecen plausibles pero son de baja calidad.

Todas las cifras son estimaciones de mantenedores y colaboradores, no recuentos medidos. Las fuentes consultadas no indican el número de personas encuestadas ni cuándo se hizo la encuesta.

Las cifras

La cifra principal es el 25 %: la proporción de pull requests entrantes que los mantenedores consideran AI slop. En los proyectos grandes, la estimación sube al 31 %, según el anuncio de la Linux Foundation. El agotamiento (burnout) de los mantenedores por las pull requests de IA de baja calidad es la principal preocupación en los proyectos grandes, según la página del informe.

Hallazgo	Proporción
Mantenedores que reciben más contribuciones desde la llegada de la IA generativa	59 % (69 % en proyectos grandes)
Mantenedores que dicen que la IA reduce la barrera de entrada	71 %
Mantenedores que no están de acuerdo en que la IA haya mejorado la confianza en la comunidad	53 %
Colaboradores que revisan y prueban por completo el código de IA antes de enviarlo	61 %
Proyectos con una política formal que permite el uso de IA	35 %
Proyectos sin política y sin planes de tenerla	32 %

El ahorro de tiempo varía según la tarea. Las personas encuestadas estiman un 19 % menos de tiempo en las discusiones de propuestas y un 52 % menos en escribir código. Pero un 21 % dice que la IA hace que las tareas de alta complejidad tarden más. Quienes ahorran tiempo lo dedican sobre todo a deuda técnica (66 %), nuevas funciones (63 %) y aprendizaje (58 %).

La mentoría divide opiniones. El 46 % de los mantenedores dice que la IA aumenta la necesidad de orientar a los nuevos colaboradores, mientras que el 32 % dice que la reduce.

Qué recomienda la Linux Foundation

El informe pide a los proyectos que dejen de reaccionar y fijen normas. «Los proyectos de código abierto deben diseñarse para una base creciente de colaboradores generada por IA, no limitarse a reaccionar ante ella», dijo Hilary Carter, vicepresidente sénior de investigación de la Linux Foundation.

Sus recomendaciones incluyen:

• Políticas escritas para las contribuciones asistidas por IA.
• Una declaración más clara cuando la IA ha ayudado a escribir un cambio.
• Que los colaboradores prueben y documenten los cambios asistidos por IA antes de enviarlos.
• Una forma estándar de reconocer las herramientas de IA en los commits.
• Tratar la gobernanza y la verificación como infraestructura esencial.

Un reconocimiento estándar está lejos de ser una realidad. El kernel de Linux se dispone a eliminar su etiqueta de IA «Assisted-by» después de que pocos commits la usaran, justo lo contrario de lo que recomienda el informe.

«Mantener seguro el código abierto es una responsabilidad compartida, y los mantenedores no deberían tener que cargar con ella solos», dijo Adrianne Marcum, chief of staff de la OpenSSF. Michael Larabel, de Phoronix, calificó la cifra del 25 % de «muy preocupante».

Qué significa para los desarrolladores

El informe pone cifras a un coste que los colaboradores rara vez ven: el tiempo de revisión que sus cambios asistidos por IA generan para otra persona.

• Prueba antes de enviar. Solo el 61 % de los colaboradores dice revisar y probar por completo el código escrito por IA antes de enviarlo. Ejecuta las pruebas del proyecto y lee tu diff línea por línea.
• Di cuándo te ayudó la IA. Hoy la declaración del uso de IA es irregular. Sigue las normas de atribución del proyecto o, si no las hay, indica el uso de IA en la pull request.
• Si mantienes un proyecto, escribe una política. Solo el 35 % de los proyectos tiene una. Una sección breve sobre el uso de IA en CONTRIBUTING fija expectativas antes de la próxima oleada de pull requests.
• Protege el tiempo de revisión. Las plantillas, las pruebas obligatorias y los límites de tamaño en las pull requests pueden filtrar los envíos de poco esfuerzo antes de que una persona tenga que leerlos.
• Sigue con la mentoría. Casi la mitad de los mantenedores dice que la IA aumenta la necesidad de mentoría. Quienes llegan nuevos y usan IA siguen necesitando a alguien que les explique cómo funciona el proyecto.