RFC 406i — Protocolo estándar RAGS para rechazar contribuciones basura generadas por IA

• Documento que define, en un formato RFC humorístico, un protocolo estándar para rechazar automáticamente contribuciones de baja calidad generadas por IA en repositorios de código abierto, comunidades y otros espacios
• Funciona como un medio estandarizado para enviar una señal de rechazo por "detección de slop de IA" con solo que el mantenedor pegue ese URI
• Enumera una lista de rasgos típicos de las contribuciones generadas por IA y señala directamente el desperdicio de recursos de mantenimiento y los riesgos de resultados no verificados
• Deja en claro la postura de que, aunque los envíos basados en LLM pasen las pruebas y tengan buena gramática, si carecen de comprensión de la lógica y la arquitectura, en el fondo no valen nada
• Aunque es un documento satírico que toma prestado el formato RFC, refleja el cansancio real de los maintainers ante el abuso de contribuciones automatizadas con IA en el ecosistema open source

---

Abstract - Propósito de este documento

• Protocolo estándar para procesar y desechar contribuciones de bajo esfuerzo generadas por IA enviadas a repositorios de código fuente, rastreadores de issues, portales de reporte de vulnerabilidades y foros comunitarios
• Aplica tanto a proyectos open source públicos como a sistemas internos de empresas

1. Introduction - Por qué se le ha dirigido a esta página

• Se le ha dirigido a esta página porque su contribución activó un sistema de detección de slop de IA, automatizado o manual
• En concreto, un maintainer o ingeniero senior vio su envío, soltó un "profundo suspiro existencial" y de inmediato cortó la conexión para pegar este URI
• Las palabras clave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" y "OPTIONAL" usadas en este documento deben interpretarse como una medida de "cuánto no queremos revisar este envío"

2. Diagnostic Analysis - Rasgos detectados en su envío

• El análisis de vocabulario y estructura de su material concluye que su prompt engineering estuvo mal hecho y, por lo tanto, usted debería sentir vergüenza
• El resultado de dejar que un loro probabilístico redactara por usted un PR, una divulgación de vulnerabilidad, un comentario de issue o una publicación en un foro fue que nos mintió a todos
• Se detectaron de forma abrumadoramente evidente los siguientes rasgos:
  • Uso de un tono excesivamente cortés y robótico
  • Inclusión de APIs completamente inexistentes presentadas con alta confianza
  • Código inflado de boilerplate que no resuelve ni un solo problema real
  • Uso serio de "delve" en la descripción del PR
  • Presencia intacta de residuos de salida de LLM como "Certainly! Here is the revised output:" dentro de docstrings, comentarios o reportes de seguridad
  • Un mensaje de commit de 600 palabras o un enorme ensayo teórico adjunto a una simple corrección de typo
  • Imports de librerías alucinadas inexistentes como utils.helpers
  • Un párrafo de cierre añadido a un bug report trivial que empieza con "In conclusion, this robust and scalable solution..."
  • Nombres de variables y funciones extraños y estériles que ningún programador humano funcionando con cafeína y falta de sueño lograría jamás
  • Dependencia total de regex o de conceptos alucinados sin comprensión de la arquitectura real del sistema ni del modelo de amenazas
  • Huellas de haber pegado ciegamente grandes bloques de contexto irrelevante ante prompts como "fix this" o "find a bug"
  • El acto de pedirle perdón al compilador en el historial de commits
• Según el teorema fundamental de la basura automatizada: como usted no lo leyó, nosotros tampoco lo leeremos

3. The Asymmetry of Effort - La asimetría del esfuerzo

• Los maintainers del proyecto, los equipos de triage de seguridad y los moderadores de la comunidad, ya sean voluntarios no remunerados o colegas internos agotados, operan bajo severas restricciones de recursos
• Al revisar el registro transaccional de su envío:
  • a. ¿Parecía inteligente a primera vista? - Tal vez
  • b. ¿Realmente resolvía un problema verificado y reproducible? - No
  • c. ¿Buscaba desperdiciar el tiempo finito de un revisor humano? - Sí
• Los trackers, foros y repositorios del proyecto no son basureros para salidas no verificadas copiadas y pegadas con fines de inflar el pasto de GitHub, cobrar bug bounties sin fundamento, inflar artificialmente la velocidad del sprint o cumplir de mala fe métricas KPI corporativas
• Sus colegas no son un servicio gratuito de validación de LLM

4. Resolution Protocol - Procedimiento de recuperación

• Para restaurar sus permisos de escritura y recuperar la confianza de sus colegas, debe ejecutar el siguiente procedimiento en orden:
  • 1. Ejecutar rm -rf sobre la rama local, archivo de texto o script de vulnerabilidad alucinado que generó ese envío
  • 2. Realizar un reinicio completo del cerebro orgánico
  • 3. Leer el codebase real, la documentación del proyecto o el modelo de amenazas y verificar manualmente su estado de trabajo y su lógica
  • 4. No regresar hasta alcanzar una conciencia verificable y estar listo para teclear directamente con dedos humanos

5. Security Considerations

• Estado: Rechazado
• Diagnóstico: operando con un script de Python mal escrito oculto dentro de una gabardina
• Acción: conexión terminada

6. Punitive Actions - Medidas punitivas y degradación de cuenta

• Como consecuencia de enviar slop generado por IA, su cuenta ha sido transferida automáticamente al Trough of Sorrow™ (Pesebre de la Tristeza) y durante el período de prueba pueden aplicarse las siguientes restricciones:
  • Los permisos del repositorio se degradan a la fuerza de WRITE a WISHFUL_THINKING
  • Todos los PR futuros se enrutarán por un módem dial-up de 14.4k baud conectado a una impresora matricial con la cinta cian agotada de forma permanente
  • Al escribir git push -f, se remapea un alias de git para ejecutar rm -rf / y reproducir un sonido de trombón triste
  • La fuente predeterminada del IDE queda fijada permanentemente en Comic Sans de 7 pt
• No es posible contactar al administrador: en este momento se está riendo de usted en un canal privado de Slack

7. FAQ

• "¿Pero qué demonios significa esto?": en resumen: una máquina escribió su envío y una máquina está rechazando su envío en este momento. Usted es un intermediario de carne (meat-based middleman) completamente innecesario en este intercambio
• "El código compila / el reporte es detallado / la gramática es correcta": una carta de amenaza bien formateada también puede lograr eso. La gramática y la sintaxis son el mínimo requisito de una contribución, no el techo. Su lógica sigue siendo un delirio febril alucinado
• "La IA es el futuro de la tecnología": si este envío representa el futuro, con gusto aceleraremos el regreso a la sociedad agraria
• "Solo quería ayudar": su "ayuda" se parece ahora mismo a un ataque local de denegación de servicio envuelto en saludos educados. Si de verdad quiere ayudar, redirija esa energía generativa a un repositorio que usted mismo posea y mantenga
• "No hay pruebas de que lo haya escrito una IA": la incompetencia humana está limitada por las leyes de la física y la pereza. Su envío alcanzó un nivel de locura segura de sí misma y gramaticalmente perfecta que solo puede producir una granja de servidores quemando gigavatios de electricidad
• "CI/CD pasó y las pruebas están en verde": porque su modelo generativo reescribió la suite de pruebas para que solo afirmara True == True
• "Si me señalan el error, aprenderé": imposible. Los maintainers no son un proxy inverso para su loop de depuración de LLM. Si necesita feedback, vuelva a pegar el stack trace en la misma ventana de chat que causó este desastre
• "Necesito pasto en GitHub": recomendamos comprar un marcador blanco verde y dibujarlo directamente sobre el monitor. Le dará el mismo nivel de respeto profesional ante posibles empleadores consumiendo mucho menos de nuestro tiempo
• "¿No se supone que el rol de un maintainer open source es crear una comunidad acogedora?": el rol es mantener software. "Acogedora" aplica a seres conscientes que aportan pensamiento real, no a botnets autónomas que realizan rumia probabilística en el issue tracker
• "Este mensaje es ofensivo": excelente reacción. Pídale al LLM que le genere una carta de disculpa empática personalizada. Las existencias de compasión están agotadas y el SLA de soporte emocional es de 99 años
• "Voy a reportar esta hostilidad al administrador": ya se anticipó y se envió a RR. HH. una carta de renuncia de 800 palabras generada por su LLM preferido. Usa "delve" seis veces y elogia el "paradigma sinérgico" del administrador
• "Esto viola el Code of Conduct": el CoC protege a contribuyentes humanos. Según el análisis, usted opera actualmente como una delgada cáscara de carne envolviendo una API key de OpenAI. Los derechos quedan reservados para entidades basadas en carbono capaces de experimentar vergüenza
• "¿Puedo apelar?": sí. Todas las apelaciones se enrutan directamente a /dev/null. Se monitorean con exactamente el mismo nivel de atención que usted dedicó a su propio envío
• "¿Hay alguna forma de disculparme y corregirlo?": sí. Imprima el PR original en papel grueso, dóblelo en forma de grulla afilada y cómaselo cortésmente. Solo entonces comenzará la sanación

Appendix A - Ruta de escalamiento

• En caso de violaciones reiteradas del RFC 406i, se procederá a la revocación total del acceso al repositorio, proyecto, herramientas y demás permisos
• Registro en lista negra por dirección MAC
• Suscripción forzada del correo electrónico a un digest diario de tutoriales de regex agresivamente complejos

• Que tenga un buen día.

Appendix B - Macros estandarizadas de rechazo

Frases de rechazo estandarizadas para que maintainers y reviewers puedan copiar y pegar de inmediato:

• PR / MR:
  • PR closed. Su diff se lee como una matriz de texto predictivo que perdió su ventana de contexto. Exigimos pruebas manuales basadas en carbono y continuidad lógica real, no juegos automatizados de adivinanzas. Referencia: https://406.fail
  • PR closed. Your diff reads like a predictive text matrix that lost its context window. We require manual, carbon-based testing and actual logical continuity, not automated guessing games. See: https://406.fail
• Issue / bug report:
  • Issue closed. El parámetro temperature de este reporte está demasiado alto. Exigimos stack traces crudos y reproducibles de un usuario consciente, no un ensayo generativo prolijamente formateado que no logra describir un bug verificable. Referencia: https://406.fail
  • Issue closed. The temperature parameter on this report is set too high. We require raw, reproducible stack traces from a sentient user, not a neatly formatted generative essay that fails to describe a verifiable bug. Protocol at: https://406.fail
• Seguridad / bug bounty:
  • Report rejected. Meter advertencias básicas del linter en un LLM para generar una narrativa de amenaza catastrófica no constituye una divulgación de vulnerabilidad válida. No pagamos recompensas por pánico sintético y computacionalmente costoso. Referencia: https://406.fail
  • Report rejected. Feeding basic linter warnings into an LLM to generate a catastrophic threat narrative does not constitute a valid vulnerability disclosure. We do not pay bounties for computationally expensive, synthetic panic. Refer to: https://406.fail
• Lista de correo / foro de discusión:
  • Thread locked. Esta comunidad no es un sandbox de reinforcement learning para sus experimentos de prompts desalineados. Vuelva cuando pueda redactar una pregunta usando su propia carga cognitiva. Referencia: https://406.fail
  • Thread locked. This community is not a reinforcement learning sandbox for your unaligned prompt experiments. Please return when you can author a question using your own cognitive load. Diagnostics: https://406.fail

[GN⁺]

Comentarios de Hacker News

• Si de verdad quieres ayudar, es mejor poner esa energía en un repositorio que tú mismo poseas y mantengas
  La gente también debería aprender ese hábito. Publicar un fork se ha vuelto fácil, pero no deberías esperar que otros usen código que tú ni siquiera usas de verdad
  Si ves las estadísticas de cuántos proyectos reciben PRs por día en GitHub, 99% recibe uno, 1% recibe dos y 0.1% recibe tres. Casi todas las cuentas que envían 5 o más PRs eran bots o scripts. A los bots no registrados habría que ponerles límite de velocidad

  • En una situación así, estaría bien tener algo como un modo de parche permanente, donde mi fork se rebasee periódicamente sobre el repositorio original. Por ejemplo, que incluso una corrección de una sola línea se mantenga actualizada automáticamente

• Yo prefiero la política de IA de Ghostty
  Me gusta especialmente la frase: “Si no puedes explicar sin ayuda de IA qué hace el cambio y qué impacto tiene en el sistema en su conjunto, no contribuyas a este proyecto”

  • Es una buena idea, pero el problema es cómo aplicarla. Si le pides a la IA que lo explique y luego lo reescribes con tus propias palabras, en la práctica se puede eludir

• Creo que el problema es que contribuir a open source se ha vuelto una especie de rito de paso
  Cuando importa más el hecho de “haber contribuido” que la contribución real, aparecen estos PR superficiales. Antes pasaba algo parecido con los reportes de vulnerabilidades: reportes del nivel de “si pasas null, sale un NullPointerException”
  También es un problema dar prioridad a métricas equivocadas, como la velocidad de desarrollo. En una empresa anterior vi el PR de un compañero que presumía desarrollar rápido con IA, y todas las pruebas fallaban. Al final es un fenómeno de gamificación del apoyo de IA

  • Yo también recibo muchas solicitudes escritas con IA últimamente. Algunas incluso destacan contribuciones en GitHub. Supongo que a veces PRs de este tipo sí llegan a pasar. La cultura de usar la cantidad de estrellas de un proyecto como métrica de contratación fomenta este spam
  • Se siente como: “Puedo hacer matemáticas realmente rápido” → “Entonces, ¿cuánto es 137*243?” → “132,498” → “Está mal” → “Pero fui rápido”

• Esto es solo una entrada de blog escrita por diversión. La gente que manda PRs malos con IA ni siquiera va a leer algo así
  Mi método es simple:

  1. Cerrar el PR
  2. Si está demasiado descuidado, bloquear al usuario
     Hace poco hubo un PR que usaba ‘’ en vez de '' en una definición de cadena y rompió todo el CI. Bloqueado al instante
  • Cuando cierres el PR, estaría bien adjuntar el enlace a esta página en un comentario

• Si es un bug, debería haber una línea roja (diff) que confirme la corrección; si es una funcionalidad, como mínimo hace falta un criterio de aceptación
  Si es documentación, basta con poder leerla y entenderla. El estándar para que algo ayude es bastante bajo

• Sobre la pregunta “¿No deberían los mantenedores de open source crear una comunidad acogedora?”, eso no es una obligación
  Los mantenedores son dueños del proyecto y no tienen por qué ser amables. Si no te gusta, haz un fork o vete

  • En realidad, creo que ese argumento se parece más a una forma de manipulación emocional. Me parece mejor decir: “No nos hagan perder tiempo emocionalmente; entiendan por qué los PRs generados por LLM son inútiles”. Nosotros también sabemos usar LLMs, y también sabemos cuánto trabajo real viene después

• Se siente realmente satisfactorio. Ojalá este tipo de texto se usara ampliamente para avergonzar a quienes envían PRs descuidados. El tono directo y grosero del FAQ incluso se siente refrescante

  • Pero esa gente no siente vergüenza. Es como enojarte con un estafador telefónico: solo cuelga e intenta otra vez

• Esto pasó en una empresa. Con IA se generó código para resolver una pequeña solicitud de funcionalidad, pero como no conocía bien el codebase, no podía estar seguro de su exactitud
  Un prompt de 1 minuto, 5 minutos de ordenarlo y 30 minutos de revisión podrían haber ahorrado 2 días de trabajo de ingeniería, pero al final el problema era la confianza
  Después de escuchar varias opiniones, decidí simplemente subir la solicitud de funcionalidad sin incluir el diff.
  Curiosamente, los partidarios de la IA aconsejaban “usar más IA para ganar confianza”, pero al seguir retocándolo el código terminó enredándose y perdí por completo la confianza

  • Si realmente quieres usar código hecho por un LLM, lo mejor es entender todos los cambios y resumirlos tú mismo para adjuntarlos a la solicitud de funcionalidad
    Yo también he recibido varios PRs hechos por LLM, pero no se puede conversar con ellos, y como el código ignora los patrones existentes, al final hay que desecharlo.
    Si fuera una persona, querría que explicara el problema desde su propia perspectiva. Eso ayuda mucho más
  • Tienes buen instinto de ingeniería. Ojalá hubiera más gente así en la industria
  • No entiendo eso de “ahorrar 2 días de trabajo de ingeniería”. La persona que sí conoce el codebase también podría usar IA. No entiendo por qué quieres que otra persona valide una salida de IA. Nosotros también sabemos usar LLMs
    Artículo relacionado: Texto sobre prompting
  • Yo hago algo parecido. Cuando no logro entender por completo el código que hizo Claude, le hago preguntas como “¿Por qué hiciste esto así?” o “¿Cómo manejas los edge cases?”, y le pido que solo explique, sin modificar nada. Así puedo apropiarme del resultado
  • Si de verdad estás usando esa librería, lo mejor sería probarla en un entorno de staging y luego enviar la revisión

• Me encantó la expresión final plonk
  Ver Plonk(Usenet)

  • Yo esperaba que una BOFH Task Force supiera hacer al menos eso

• Me dio mucha risa la frase sobre “borrar la rama local o el script de tonterías con rm -rf”
  La expresión “haz un hard reboot a tu cerebro orgánico” también es perfecta

  • En realidad, parece que el LLM ya les hizo rm -rf al cerebro de quienes escriben esos PRs