Hubo un tiempo en el que contribuir al Open Source tenía una barrera de entrada natural: el esfuerzo “Proof of Work”. Para enviar una mejora, tenías que entender la base del código, detectar el error y escribir la solución manualmente. Esa fricción garantizaba un estándar mínimo de calidad.

Hoy, esa barrera ha colapsado.

Desde la llegada de LLMs y agentes de codificación, el ecosistema está sufriendo lo que los mantenedores llaman un “DDoS of attention” (DDoS de atención). Herramientas capaces de generar miles de líneas de código en segundos están inundando a los revisores humanos. ¿El resultado? Una política de defensa drástica contra el fenómeno conocido como “AI Slop”.

El caso ‘tldraw’: Cerrando las puertas

La señal de alarma sonó fuerte recientemente en el proyecto tldraw. Su equipo tomó una decisión controversial: cerrar automáticamente cualquier Pull Request (PR) proveniente de contribuidores externos nuevos, hasta que GitHub ofrezca mejores herramientas de moderación.

El problema no era la mala intención, sino el volumen y la baja calidad sutil. Agentes de IA escaneaban el repositorio en busca de issues, y enviaban soluciones que “parecían” correctas pero que introducían bugs lógicos o ignoraban el contexto del proyecto.

Para los mantenedores, el tiempo invertido en revisar este código (code review) superaba el valor que aportaba. Se convirtió en una tarea de limpiar basura infinita.

¿Qué es el “AI Slop”?

No estamos hablando de simples errores de sintaxis. El “AI Slop” es código sintético que reside en el uncanny valley de la programación:

1. Look & Feel Profesional: Tiene la estructura correcta y comentarios.
2. Hallucinations: Invoca funciones que no existen o inventa lógica que rompe la arquitectura.
3. Low Context: Ignora las decisiones de diseño previas del proyecto.

Daniel Stenberg, el creador de curl, ha sido muy vocal al respecto, describiendo la situación como un ataque constante de “DDoSed by AI slop”. Stenberg reporta recibir reportes de seguridad falsos generados por IA que alegan vulnerabilidades en código que ni siquiera existe en curl.

“The better the crap, the longer time and the more energy we have to spend…” (Cuanto mejor es la basura, más tiempo y energía tenemos que gastar…)

Esto se debe a que la basura obvia se descarta en segundos, pero el AI Slop requiere que un experto humano dedique horas para demostrar que es incorrecto.

El incidente de OCaml y las 13k líneas

Un ejemplo extremo ocurrió en el ecosistema de OCaml, donde un usuario envió un PR de 13,000 líneas generado enteramente por Claude (Anthropic). El usuario admitió que su rol fue simplemente “pastorear a la IA”. Los mantenedores rechazaron el PR inmediatamente. Revisar tal cantidad de código generado por máquina es humanamente agotador (“more exhausting than reviewing human code”) y legalmente arriesgado por temas de copyright.

La respuesta: Nuevas “políticas” de gobernanza

El sector está reaccionando. La era del “envía lo que quieras” está terminando.

La política de LLVM: “No Slop”

El proyecto de compiladores LLVM ha publicado una RFC (Request for Comments) sobre su política de herramientas de IA que muchos consideran el nuevo estándar:

• Start Small: Se recomienda que las contribuciones asistidas por IA sean pequeñas e incrementales.
• Human Responsibility: Si la IA alucina, la culpa es 100% del humano. “The bot did it” no es una excusa válida.
• Net Negative: Si al mantenedor le cuesta más revisar tu código que escribirlo él mismo, tu contribución es negativa y será rechazada.

Vue Ecosystem y la fatiga

Mantenedores en el ecosistema de Vue también han reportado fatiga extrema por PRs de baja calidad, llevando a discusiones sobre restringir contribuciones solo a usuarios verificados o con historial previo.

El futuro: ¿Del “Pull Request” al “Prompt Request”?

La crisis actual está forzando a repensar la topología de la colaboración en GitHub.

Algunas voces en la industria sugieren que el código generado ya no comunica la “intención” del desarrollador. Cuando un humano escribe código, cada línea tiene un propósito deliberado. Cuando lo hace una IA, es una aproximación probabilística.

Por ello, surge la idea del “Prompt Request”: En lugar de enviar el código final (que puede ser confuso), el contribuidor enviaría el prompt que utilizó.

• Ventaja: El mantenedor puede ver la intención original (“Create a function that handles UTF-8 csv parsing…”).
• Ejecución: El mantenedor ejecuta ese prompt en su propio entorno controlado y validado.

GitHub y la moderación

GitHub está intentando ponerse al día. Aunque Copilot es parte del origen del flujo, la plataforma está desarrollando características para detectar bot-generated content, permitiendo a los dueños de repositorios filtrar o etiquetar automáticamente estos PRs antes de que consuman tiempo humano.

El Open Source no está muriendo, pero está mutando. Estamos entrando en una era de “High Trust, Low Noise” (Alta confianza, bajo ruido).

Las herramientas generativas son increíbles para la productividad individual, pero cuando se usan para inundar proyectos comunitarios sin supervisión experta, se convierten en un vector de ataque. Para los desarrolladores que quieran contribuir en el futuro, la lección es clara: La IA puede escribir el código, pero tú debes ser el arquitecto y el responsable final.

¿Crees que el concepto de “Prompt Request” es viable? Déjanos tu opinión.