GitHub: la IA inunda de spam las listas awesome

Las listas awesome de GitHub ya no son la mina de oro que eran

91 pull requests abiertos en un repositorio con 13 estrellas. Esa desproporción, que el autor del blog Erik Gahner usa como ejemplo, resume el problema: las listas awesome —repositorios de GitHub que curan los mejores recursos de un tema— están dejando de ser la fuente confiable que fueron. Para un founder que arma su stack técnico copiando enlaces de ahí, el costo es concreto: horas perdidas evaluando herramientas que ya nadie mantiene o que nunca pasaron un filtro de calidad.

Qué son las listas awesome y por qué importaban

En GitHub existen muchos repositorios con el prefijo awesome: awesome-python, awesome-R y un largo etcétera. Durante años funcionaron como puerta de entrada a un ecosistema: si necesitabas librerías, tutoriales o datasets de un lenguaje o una industria, alguien ya había hecho el trabajo de seleccionarlos. Gahner lo dice sin rodeos: él las veía como minas de oro de buen contenido.

Hoy su veredicto es distinto. En una entrada publicada en su blog, sostiene que la mayoría le resulta irrelevante e inútil, y atribuye el cambio a dos causas relacionadas con la IA.

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

Un agente de IA puede quedarse con parte de tu día: ordenar lo pendiente y pedirte el OK antes de actuar. El Kit «tu mano derecha con IA» trae un video de 11 minutos y una ficha para dejar al tuyo trabajando. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

Por qué el material de las listas envejece tan rápido

La primera causa es la falta de mantenimiento. Muchas listas se crearon hace años y, si nadie las actualiza, acumulan material obsoleto. El ejemplo que da Gahner es elocuente: el repositorio awesome-R no se actualiza desde hace más de un año y uno de sus primeros enlaces es un resumen de los 50 paquetes más descargados, con datos de 2016.

La consecuencia práctica es que hoy es más rápido preguntarle a un modelo de IA decente por inspiración o por el material que necesitas. Gahner agrega un matiz interesante: si estas listas siguen siendo útiles para alguien, será sobre todo para agentes de IA que necesitan encontrar y verificar recursos.

El segundo golpe: pull requests generados por IA

El problema más ruidoso es la avalancha de aportes genéricos. Gahner señala que basta entrar a cualquier repositorio awesome para encontrar pull requests que sugieren las herramientas más genéricas posibles. Su caso testigo es awesome-free-online-tools: un repositorio chico, con 13 estrellas, que tenía 91 pull requests abiertos al momento de escribir.

El patrón se repite. Un mismo usuario creó al menos seis sitios web generados con IA —StatOrigin, ScanChess, Sticker Printer Hub, QuizQuip, LiquidityPools y DefiLPKit— y envió más de 100 pull requests a distintas listas awesome para agregarlos. Gahner encontró casos en los que esos aportes fueron aceptados, y otros en los que el mantenedor hizo el trabajo de verificación y los rechazó con una explicación contundente: no había evidencia suficiente de revisión por educadores calificados, validación independiente del contenido ni resultados de aprendizaje demostrados.

Qué dicen los datos: uno de cada cuatro pull requests es AI slop

Lo de Gahner no es una impresión aislada. Una encuesta de la Linux Foundation a 234 contribuidores y mantenedores de open source estimó que alrededor de una de cada cuatro contribuciones que llegan a la cola es de baja calidad o generada por IA, y que en proyectos con más de 50 contribuidores esa proporción se acerca a un tercio, según reportó Help Net Security.

El reporte de LF Research, presentado en el evento All Things Open, pone cifras más precisas: el 25% de los pull requests entrantes se considera AI slop, y en proyectos grandes sube al 31%. Además, el 59% de los mantenedores reporta un volumen creciente de contribuciones desde el auge de la IA generativa, porcentaje que llega al 69% en proyectos grandes. El mismo estudio encontró que la IA acelera el trabajo hasta un 50%, pero que el ahorro se reduce a medida que la tarea se vuelve más compleja.

Hay otro dato que debería interesar a cualquier equipo que contribuya a open source: apenas un tercio de los proyectos tiene una política formal que permita contribuciones asistidas por IA, y uno de cada diez las prohíbe. El resto no tiene nada escrito. Donde sí existen reglas, suelen pedir que el contribuidor declare el uso de IA y se responsabilice de revisar su propio trabajo. El kernel de Linux, por ejemplo, pide una línea "Assisted-by:" en el mensaje de commit que nombre la herramienta y el modelo usados.

El spam de IA ya rompió programas de bug bounty

El fenómeno no se limita a las listas curadas. Google congeló las presentaciones de vulnerabilidades de producto de su programa de recompensas para open source hasta al menos el primer trimestre de 2027, después de que miles de reportes inválidos generados por IA saturaran a sus equipos, según Android Headlines. El programa de parches verificados sigue abierto, con recompensas de hasta US$15.000.

El mismo medio recuerda que el creador de curl cerró su programa de recompensas en HackerOne por el mismo motivo, que los mantenedores del kernel de Linux se vieron desbordados por miles de reportes CVE automatizados y falsos, y que Intel retiró los premios económicos de su bug bounty. Help Net Security documenta además un giro positivo: tras declarar en 2025 que curl estaba desbordado por AI slop en sus reportes de seguridad, su líder Daniel Stenberg dijo en abril de 2026 que el proyecto había dejado de recibir ese ruido y estaba recibiendo reportes de seguridad cada vez mejores, casi todos elaborados con ayuda de IA.

En paralelo, las plataformas están vendiendo la solución. GitHub lanzó Code Quality, un producto que combina análisis estático con detección asistida por IA y que cuesta US$10 por committer activo al mes, según InfoQ. GitHub afirma que el 67,3% de los hallazgos que genera en su propia organización se resuelven antes de fusionar el pull request.

¿Qué significa esto para tu startup?

Tres implicancias concretas.

Primero, deja de tratar las listas awesome como documentación. Siguen siendo un buen punto de partida para descubrir nombres, pero no son un filtro de calidad. Antes de adoptar una herramienta que encontraste ahí, revisa dos señales objetivas: cuándo fue el último commit del repositorio y si el enlace apunta a algo vivo.

Segundo, si mantienes una lista curada —pública o interna—, escribe la política antes de que llegue el ruido. El reporte de la Linux Foundation muestra que la mayoría de los proyectos no tiene reglas. Un archivo CONTRIBUTING.md que exija declarar el uso de IA, verificar el recurso y explicar por qué aporta valor te ahorra cientos de horas de revisión.

Tercero, aplica el mismo criterio hacia adentro. Si tu equipo usa IA para generar código, define quién revisa y con qué estándar. El dato de que uno de cada cinco contribuidores nunca menciona que usó IA es una advertencia: en un equipo chico, la trazabilidad es más barata que el retrabajo.

Acciones que puedes implementar esta semana:

Audita tus bookmarks técnicos: elimina toda lista awesome sin commits en los últimos seis meses.
Crea un repositorio interno de recursos aprobados, con fecha de alta y responsable de cada entrada.
Si contribuyes a un proyecto abierto, adopta la convención "Assisted-by:" en tus commits.

Conclusión

Las listas awesome no están muertas, pero dejaron de ser un atajo confiable. El problema no es que la IA genere contenido, sino que bajó a casi cero el costo de enviarlo sin verificarlo. Para un founder, la lección es la misma que en cualquier otra fuente de información: la curación ya no es un bien escaso, el filtro sí. Quien construya ese filtro, con reglas explícitas y revisión humana, va a seguir sacando ventaja de un ecosistema que, en volumen, nunca tuvo tanto para ofrecer.