La IA acelera el desarrollo open source, pero aumenta la carga de revisión y el riesgo de desgaste de mantenedores

Qué ha cambiado

La inteligencia artificial generativa está acelerando varias tareas del desarrollo open source, pero el aumento de velocidad no está llegando gratis.

Un nuevo estudio de Linux Foundation Research concluye que las herramientas de IA pueden reducir entre un 19% y un 52% el tiempo dedicado a distintas actividades de desarrollo abierto, mientras que los proyectos —especialmente los grandes— reciben más contribuciones, dedican más tiempo a revisarlas y afrontan mayor riesgo de desgaste de sus mantenedores.

La conclusión más útil no es que “la IA sea buena” o “la IA sea mala”. Es que productividad individual y salud de una comunidad no son la misma métrica.

QUÉ INVESTIGÓ LINUX FOUNDATION El informe, Navigating Open Source Software Development in the Generative AI Era, analiza cómo contribuidores y mantenedores están utilizando IA generativa y qué efectos perciben sobre: - volumen de contribuciones; - calidad de pull requests; - tiempos de revisión; - productividad; - confianza comunitaria; - políticas sobre uso de IA; - atribución; - pruebas y verificación; - mentoría de nuevos contribuidores.

La investigación se basa en una encuesta web de 45 preguntas. Se realizó entre abril y junio de 2026.

La muestra analítica es de 234 participantes cualificados. De ellos, 206 se identifican como contribuidores y 134 como mantenedores, con solapamiento entre ambos grupos.

El informe declara un margen de error de ±6,41% al 95% de confianza para la muestra global. Estos datos son importantes porque permiten interpretar correctamente los porcentajes posteriores.

UNO DE CADA CUATRO PR: QUÉ SIGNIFICA REALMENTE El dato que probablemente atraerá más titulares es este: los mantenedores encuestados estiman que, de media, el 25% de los pull requests entrantes son contribuciones de baja calidad generadas o asistidas por IA, lo que el estudio denomina “AI slop”.

En proyectos grandes, definidos como aquellos con más de 50 contribuidores, la estimación media sube al 31%. Pero RadarAbierto introduce aquí una precisión importante.

El informe no ha inspeccionado automáticamente todos los repositorios del mundo ni ha clasificado técnicamente una cuarta parte de cada PR. Ese 25% procede de una pregunta respondida por mantenedores.

La figura concreta utiliza una submuestra de 111 personas.

Por tanto, la lectura correcta es: “Los mantenedores encuestados estiman que alrededor de una cuarta parte de los PR que reciben son de baja calidad y/o generados con IA.” No: “Uno de cada cuatro PR de todo el open source es basura de IA.” La diferencia importa.

MÁS CONTRIBUCIONES, PERO TAMBIÉN MÁS TRABAJO DE REVISIÓN El 59% de los mantenedores encuestados afirma que el volumen de contribuciones ha aumentado desde el auge de la IA generativa. En proyectos grandes, esa cifra llega al 69%.

A primera vista esto parece positivo. Más personas pueden contribuir.

Más código puede llegar a los proyectos. Pero cada contribución crea también una obligación de revisión.

En proyectos grandes, el 64% de los mantenedores de la muestra correspondiente informa de aumento del tiempo de revisión. Y en ese grupo el desgaste de los mantenedores pasa a ocupar el primer puesto entre las preocupaciones.

Esto muestra un problema de escala. Reducir el coste de generar código también reduce el coste de generar código que otra persona debe revisar.

Si la creación se acelera mucho más que la verificación, el cuello de botella cambia de sitio. Ya no está únicamente en escribir.

Está en revisar, probar, explicar, rechazar y mantener. LA IA SÍ AHORRA TIEMPO El informe no es una crítica general a las herramientas de IA.

Los participantes declaran ahorro medio de tiempo en las seis actividades de desarrollo analizadas. Los valores van desde aproximadamente un 19% en discusiones y propuestas hasta un 52% en autoría de código.

La productividad, por tanto, es real dentro de la experiencia declarada por los encuestados. Pero también tiene límites.

El ahorro disminuye a medida que aumenta la complejidad de la tarea. En trabajos de alta complejidad, un 21% de los participantes afirma necesitar más tiempo cuando utiliza IA.

Esto encaja con una diferencia cada vez más importante: generar una primera solución puede ser rápido; entender el contexto, comprobarla, integrarla y asumir responsabilidad puede no serlo. QUÉ HACEN LOS DESARROLLADORES CON EL TIEMPO AHORRADO El informe también pregunta qué ocurre con el tiempo liberado por la IA.

Los participantes indican que lo reinvierten, entre otros usos, en: - deuda técnica: 66%; - desarrollo de nuevas funciones: 63%; - aprendizaje y mejora de habilidades: 58%. Esto contradice una interpretación simple en la que toda ganancia de productividad se convierte automáticamente en menos trabajo humano.

En esta muestra, parte importante del tiempo ahorrado vuelve al propio proyecto. Eso puede ser positivo si se traduce en mantenimiento, calidad y aprendizaje.

Pero depende de que exista capacidad para absorber el aumento de contribuciones que la propia IA genera. LA CONFIANZA NO CRECE AL MISMO RITMO QUE LA PRODUCTIVIDAD El 71% de los mantenedores considera que la IA reduce barreras de entrada al open source.

Sin embargo, el 53% discrepa de que la IA haya mejorado la confianza dentro de la comunidad. Esta tensión es central.

Una herramienta puede hacer más fácil participar y, al mismo tiempo, hacer más difícil confiar en cada aportación.

La comunidad necesita saber: - si el autor entiende lo que envía; - si lo ha probado; - qué parte fue generada por IA; - si puede mantener posteriormente ese código; - si respeta licencias y políticas; - si introduce riesgos de seguridad; - y quién asume responsabilidad cuando algo falla.

La velocidad no responde a esas preguntas. LA MAYORÍA DE PROYECTOS TODAVÍA NO TIENE UNA POLÍTICA CLARA Solo el 35% de los proyectos representados en la investigación dispone de una política formal que permite el uso de IA generativa.

Otro 32% no tiene política y tampoco planea crear una. Esto significa que la adopción tecnológica va por delante de la gobernanza.

En muchos proyectos, contribuidor y mantenedor todavía deben interpretar caso por caso: qué está permitido; qué debe declararse; qué nivel de revisión se espera; y qué responsabilidad mantiene la persona que presenta código asistido por IA. El informe recomienda pasar de una gestión reactiva a reglas explícitas.

REVISAR ANTES DE ENVIAR Hay también una señal positiva. El 61% de los contribuidores afirma que realiza revisión detallada línea por línea y pruebas funcionales completas del código generado por IA antes de enviarlo.

Pero la atribución es mucho menos consistente. El informe resume que aproximadamente tres de cada diez participantes siempre revelan asistencia de IA, mientras que dos de cada diez nunca lo hacen.

Por tanto, “revisar bien” y “declarar cómo se produjo” son dos problemas distintos. Un proyecto puede exigir ambos.

LA VERIFICACIÓN NO DEBE CAER ENTERA SOBRE EL MANTENEDOR Una de las ideas más importantes del informe es trasladar parte del coste de comprobación hacia quien crea la contribución.

Eso puede traducirse en requisitos como: - pruebas obligatorias; - documentación del cambio; - explicación de decisiones; - reproducción del problema; - disclosure de uso de IA; - cumplimiento de estilo y políticas; - evidencia de que el contribuidor entiende el código; - validaciones automatizadas antes de abrir el PR.

El objetivo no es prohibir la IA. Es impedir que la capacidad de producir más código se convierta simplemente en más trabajo gratuito para otra persona.

MENTORÍA: LA IA NO ELIMINA LA NECESIDAD DE PERSONAS El 46% de los mantenedores considera que la IA aumenta la necesidad de mentoría para nuevos contribuidores. Solo el 32% considera que la reduce.

Esto apunta a otra diferencia entre acceso y aprendizaje. Una persona puede producir antes una contribución funcional con IA sin haber adquirido todavía todo el conocimiento sobre: - arquitectura; - convenciones; - historia del proyecto; - criterios de aceptación; - seguridad; - mantenimiento futuro.

La IA reduce fricción de entrada. No necesariamente sustituye el proceso mediante el que una comunidad transmite contexto.

EL CASO DE CURL MUESTRA QUE EL PROBLEMA PUEDE EVOLUCIONAR El propio informe menciona un ejemplo que evita convertir “AI slop” en una tendencia inevitable. En 2025, el proyecto curl había descrito una avalancha de informes de seguridad de baja calidad generados con IA.

En abril de 2026, su responsable Daniel Stenberg señaló que ese tipo de informes había disminuido y que estaban recibiendo cada vez más informes buenos realizados con ayuda de IA.

Eso sugiere que el resultado puede cambiar con: - mejores modelos; - reglas más claras; - rechazo activo de contribuciones de baja calidad; - mejor comportamiento de usuarios; - y mecanismos de verificación.

Por eso RadarAbierto considera importante seguir esta cuestión como una tendencia, no congelar el porcentaje del 25% como una constante. LIMITACIONES DE LA INVESTIGACIÓN El informe aporta datos útiles, pero no representa una medición completa de todo el ecosistema open source.

Hay varias cautelas. Primero, la muestra es de 234 personas.

Segundo, muchas figuras utilizan submuestras porque no todas las preguntas se aplican a todos los participantes. Tercero, la encuesta se distribuyó mediante canales de Linux Foundation y socios de investigación, por lo que la población alcanzada está ligada a esas redes.

Cuarto, numerosas métricas son percepciones o estimaciones de los participantes. Quinto, los datos fueron recogidos entre abril y junio de 2026; el entorno de modelos, herramientas y políticas cambia con rapidez.

Por tanto, el informe sirve para detectar patrones y tensiones. No para afirmar que cada proyecto open source del mundo tiene exactamente la misma situación.

QUÉ APORTA RADARABIERTO RadarAbierto separa cuatro afirmaciones que pueden confundirse al resumir el estudio. Primera: la IA está reduciendo el tiempo declarado para varias tareas.

Eso está respaldado por la encuesta. Segunda: los mantenedores perciben más contribuciones y mayor carga de revisión, especialmente en proyectos grandes.

También está respaldado por la encuesta. Tercera: el 25% de “AI slop” es una estimación de una submuestra de mantenedores.

No es telemetría universal de GitHub, GitLab o todos los repositorios. Cuarta: la respuesta propuesta por el informe no es prohibir automáticamente la IA, sino introducir gobernanza, atribución, pruebas, verificación y mentoría.

Esta separación permite conservar la utilidad de los datos sin convertir un estudio de encuesta en una ley universal. QUÉ PUEDE HACER UN PROYECTO OPEN SOURCE Un proyecto que ya recibe contribuciones asistidas por IA puede revisar al menos estos puntos: 1.

publicar una política explícita sobre uso de IA; 2. definir cuándo debe declararse su uso; 3.

exigir que quien envía código pueda explicarlo y mantenerlo; 4. requerir pruebas antes del envío; 5.

automatizar validaciones repetibles; 6. documentar criterios de rechazo de contribuciones de baja calidad; 7.

proteger el tiempo de los mantenedores; 8. medir tiempos de revisión y volumen de contribuciones; 9.

mantener mentoría humana para nuevos colaboradores; 10. revisar periódicamente la política a medida que cambien modelos y herramientas.

Una política eficaz debería reducir incertidumbre tanto para quien contribuye como para quien revisa.

RECURSOS Linux Foundation Research — informe: https://www.linuxfoundation.org/research/oss-development-gen-ai-era-2026 Comunicado de resultados: https://www.linuxfoundation.org/press/new-lf-research-survey-shows-generative-ai-cuts-open-source-coding-time-in-half-but-25-of-incoming-pull-requests-are-considered-ai-slop Política de Linux Foundation sobre IA generativa y contribuciones: https://www.linuxfoundation.org/legal/generative-ai QUÉ SEGUIREMOS RadarAbierto seguirá: - nuevas mediciones basadas en repositorios y no solo encuestas; - evolución del porcentaje de contribuciones de baja calidad; - tiempos de revisión en proyectos grandes; - políticas de uso de IA en proyectos open source; - herramientas automáticas de triage y verificación; - estándares de atribución; - carga y desgaste de mantenedores; - y si mejores modelos reducen realmente el “AI slop” o simplemente aumentan todavía más el volumen de contribuciones.

Cómo ha evolucionado

Primer registro en RadarAbierto: 26/10/2026. Estado actual: actual.

Añadiremos los cambios posteriores sin borrar este registro.

Seguir el contexto

La señal conserva procedencia y relaciones internas para que puedas comprobar el origen y explorar cambios relacionados.