En pocas palabras: Sí: los proyectos open source están saturados de pull requests generados por IA sin revisión humana. Coolify reportó hasta 98% de spam y Godot rechazó cerca del 90% de las contribuciones IA. GitHub sumó la opción de restringir o pausar PRs para frenar la avalancha.
El “AI Slop” es código generado por modelos de lenguaje (LLMs) y enviado a proyectos open source sin revisión humana real. Suele ser sintácticamente correcto pero le falta contexto del proyecto, introduce bugs sutiles y consume el tiempo de mantenedores voluntarios. El término describe contribuciones de bajo valor que parecen útiles pero generan más trabajo del que ahorran.
En 30 segundos
- Volumen descontrolado: Coolify reportó hasta 98% de spam en sus PRs y Godot rechazó cerca del 90% de las contribuciones IA.
- GitHub reaccionó: sumó la opción de restringir o pausar pull requests cuando el spam se vuelve inmanejable.
- Más inseguro: el código IA tiende a introducir más bugs y vulnerabilidades de seguridad que el escrito con criterio humano.
- Costo humano real: mantenedores voluntarios se queman revisando basura y algunos abandonan sus proyectos.
- Hay defensa: sistemas de “vouching” (Tangled), políticas explícitas (LLVM, EFF) y revisión automatizada filtran lo peor.
¿Qué es el AI Slop y por qué ahoga a los proyectos open source?
Ponele que mantenés una librería que usan miles de personas. Abrís GitHub un lunes a la mañana y tenés 40 pull requests nuevos. Te ilusionás. Después las abrís una por una y son todas iguales: “arreglé un typo”, “mejoré el rendimiento”, “refactoricé esta función”. Ninguna entiende qué hace tu proyecto. Bienvenido al AI Slop.
A partir de 2023-2024, el fenómeno explotó con la adopción masiva de asistentes como GitHub Copilot, Codeium y los agentes autónomos que prometen “contribuir” solos. Cualquiera que quiera figurar en su perfil con una contribución a un proyecto famoso ahora puede tirarle el repo a un LLM y pedirle que “encuentre algo para mejorar”. El modelo siempre encuentra algo. Casi nunca vale la pena. Podés profundizar en plataformas como ChatGPT que generan código automático en nuestra cobertura completa.
El problema de fondo, como lo plantea el análisis de dev.to sobre el tema, es que no existe un “filtro de spam” para el trabajo generado por IA. El correo basura lo resolvimos hace 20 años. Las contribuciones basura, todavía no.
¿Cuál es el porcentaje real de rechazo de pull requests IA en Open Source?
Acá viene lo bueno: los números son brutales. No estamos hablando de un proyecto puntual que se quejó en Twitter. Es un patrón que se repite en proyectos grandes, chicos, de motores de juegos y de infraestructura.
- Coolify llegó a 98% de spam (reportado en 2025): el proyecto de self-hosting reportó que la enorme mayoría de las contribuciones entrantes no servían para nada.
- Godot rechazó cerca del 90% (a principios de 2025): el motor de juegos open source registró cientos de PRs generadas por IA y la mayoría terminó en la papelera.
- Mantenedores individuales: muchos reportan que la enorme mayoría de las PRs IA que reciben no aporta valor.
La gota que rebalsó el vaso llegó del lado de GitHub. La plataforma habilitó lo que muchos llamaron el “kill switch”: una opción para que los mantenedores restrinjan quién puede abrir pull requests, o las pausen del todo cuando la cosa se descontrola. CodeRabbit lo describió como un “acelerador” para regular el flujo. Que GitHub haya tenido que construir esto te dice el tamaño del problema.
¿Por qué el código IA parece bueno pero falla?
El engaño está en la superficie. Un LLM escribe código que compila, sigue las convenciones de indentación y hasta tiene comentarios prolijos. A primera vista parece la contribución de un dev senior. El tema es que la prolijidad no es lo mismo que la corrección.
¿Por qué fallan? Falta de contexto, básicamente. El modelo no sabe que esa función “redundante” que quiere borrar en realidad maneja un edge case que tardó tres años en aparecer. No conoce la decisión de diseño que está atrás de cada línea rara. Subís el cambio, lo probás en local, parece andar, lo mergeás y de repente se rompe un flujo que nadie tocaba hace meses porque el modelo “optimizó” algo que no había que tocar.
Los patrones más típicos del código basura:
- Refactorings sin cambio de lógica: reescriben una función entera para que haga exactamente lo mismo, ensuciando el historial de git.
- “Correcciones” de typos inventados: cambian palabras que estaban bien escritas o que eran nombres de variables a propósito.
- Cambios que rompen funcionalidad: los más peligrosos, porque parecen correctos hasta que un usuario reporta un bug en producción.
El costo oculto: ¿cómo afecta esto a los mantenedores voluntarios?
Acá está la parte que no se ve en las estadísticas. Detrás de cada proyecto open source hay personas que lo mantienen gratis, en su tiempo libre, muchas veces después de su trabajo real. Te puede servir nuestra cobertura de cómo funcionan los modelos de lenguaje modernos.
Revisar código tiene un costo mental que no desaparece porque el PR sea malo. Tenés que leerlo igual, entender qué intenta hacer, verificar si rompe algo y escribir una respuesta educada explicando por qué lo rechazás. Multiplicá eso por 40 PRs basura por semana y tenés a un voluntario quemado que termina abandonando el proyecto.
Las consecuencias ya son concretas. Mantenedores de proyectos de infraestructura crítica reportan que se la pasan filtrando reportes de vulnerabilidades falsas generadas por IA, y algunos voluntarios directamente abandonan los proyectos que sostenían. ¿La razón de fondo? Agotamiento.
El open source se sostiene sobre buena voluntad. Y la buena voluntad se gasta cuando pasás más tiempo filtrando basura que escribiendo código.
¿Qué vulnerabilidades de seguridad tiene el código generado por IA?
El problema no es solo el tiempo perdido. Es que parte de ese código, si se cuela, deja el proyecto más expuesto. Y los números no son menores. En herramientas de IA como Claude que automatizan tareas profundizamos sobre esto.
El código generado por IA tiende a introducir más bugs en general y más vulnerabilidades de seguridad que el escrito por humanos con criterio. Y lo más complicado: parte de esos defectos persiste en versiones recientes del código sin ser detectada. O sea, no es que se detecta y se borra rápido. Se queda.
¿Por qué pasa esto? Los LLMs aprenden de código existente, incluyendo código con malas prácticas. Reproducen patrones inseguros (inyecciones, manejo flojo de inputs, secretos hardcodeados) sin la malicia de un atacante pero con el mismo resultado. Si manejás infraestructura web, hosting o servidores con proyectos que dependen de estas librerías, esto te toca directo. Para ese tipo de stack conviene apoyarse en infraestructura confiable como la de donweb.com y mantener las dependencias auditadas.
¿Cómo se defienden los proyectos open source del spam de bots IA?
La buena noticia: no están de brazos cruzados. Hay respuestas que ya están funcionando, desde controles técnicos hasta políticas explícitas. Acá la tabla con las principales.
| Solución | Quién la usa | Cómo funciona |
|---|---|---|
| Restricción de PRs | GitHub | Pausar o limitar contribuciones a colaboradores verificados |
| Sistema de vouching | Tangled | Confianza explícita: alguien conocido te “avala” antes de contribuir |
| Política IA formal | LLVM, Ghostty, EFF | Aceptan IA pero exigen comprensión humana verificable del código |
| Revisión automatizada | PR-Agent (Qodo), CodeRabbit | Filtran y puntúan PRs antes de que las vea un humano |
Lo interesante es la diferencia de filosofía. GitHub apuesta al control de acceso. Tangled apuesta a la red de confianza. Y proyectos como LLVM o la EFF eligen no prohibir la IA, sino exigir que quien la usa entienda lo que está enviando y se haga responsable. Esta última me parece la más sana: el problema nunca fue la herramienta, fue mandar código sin entenderlo.
Cómo identificar y filtrar spam IA: guía para mantenedores
Si mantenés un proyecto, hay señales que delatan el slop antes de que te coma la tarde. Lo explicamos a fondo en tecnología GPT detrás de estos asistentes.
- Descripción genérica del PR: “mejoré el código” o “optimicé el rendimiento” sin explicar qué problema concreto resuelve.
- Refactor sin motivo: reescribe lógica que ya funcionaba, sin ticket, sin issue, sin discusión previa.
- Estilo inconsistente: el código no respeta las convenciones del proyecto porque el modelo no las leyó.
- Contribuyente sin historial: cuenta nueva, sin actividad real, que aparece de la nada con un PR ambicioso.
Del lado práctico: usá el flag --author de Git para rastrear patrones, sumá revisión automatizada como primera barrera, y sobre todo escribí una política explícita en el CONTRIBUTING. Si decís claramente “aceptamos IA pero tenés que entender y poder explicar tu código”, ya filtrás a la mayoría de los que solo querían figurar.
Errores comunes al manejar contribuciones IA
- Prohibir la IA por completo: es inaplicable y espanta a gente que la usa bien. Mejor pedí comprensión y responsabilidad, no prohibición.
- Mergear porque “compila y los tests pasan”: los tests existentes no cubren el edge case que el modelo rompió. El verde no garantiza nada sobre lógica nueva.
- Responder cada PR basura con un análisis largo: gastás energía que no tenés. Definí una respuesta corta y estandarizada para rechazar, y reservá tu tiempo para contribuciones reales.
Preguntas Frecuentes
¿Qué es el AI Slop en open source?
El AI Slop es código generado por modelos de lenguaje y enviado a proyectos open source sin revisión humana real. Es sintácticamente correcto pero carece del contexto del proyecto, por lo que suele introducir bugs o cambios inútiles que consumen el tiempo de los mantenedores.
¿Por qué los mantenedores rechazan tantas pull requests IA?
Porque la tasa de utilidad es bajísima: proyectos como Coolify reportaron 98% de spam y Godot rechazó cerca del 90%. La mayoría de las contribuciones IA no entienden el proyecto, repiten refactorings sin valor o rompen funcionalidades existentes.
¿Es más inseguro el código generado por IA?
Sí. El código IA tiende a introducir más vulnerabilidades de seguridad y más bugs en general que el escrito con criterio humano. Además, parte de esos defectos persiste en versiones recientes del código sin ser detectada.
¿Qué hizo GitHub para frenar el spam de bots IA?
GitHub habilitó una opción para que los mantenedores restrinjan quién puede abrir pull requests o las pausen por completo. Permite limitar las contribuciones a colaboradores verificados cuando el volumen de spam se vuelve inmanejable.
¿Hay que prohibir la IA en los proyectos open source?
No es lo recomendable. Proyectos como LLVM, Ghostty y la EFF aceptan IA pero exigen que el contribuyente entienda y pueda explicar su código. El problema no es la herramienta sino enviar código sin comprenderlo ni hacerse responsable.
Conclusión
El 2026 dejó claro que el open source tiene un problema nuevo y medible: las pull requests IA en Open Source que llegan en volumen industrial y se rechazan en un 90% o más. No es un capricho de mantenedores anti-tecnología. Es una respuesta racional a un código que parece bueno, falla seguido y es más inseguro.
La salida no es prohibir la IA. Es construir filtros: control de acceso como el de GitHub, redes de confianza como Tangled, revisión automatizada y políticas que exijan responsabilidad humana. Si contribuís a open source, la regla es simple: no mandes nada que no puedas explicar línea por línea. Y si mantenés un proyecto, escribí tu política de contribuciones hoy. El tiempo que te ahorrás es el que necesitás para seguir.
Fuentes
- Vincent Schmalbach – Open Source Maintainers Need a Spam Filter for AI Labor
- dev.to – Análisis técnico del problema y posibles soluciones
- CodeRabbit – GitHub da a los mantenedores un control sobre los PRs IA
- Axios – Los agentes IA saturan a los voluntarios que aseguran el software open source
- Signadot – Los mantenedores se ahogan en PRs generadas por IA