Slopper: una GitHub Action para filtrar contribuciones generadas por IA

El término AI slop lleva meses circulando entre mantenedores de proyectos open source: pull requests con código genérico, mensajes de commit vacíos de contexto, documentación que suena como resumen de ChatGPT y cambios que no encajan con el estilo del repositorio. Quien haya gestionado un proyecto medianamente popular en GitHub en el último año sabe de lo que hablamos. Ahora hay una herramienta concreta para hacerle frente.

Slopper es una GitHub Action publicada por el desarrollador `malvads` y discutida esta semana en Hacker News. Su objetivo es sencillo: analizar automáticamente los pull requests entrantes en busca de señales que indiquen que el código fue generado por un LLM de forma poco cuidadosa, y bloquearlos o marcarlos antes de que el mantenedor tenga que revisarlos manualmente.

Qué hace exactamente Slopper

Slopper se integra en el flujo de CI/CD de cualquier repositorio GitHub como una acción más del workflow. Cuando llega un pull request, la acción inspecciona el diff, el mensaje del PR y, opcionalmente, los mensajes de commit en busca de patrones asociados al slop: frases genéricas del tipo «this function improves performance», estructuras de código repetitivas sin adaptación al contexto del proyecto, o comentarios que parecen generados para cubrir el expediente más que para explicar.

El resultado puede configurarse para que el PR quede bloqueado directamente, se le añada una etiqueta de revisión prioritaria, o simplemente se deje un comentario automático indicando las señales detectadas. Esta última opción es la más respetuosa con los contribuyentes legítimos que usan asistentes de IA como apoyo pero revisan y adaptan el código antes de enviarlo.

El repositorio incluye ejemplos de configuración y permite ajustar la sensibilidad de la detección, lo que es relevante porque el problema central de cualquier detector de este tipo es la tasa de falsos positivos.

Por qué importa este problema ahora

La proliferación de asistentes de código basados en LLMs —Claude Code incluido— ha bajado drásticamente la barrera para contribuir a proyectos open source. Eso tiene un lado positivo evidente, pero también ha disparado el volumen de contribuciones de baja calidad enviadas sin apenas revisión humana. Algunos mantenedores de proyectos populares han reportado públicamente que el porcentaje de PRs que simplemente no encajan, que ignoran las guías de contribución o que duplican funcionalidad ya existente ha crecido de forma notable en el último año.

El problema no es que alguien use un LLM para escribir código, sino que lo envíe sin entenderlo ni adaptarlo. La distinción es importante y Slopper intenta operar en ese espacio: no penaliza el uso de IA, sino la falta de cuidado en la contribución.

Para proyectos con pocos mantenedores y muchas contribuciones entrantes, tener un filtro automático en la puerta puede ahorrar horas de triaje semanal. Para proyectos grandes con equipos de revisión, puede servir como capa de pre-clasificación antes de asignar revisores humanos.

Limitaciones que conviene tener presentes

Cualquier sistema de detección basado en heurísticas de texto va a tener sus límites. Un desarrollador que use Claude Sonnet 4.6 para generar un parche, lo revise en profundidad y lo adapte al estilo del proyecto va a producir código que difícilmente active las alertas de Slopper. Inversamente, alguien que escriba con un estilo muy formal o que no sea nativo en inglés podría ver su PR marcado injustamente.

El repositorio es todavía joven y, en el momento de su aparición en Hacker News, tenía escasa tracción en comentarios. No hay aún datos públicos sobre tasas de precisión en entornos reales. Eso no lo invalida, pero sí invita a desplegarlo primero en modo observación antes de usarlo para bloquear PRs automáticamente.

También vale la pena preguntarse si el problema de fondo —contribuyentes que no leen las guías del proyecto— se resuelve mejor con herramientas técnicas o con fricción social explícita: plantillas de PR más exigentes, checklists obligatorias o simplemente un `CONTRIBUTING.md` bien escrito.

---

Desde EP, nos parece una respuesta razonable a un problema real que muchos mantenedores aún no han nombrado en voz alta. Que exista la herramienta no significa que sea la solución definitiva, pero al menos pone el debate sobre la mesa con algo concreto a lo que apuntar.