La inteligencia artificial ya escribe buena parte del código abierto y, al mismo tiempo, llena la bandeja de entrada de quienes lo revisan. ¿El dato? 25% de los pull requests (PR o peticiones para agregar código al proyecto), que llegan a proyectos abiertos son AI slop, esa es la etiqueta que LF Research usa para las aportaciones de baja calidad generadas con modelos que no compensan el tiempo de revisión que exigen a los mantenedores. El resultado es un cuello de botella nuevo, situado en la puerta de entrada y no en el teclado.
El dato salió el 20 de octubre de 2026 en un informe presentado en All Things Open 2026, en Raleigh, patrocinado por Red Hat y con el apoyo de Futurewei, OpenSSF y LF AI & Data. La misma encuesta pone número al ahorro: escribir código con ayuda de un modelo recorta un 52% el tiempo de esa tarea y el conjunto de actividades medidas se mueve entre el 19% y el 52%.
La paradoja está en quién paga la factura. La herramienta que acelera a quien escribe multiplica el trabajo de quien revisa, y el 64% de los proyectos grandes ya reporta revisiones más lentas. Con 234 respuestas válidas y un margen de error de ±6,41 puntos porcentuales, el estudio convierte una queja difusa en una cifra incómoda para toda la industria del software.
Una muestra de 234 personas, no una anécdota
El informe se titula Navigating Open Source Software Development in the Generative AI Era y lo firman Sam Boysel, científico de datos de la Linux Foundation, y Anni Lai, de Generative AI Commons.
La ficha metodológica es explícita: encuesta web de 45 preguntas, trabajo de campo entre abril y junio de 2026, 234 respuestas cualificadas y un margen de error de ±6,41 puntos con un 95% de confianza. La distribución se hizo por los canales de la Linux Foundation y de sus socios.
La muestra se reparte entre roles que a menudo conviven en la misma persona: 206 de los 234 encuestados se identifican como contribuidores y 134 como mantenedores. El 81% participa por interés personal, el 47% cobra de su empresa por hacerlo y el 52% de los contribuidores acumula once años o más de experiencia.
Conviene matizar dos cosas antes de citar el dato en una reunión. El porcentaje de slop es una estimación subjetiva de cada mantenedor sobre su propia bandeja de entrada, no un recuento automático de commits. Y el cuestionario circuló entre quien ya vive dentro del ecosistema, así que la muestra se inclina hacia los proyectos de infraestructura.
El ahorro real, tarea por tarea
Los encuestados estiman cuánto tardaban antes y cuánto tardan ahora con asistencia de modelos en seis actividades del ciclo de desarrollo. El resultado no es un promedio único sino una escala: el 52% de ahorro en la escritura de código cae hasta el 19% en las discusiones sobre propuestas, donde el trabajo consiste en leer, entender y decidir antes que en producir texto.
| Actividad medida |
Ahorro medio de tiempo |
| Escribir código |
52% |
| Discusión de propuestas |
19% |
| Discusión técnica y revisión de propuestas, solo mantenedores |
25% a 40% |
Ese reparto tiene una lectura clara para los mantenedores: la IA les quita carga en las tareas de coordinación, no solo en el teclado. Aun así, el informe reconoce un límite importante, y es que el 21% de los encuestados admite tardar más con IA en las tareas de mayor complejidad.
El tiempo ganado no desaparece. El 66% lo reinvierte en deuda técnica, el 63% en funciones nuevas y el 58% en formación, según las respuestas. Es decir, la IA no reduce la carga total del ecosistema: la desplaza hacia trabajo que llevaba años pospuesto, lo que a su vez genera más código que alguien tendrá que revisar después.
¿Quién paga la factura del filtrado?
El volumen es la primera mitad del problema. El 59% de los mantenedores constata más contribuciones desde la llegada de la IA, un porcentaje que sube al 69% en proyectos con más de cincuenta colaboradores. La segunda mitad es la calidad: ese 25% de media se convierte en 31% en los proyectos grandes y en 23% y 20% en los medianos y pequeños.
El desgaste sigue la misma pendiente. En proyectos pequeños y medianos la primera preocupación es la calidad del código; en los grandes, el primer puesto lo ocupa el agotamiento de los mantenedores.
Los co-mantenedores calculan un 29% de slop, casi seis puntos por encima de los mantenedores principales, y el 64% de los proyectos grandes alarga sus revisiones frente al 46% de los pequeños. Cada contribución basura cuesta, en la práctica, el rato de varias personas que podrían estar revisando parches útiles.
Muchos equipos han empezado a usar la misma tecnología para defenderse. Tres de cada cuatro mantenedores emplean herramientas de IA para filtrar contribuciones, sobre todo para resumir lógica compleja o buscar errores de borde, mientras que el 23% no usa ninguna. En esa línea trabaja Sashiko, la IA con la que el kernel busca su próximo gran bug.
Etiquetas, filtros y una trazabilidad que nadie cumple
Solo el 35% de los proyectos tiene una política formal que permita usar IA, el 32% no tiene ninguna ni piensa tenerla, el 23% planea aprobar una y el 10% la prohíbe de forma explícita.
Entre quienes ya escribieron reglas, el 76% exige declarar el uso de IA en la contribución, una fórmula que traslada la carga de la prueba al autor en lugar de vetar la herramienta.
La práctica va por otro camino. El 61% de los contribuidores revisa línea por línea y prueba el código generado antes de enviarlo, pero solo el 52% marca el trabajo asistido por IA la mayoría de las veces o siempre, y el 19% no lo marca nunca. El 80% considera importante saber con qué modelo y con qué datos se generó el parche.
El kernel de Linux lleva meses en ese debate. Su documentación todavía pide una etiqueta `Assisted-by` en los parches con ayuda de IA, y el 13 de octubre de 2026 se publicó en la lista de correo un parche para retirar ese requisito, después del consenso que, se alcanzó en el Linux Maintainers Summit de Praga.
La disputa sigue abierta y con discrepancias dentro de la propia lista de correo. En el extremo opuesto, muchos proyectos de GNOME prohíben cualquier contenido generado por modelos, una norma que Michael Catanzaro criticó en junio de 2026 por vetar también informes de fallos útiles.
Herramientas como Boro, el CLI en Rust con IA para auditar el kernel muestran la otra vía: automatizar el filtro en lugar de confiar en la declaración del autor. Aun así, el problema de fondo sigue siendo cuánto tarda una persona en validar el resultado.
El caso curl, donde el slop se puede desactivar
La historia de curl sirve de contrapeso al pesimismo. Daniel Stenberg, su mantenedor principal, contó en julio de 2025 que cerca del 20% de los informes de seguridad recibidos ese año eran slop, que solo el 5% acabó siendo una vulnerabilidad real y que cada informe moviliza a tres o cuatro personas del equipo durante media hora y hasta tres horas.
Desde 2019, el programa de recompensas del proyecto había validado 81 fallos reales con más de 90.000 dólares en premios. Ese historial era la prueba de que el modelo funcionaba, y el slop lo estaba rompiendo por el lado más barato: el de enviar sin comprobar.
Nueve meses después, el mismo proyecto cambió el signo. Según recoge la propia encuesta, en abril de 2026 Stenberg reportó que curl había dejado de recibir informes basura y que le llegaban cada vez más hallazgos buenos, casi todos hechos con ayuda de IA. El slop no es una propiedad fija de los modelos: depende del incentivo, del filtro y de lo explícitas que sean las reglas del proyecto.
Un cuello de botella que se mide en horas ajenas
El informe propone políticas escritas, atribución estandarizada y exigir que el autor pruebe su propio parche antes de enviarlo. Las tres recetas tienen el mismo efecto contable, que es devolver al autor un coste que hoy absorbe el revisor.
Nadie factura esas horas, y por eso el debate público sigue centrado en la velocidad de escritura mientras el embudo real está en la revisión. Como contamos al analizar cómo la IA cambia para siempre el desarrollo del software libre, la parte técnica avanza más rápido que la gobernanza.
Con un cuarto de las contribuciones entrantes en cuarentena y solo un tercio de los proyectos con normas claras, la pregunta rentable ya no es cuánto código ahorra un modelo, sino cuántas horas de mantenedor cuesta cada punto de ahorro.
