La inteligencia artificial está inundando los proyectos de software libre con contribuciones de bajo valor — conocidas como "AI slop" o código basura — que utilizan a modelos como Claude para inflar artificialmente los perfiles de GitHub y obtener créditos en reportes de vulnerabilidades. Así lo denuncia Neil Alexander, mantenedor de proyectos open source, quien describe cómo en el último año el patrón de contribuciones externas ha cambiado drásticamente: predominan los pull requests sobre los reportes de issues, muchos de ellos generados íntegramente por IA, y los reportes de seguridad llegan acompañados de supuestas soluciones automáticas.
Según Alexander, resulta cada vez más sencillo pedirle a un modelo de lenguaje que identifique proyectos open source interesantes, que encuentre errores menores en ellos y que genere pull requests para corregirlos, sin que el usuario necesite usar el software ni preocuparse por su desarrollo. El resultado es la creación de una ilusión de competencia técnica que engaña a reclutadores y responsables de contratación, quienes suelen rastrear talento a través de la actividad en GitHub.
El autor relata un caso concreto: un contribuidor sin aportes en GitHub desde finales de 2018 presentó tres pull requests para corregir errores ortográficos en comentarios del código. Claude habría realizado las correcciones, redactado las descripciones, firmado los commits en nombre del usuario e incluso insertado su propia co-autoría. Alexander cerró las tres solicitudes sin comentarios, argumentando que aceptarlas establecería un precedente problemático y convertiría la lista de contribuidores en un premio por pedirle a un robot que corrija erratas.
La misma dinámica se repite con los reportes de vulnerabilidades. Los CVE (Common Vulnerabilities and Exposures) tradicionalmente acreditan a quienes reportan fallas de seguridad, y Alexander asegura que todos los reportes recibidos recientemente son "obviamente generados por IA". Aunque las correcciones de seguridad son siempre importantes, el mantenedor sospecha que muchos buscan simplemente un crédito fácil. Ante esta situación, su equipo ha comenzado a ser más selectivo al evaluar la gravedad de los reportes y, en algunos casos, ha decidido no emitir avisos CVE para vulnerabilidades de baja severidad.
El fenómeno no es aislado. Alexander es uno de varios mantenedores que han documentado públicamente esta tendencia en blogs y redes sociales durante 2025. La preocupación central es que el open source se construye sobre confianza, una variable que las métricas automatizadas no pueden capturar. El verdadero indicador de una contribución valiosa no es cuántos pull requests puede producir un modelo de lenguaje, sino si el cambio mejora de manera significativa un proyecto.
El problema tiene implicaciones más profundas. Si los mantenedores dedican tiempo a revisar contribuciones generadas por IA que no aportan valor real, se reduce su capacidad para atender problemas legítimos. Además, el colapso de la divulgación privada de vulnerabilidades —un proceso que requiere coordinación entre quien reporta y quien corrige la falla— se ve acelerado cuando los reportes masivos automatizados saturan los canales de comunicación. Algunos proyectos han comenzado a exigir pruebas de concepto funcionales o reproducción de la vulnerabilidad antes de tomar cualquier reporte en serio.
Para los reclutadores, la situación plantea un dilema: las señales tradicionales de GitHub —gráficos de actividad, avatares de contribuidores, historial de pull requests— se han vuelto menos confiables como indicadores de competencia real. Algunos expertos recomiendan a los procesos de contratación incorporar entrevistas técnicas más rigurosas o ejercicios prácticos que verifiquen habilidades más allá del currículum algorítmico.
El fenómeno del código basura generado por IA en open source llegó para quedarse. Mientras los modelos de lenguaje sean gratuitos o de bajo costo, existirán incentivos para utilizarlos con el fin de inflar perfiles técnicos. Los mantenedores, por su parte, enfrentan el dilema de cómo distinguir entre contribuciones genuinas y automatizadas sin desalentar a nuevos colaboradores legítimos. La respuesta de la comunidad, según Alexander, debe ser clara: contribuir porque se valora el proyecto, no porque se busca otro cuadrado verde en el perfil de GitHub.