IA recorta 52% el código, pero 25% de los PR son ruido

El 25% de los pull requests que llegan a open source son ruido generado por IA

Uno de cada cuatro pull requests que reciben los proyectos de código abierto es de baja calidad, lo que los mantenedores ya llaman "AI slop". En los proyectos grandes esa proporción sube al 31%, según una encuesta de Linux Foundation Research presentada en el evento All Things Open en Raleigh, con patrocinio de Red Hat y apoyo de Futurewei, OpenSSF y LF AI & Data.

Para un founder que construye sobre open source —o que mantiene un proyecto propio como carta de presentación— el dato importa por una razón concreta: el cuello de botella del software libre dejó de ser escribir código y pasó a ser revisarlo. Y la revisión la hace gente que, en la mayoría de los casos, no cobra por ello.

¿Cuánto tiempo ahorra realmente la IA al programar?

El estudio midió seis actividades del ciclo de desarrollo. El resultado más citado es el de la escritura de código: los encuestados estiman una reducción media del 52% en el tiempo dedicado a esa tarea. Pero el ahorro no se queda ahí. Las discusiones de propuestas bajan un 19%, y el informe señala mejoras en todas las actividades medidas.

Leíste lo que hace la IA. ¿Y en tu negocio?

En CAR, dueños de empresa arman en 7 días su primer sistema funcionando: que ningún cliente se les escape, o que el informe del lunes salga solo. Con otros emprendedores al lado.

👥 Probar 7 días

Hay un matiz que casi nadie menciona y que cambia la conversación: para tareas de alta complejidad, el 21% de los encuestados reporta que tardó más con IA que sin ella. Es decir, la herramienta acelera lo repetitivo y puede frenar lo difícil, que es justo donde el criterio humano escasea.

¿Y qué hacen los desarrolladores con el tiempo que recuperan? Según el mismo informe, el 66% lo reinvierte en deuda técnica, el 63% en nuevas funcionalidades y el 58% en aprendizaje. No es tiempo libre: es tiempo reasignado a trabajo que antes se postergaba.

¿Por qué la IA acelera el código pero rompe la confianza de la comunidad?

Aquí está la tensión central del estudio. El 71% de los mantenedores coincide en que la IA generativa redujo las barreras para contribuir a open source. Es un dato positivo en teoría: más gente participando, más ojos sobre el código.

Pero el 53% no cree que la tecnología haya mejorado la confianza dentro de la comunidad. Y el 59% reporta un aumento del volumen de contribuciones desde la popularización de estas herramientas, cifra que llega al 69% en proyectos grandes.

Más contribuciones y menos confianza no es una contradicción: es la consecuencia lógica de bajar el costo de enviar algo sin bajar el costo de evaluarlo. El mantenedor absorbe toda la diferencia.

Hilary Carter, SVP de Research de la Linux Foundation, lo resume así: los proyectos "necesitan diseñar para una base creciente de contribuyentes generados por IA, no simplemente reaccionar a ella". Y añade que eso implica fijar expectativas claras, poner la responsabilidad de las pruebas y la divulgación en el contribuyente, y dar a los mantenedores mejores herramientas para gestionar los pull requests entrantes.

La gobernanza va dos años por detrás de la adopción

El dato más incómodo del informe es de gestión, no de tecnología. Solo el 35% de los proyectos tiene una política formal que permita el uso de IA generativa. Otro 32% no tiene política ni planes de tenerla.

Eso deja a la mayoría de la comunidad operando con reglas implícitas. Cada contribuyente decide por su cuenta qué declarar, cuánto probar y qué está bien visto. El resultado: el 61% de los contribuyentes dice hacer revisiones detalladas y pruebas funcionales completas del código generado por IA antes de enviarlo, pero la divulgación del uso de IA sigue siendo inconsistente.

Hay un detalle que suele pasarse por alto y que afecta directamente a la cultura de equipo: el 46% de los mantenedores afirma que la IA aumenta la necesidad de mentoría para nuevos contribuyentes, frente a un 32% que dice que la reduce. La herramienta no reemplaza al mentor; lo hace más necesario, porque ahora hay que enseñar a distinguir un aporte útil de uno plausible.

El caso curl: cuando el ruido se convierte en crisis de seguridad

El informe no es teoría. La misma semana, el proyecto curl anunció que moverá las vulnerabilidades de severidad baja y media a vista pública para proteger a un equipo de seguridad desbordado por reportes asistidos por IA.

Daniel Stenberg, mantenedor del proyecto, lo dijo sin rodeos: "Estamos luchando como proyecto, ya que todos los mantenedores clave nos sentimos tensos, sobrecargados y al límite de lo que podemos soportar".

El contexto ayuda a dimensionar el problema. Según reportó TechTarget, curl suspendió su programa de bug bounty a comienzos de 2026 tras años lidiando con reportes de baja calidad, y en julio el proyecto suspendió temporalmente la recepción de reportes de vulnerabilidades para aliviar la presión sobre su equipo. El programa había pagado más de US$100.000 por 87 vulnerabilidades confirmadas en siete años.

La ironía es que la IA también está encontrando fallos reales. ZDNET documentó que la plataforma de la startup Aisle identificó seis vulnerabilidades previamente desconocidas en curl que los mantenedores aceptaron y les asignaron números CVE. Y según el comunicado de la compañía recogido por Yahoo Finance, 18 de los 24 CVE corregidos en la versión de curl del 14 de octubre provinieron de su plataforma, dentro de un acumulado de 35 CVE y 160 bugs adicionales en el proyecto.

El problema, entonces, no es que la IA no sirva. Es que el volumen de hallazgos —buenos, malos y duplicados— supera la capacidad de triaje de equipos que en muchos casos son de dos o tres personas.

¿Qué significa esto para tu startup?

Si tu producto corre sobre dependencias open source, esto te afecta en dos frentes. Primero, en la cadena de suministro: los mantenedores de tus dependencias están bajo una carga que no existía hace dos años, y eso se traduce en tiempos de respuesta más lentos y parches que tardan más en llegar. Segundo, si tu equipo contribuye a proyectos abiertos —o mantiene uno propio—, ya estás recibiendo pull requests que parecen razonables y no lo son.

Tres acciones concretas para esta semana:

Escribe la política antes de que haga falta. Un documento de una página con tres reglas —declarar el uso de IA en el PR, probar el cambio antes de enviarlo, y explicar en el mensaje qué se verificó— resuelve más de lo que parece. El 32% de los proyectos sin política ni planes demuestra que la mayoría no lo ha hecho.
Mide el ruido antes de quejarte de él. Lleva una cuenta simple de cuántos pull requests recibes al mes y cuántos rechazas por falta de pruebas o contexto. Sin ese número no puedes justificar ni automatización ni cambios de proceso ante tu equipo o tus inversores.
Automatiza el primer filtro, no el juicio. CI que exija tests, plantillas de PR que obliguen a describir el cambio y bots que detecten diffs anómalos reducen la cola sin decidir por ti. La revisión final sigue siendo humana, y en proyectos grandes es el recurso más escaso.

La pregunta que viene: ¿quién paga el triaje?

El informe recomienda políticas escritas, requisitos de transparencia, pruebas obligatorias y atribución estandarizada. Todo razonable. Pero ninguna de esas medidas resuelve el problema económico de fondo: la IA multiplicó el volumen de contribuciones sin multiplicar el número de personas dispuestas a revisarlas.

Mark Collier, GM de AI & Infrastructure de la Linux Foundation, plantea el marco correcto cuando dice que el impacto de la IA en open source debe medirse "por la calidad de las contribuciones y la salud de las comunidades detrás de ellas, junto con las ganancias de productividad".

Para un founder, la lectura práctica es esta: la velocidad de escritura de código ya no es una ventaja competitiva, porque cualquiera la tiene. Lo que sigue siendo escaso es el criterio para decidir qué código merece entrar, quién lo revisa y cómo se documenta esa decisión. Eso no lo genera un modelo.

Fuentes

Leíste lo que hace la IA. ¿Y en tu negocio?

En CAR, dueños de empresa arman en 7 días su primer sistema funcionando: que ningún cliente se les escape, o que el informe del lunes salga solo. Con otros emprendedores al lado.

👥 Probar 7 días