AI Slop en GitHub: protocolo para rechazar PRs de IA

El problema que nadie quería admitir: el AI slop está inundando el open source

Imagina que eres el mantenedor de un proyecto open source con miles de usuarios. Un día comienzas a recibir, sin parar, pull requests que parecen razonables a primera vista pero que, al revisarlos, no compilan, ignoran por completo las guías de contribución o proponen cambios que ya fueron deliberadamente descartados hace meses. Eso no es una pesadilla hipotética: es la realidad que enfrentan hoy cientos de mantenedores en GitHub y otras plataformas de colaboración.

El fenómeno tiene nombre: AI slop. Son contribuciones de baja calidad generadas con herramientas de IA generativa —como GitHub Copilot Coding Agent, ChatGPT o similares— enviadas de forma masiva, sin comprensión real del contexto del proyecto. Y lejos de ser una molestia menor, se ha convertido en una amenaza concreta para la sostenibilidad del ecosistema open source tal como lo conocemos.

Qué es exactamente un pull request de bajo esfuerzo generado por IA

Un pull request (PR) de bajo esfuerzo generado por IA tiene características bastante reconocibles para quienes ya han visto unos cuantos:

Ignora o desconoce las reglas del archivo CONTRIBUTING.md del proyecto.
Propone cambios genéricos que no se relacionan con ningún issue abierto real.
Usa lenguaje corporativo y vago en la descripción: «This PR improves code quality and enhances performance».
No incluye tests ni documentación, o incluye tests que no pasan.
El autor no responde preguntas de seguimiento o, si responde, sus respuestas revelan que no entiende el código que supuestamente modificó.

Según Xavier Portilla Edo, mantenedor del proyecto Genkit, apenas 1 de cada 10 PRs generados por IA cumple los estándares mínimos para ser considerado legítimo. El resto representa horas perdidas de revisión que los mantenedores —en su mayoría voluntarios— jamás recuperarán.

Por qué esto es un problema urgente para los founders tech

Podrías pensar que esto es un asunto que solo les importa a los mantenedores de proyectos open source de nicho. Pero si construyes productos sobre dependencias open source —y casi cualquier startup tech lo hace— el impacto te llega directo:

Riesgo de seguridad: Código generado por IA que parece correcto pero contiene fallos lógicos puede colarse en librerías que usas en producción.
Mantenedor burnout: Cuando los mantenedores se cansan de revisar spam disfrazado de colaboración, abandonan sus proyectos. Eso significa dependencias sin mantenimiento activo.
Erosión de la confianza: El modelo de revisión de código se basa en un contrato social implícito: quien envía un PR lo entiende. Cuando ese supuesto desaparece, el costo de revisión se dispara y las comunidades se cierran.

En febrero de 2026, The Register reportó que GitHub está evaluando un «kill switch» para los PRs, que permitiría a los mantenedores deshabilitar las contribuciones externas o restringirlas únicamente a colaboradores de confianza. No es una solución elegante; es una señal de que el problema ya superó el umbral de lo gestionable con medidas suaves.

El protocolo que están adoptando las comunidades técnicas

Ante la avalancha, distintos proyectos han comenzado a implementar sus propios protocolos. Algunos son formales, otros son reacciones de emergencia. Aquí los más relevantes:

1. Cierre inmediato y bloqueo del usuario

Proyectos como scikit-learn y opencontainers/runc proponen —y en muchos casos ya aplican— el cierre automático de cualquier issue o PR donde el texto huela a generación por LLM, seguido del bloqueo del usuario. En el caso de runc, el argumento es categórico: incluso si el issue describe un problema real, el texto generado por IA contamina la discusión con alucinaciones y ruido.

2. El sistema de «vouching» de Plone

La comunidad Plone implementó una GitHub Action llamada «Vouch» que cambia radicalmente el modelo de participación: en lugar de confiar por defecto en cualquier contribuidor externo, ahora se exige que un miembro activo de la comunidad avale (haga vouch) explícitamente cada nueva contribución antes de que sea revisada. Los PRs creados con IA deben haber sido completamente verificados por un humano que entienda lo que proponen.

3. Actualizaciones al CONTRIBUTING.md

Proyectos como Wagtail han detectado un aumento súbito en contribuciones generadas por IA y están actualizando sus guías para incluir reglas explícitas: divulgación obligatoria del uso de IA, verificación humana del código antes del envío, y advertencias claras de que el uso de IA para eludir estas reglas puede resultar en el baneo permanente de la cuenta.

4. Tests como filtro natural

Un hallazgo interesante: proyectos con suites de tests robustas —como cURL— reciben menos AI slop en PRs simplemente porque el CI rechaza automáticamente el código que no pasa las pruebas. Esto refuerza una idea que muchos founders deberían internalizar: la calidad técnica tiene externalidades positivas más allá de lo que se ve directamente.

5. La propuesta de GitHub: permisos granulares y detección por IA

En enero de 2026, la comunidad de GitHub abrió una discusión pública para explorar soluciones más estructurales, entre ellas: posibilidad de eliminar PRs desde la UI, restricción de PRs a colaboradores, umbrales de detección de IA, y herramientas de triage automatizado. Ninguna está confirmada aún para producción, pero la dirección es clara.

La dimensión ética: IA responsable en comunidades técnicas

Más allá de los protocolos técnicos, hay una cuestión ética de fondo que vale la pena nombrar. Usar IA para enviar contribuciones en masa a proyectos open source sin comprensión real del contexto no es solo una mala práctica de ingeniería; es una forma de apropiarse del trabajo voluntario de otros sin asumir ninguna responsabilidad.

El contrato implícito del open source es claro: contribuyes porque entiendes, porque te importa el proyecto, y porque estás dispuesto a defender tu propuesta en la revisión. Cuando una herramienta automatiza eso sin el entendimiento humano detrás, se rompe el contrato. Y cuando el contrato se rompe a escala, las comunidades responden cerrándose.

Como bien resume un comentario en Hacker News que resume el sentimiento de la comunidad: «Lo que más me sorprende de todo esto es lo poco que parecen importarles a estas personas el no tener vergüenza». El FOMO de aparecer como contributor en proyectos relevantes, impulsado ahora por el bajo costo de generar código con IA, está produciendo un fenómeno que podría compararse con el spam de email en los años 2000, pero en el corazón de la infraestructura de software.

Qué pueden aprender los founders de este debate

Si líderas un equipo de ingeniería o una startup que usa o contribuye a proyectos open source, hay lecciones concretas aquí:

La IA es una herramienta, no un sustituto del criterio técnico. Usar Copilot o cualquier LLM para acelerar la implementación está bien; enviarlo sin revisión humana a un repositorio ajeno es otra cosa.
La calidad del código tiene componentes sociales. Las comunidades open source funcionan por confianza. Erosionarla, aunque sea sin mala intención, tiene consecuencias reales para todos.
Si dependes de open source, cuida de él. Contribuye con calidad, reporta issues reales y apoya a los mantenedores. La infraestructura técnica de tu startup probablemente descansa sobre trabajo voluntario.
Diseña tus flujos de IA con supervisión humana. Tanto para contribuciones externas como para el código interno, incorpora puntos de revisión donde un humano valide lo que la IA propone antes de que llegue a producción.

Conclusión

El debate sobre los PRs generados por IA de bajo esfuerzo no es solo una queja de mantenedores frustrados: es una señal temprana de cómo la adopción masiva y acrítica de IA generativa puede degradar sistemas de colaboración que tardaron décadas en construirse. Los protocolos que están emergiendo —desde el vouching hasta los permisos granulares de GitHub— son respuestas pragmáticas a un problema que no va a desaparecer solo.

Para el ecosistema startup, el mensaje es simple: usar IA con inteligencia significa también usarla con responsabilidad. Y en el mundo técnico, la responsabilidad se mide en calidad de código, comprensión real del contexto y respeto por el trabajo de la comunidad. La herramienta no es el problema; lo es el criterio con que se usa.

Descubre cómo otros founders implementan IA responsablemente y elevan la calidad de sus equipos de ingenieria.

Aprender con founders