Cómo usaron el flag `--author` de Git para frenar el spam de bots de IA en un repositorio de GitHub

• El repositorio Archestra empezó a recibir cada vez más contribuciones generadas con IA, junto con comentarios y PR sin sentido, hasta ocultar las discusiones reales y aumentar la carga de mantenimiento
• Un issue con recompensa de $900 era un espacio para que colaboradores reales discutieran, pero los comentarios de bots de IA lo inflaron hasta 253 comentarios y hasta aparecieron actitudes agresivas
• En el issue de soporte para x.ai provider entraron 27 PR cerrados y no fusionados, y la mayoría ni siquiera fue probada por quien la envió
• La restricción de prior contributor de GitHub no distingue entre nuevos desarrolladores reales y bots de IA, así que usaron Git --author para agregar usuarios aprobados como authors de commits en main
• El onboarding, con reglas de uso ético de IA y CAPTCHA, crea commits de lista blanca mediante GitHub Action y prioriza la calidad por encima de métricas de actividad infladas

---

Cómo el spam de bots de IA fue invadiendo un repositorio open source

• En el repositorio Archestra, a diferencia del crecimiento en las métricas de contribución impulsadas por IA que muestra GitHub, en la práctica aumentaron la caída de calidad de las contribuciones y la carga de mantenimiento
• El issue con recompensa de $900 era un espacio donde colaboradores reales proponían planes, hacían preguntas e intentaban resolver el trabajo, pero la llegada masiva de bots de IA lo hizo crecer hasta 253 comentarios
• Las cuentas de IA dejaban planes de implementación sin sentido e incluso mostraban una actitud agresiva hacia los mantenedores, contaminando la discusión
• Los miembros del equipo que seguían el repositorio recibían notificaciones por cada comentario de IA, mientras conversaciones de colaboradores reales como @ethanwater, @developerfred y @Geetk172 quedaban sepultadas
• En el issue de soporte para x.ai provider entraron 27 pull requests cerrados y no fusionados, y en la mayoría de los casos quienes contribuyeron ni siquiera habían hecho pruebas
• Un integrante del equipo tenía que dedicar medio día cada semana a limpiar PR sin probar e issues alucinados; si dejaban de hacerlo, el repositorio se convertía rápidamente en un espacio hostil para colaboradores reales

El método de lista blanca para sortear las limitaciones de GitHub

• Limitaciones de la respuesta inicial

  • Archestra primero creó un bot pequeño llamado London-Cat para calcular la reputación de los colaboradores
  • London-Cat calculaba la reputación de cada colaborador basándose en PR fusionados y algunas señales adicionales, y ayudaba a identificar contribuidores como se ve en este ejemplo
  • Este enfoque fracasó a la hora de bloquear el spam en sí
  • El siguiente paso fue un AI sheriff que, como se ve en este ejemplo, llegó a cerrar también algunos PR reales

• Bloquear actividad sin onboarding

  • Como los comentarios y propuestas inútiles generados con IA seguían llegando, colaboradores reales empezaron a irse, y eso los llevó a replantear tanto el uso de recompensas para atraer contribuciones como la práctica de dar tareas de prueba a candidatos de contratación
  • Archestra endureció su respuesta para crear un repositorio cómodo y seguro para colaboradores reales, usuarios responsables de IA, principiantes y también ingenieros experimentados
  • Los usuarios que no pasen por el onboarding ahora tienen bloqueada la posibilidad de crear issues, abrir PR y escribir comentarios
  • Para una startup con inversión de VC, las métricas de actividad de GitHub son sensibles, pero Archestra considera más importante la calidad que métricas infladas por AI slop

• Límites de la configuración de GitHub

  • GitHub no ofrece una forma simple de manejar directamente una lista blanca de personas que puedan comentar o crear PR en repositorios open source
  • La opción “Limit to prior contributors” bloquea comentarios en issues y PR de usuarios que nunca antes han hecho commits a main
  • Esa configuración no distingue entre bots de IA y desarrolladores reales que llegan por primera vez para trabajar en una recompensa; a ambos los trata como usuarios sin contribuciones previas

• Lista blanca usando el flag --author

  • GitHub considera como prior contributor a la cuenta de GitHub vinculada como author de un commit en la rama main
  • Un commit de Git tiene dos campos de identidad: author y committer, y esos valores pueden ser distintos
  • Con el flag --author de Git se puede crear un commit atribuido a otra persona; si el correo coincide con la cuenta de GitHub, GitHub vincula ese commit al perfil y le otorga estado de contribuidor
  • Todas las cuentas de GitHub tienen un correo noreply con el formato <id>+<username>@users.noreply.github.com
  • Después consultan el ID del usuario vía API y asignan ese formato de correo como author del commit

  gh api users/their-username --jq '.id'  
  git commit \  
  --author="their-username <[e-mail]>" \  
  -m "chore: add their-username to external contributors"  
  

  • Al hacer push de ese commit a main, el usuario externo aparece como author, la cuenta de Archestra como committer, y GitHub pasa a tratar de inmediato a ese usuario como prior contributor, dándole permiso para comentar

• Flujo real de onboarding

  • https://archestra.ai/contributor-onboard - En el sitio web hacen onboarding con reglas de uso ético de IA y CAPTCHA
  • GitHub Action - Al enviar el formulario, consultan el ID de GitHub del usuario, agregan su handle al archivo EXTERNAL_CONTRIBUTORS.md y hacen push a main de un commit cuyo author es esa cuenta de usuario
  • Usuario - Queda en la lista blanca y obtiene acceso al repositorio
  • Mientras GitHub reporta crecimiento masivo en métricas, incluso contando actividad generada por IA, los equipos de proyectos open source tienen que limpiar por su cuenta el AI slop de sus repositorios e incluso idear atajos para mantener un nivel razonable de participación real
  • El AI slop no solo empuja entre el ruido a quienes sí quieren hacer buenas contribuciones y les quita motivación, sino que además trae riesgos de seguridad, como en el repo de LiteLLM, donde atacantes intentaron inducir conversaciones con bots de IA

[GN⁺]

Comentarios de Hacker News

• Los contribuidores del repositorio obtienen privilegios más altos, como poder saltarse el requisito de aprobación para ejecutar PRs desde forks, así que este enfoque tiene implicaciones de seguridad que se pasaron por alto
  La documentación de GitHub también advierte que, con la configuración de “requerir aprobación solo para quienes contribuyen por primera vez”, cualquier usuario al que se le haya fusionado хотя sea una vez un commit o un PR en el repositorio deja de necesitar aprobación, y que un usuario malicioso podría cumplir esa condición logrando que le acepten un cambio inocuo, como corregir un simple typo

  • Es cierto. A cualquiera que no sea miembro de la organización no se le puede dar por confiable, así que requerir aprobación para todos los contribuidores externos debería ser el valor predeterminado
  • Eso no es una implicación de seguridad
    Si el repositorio se vuelve inseguro solo porque se fusionó un PR completamente inofensivo de alguien, entonces ese repositorio ya estaba en una situación insegura

• El problema es que GitHub haya permitido que esto fuera posible. Si hubiera puesto requisitos muy básicos para comentar y crear PRs, no habríamos llegado hasta aquí
  Y así como se pueden borrar issues, también deberían permitir borrar PRs

  • En este momento están trabajando en una función para que los admins puedan archivar PRs
    La meta es darles a los mantenedores un mejor control sobre cómo gestionan las contribuciones al repositorio. Los PRs archivados solo serían visibles para los admins, y los mantenedores seguirían teniendo acceso al historial del contribuidor para fines de auditoría o requisitos organizacionales y de cumplimiento. Tengo curiosidad por saber si una función así sería útil
  • Ese criterio es correcto. Así como no le corresponde a cada persona “resolver por su cuenta” cómo no recibir spam por email, esto tampoco es algo que deban resolver por su cuenta las comunidades open source o los proyectos individuales
  • No veo cuál sería la ventaja de borrar un PR en vez de cerrarlo. Si lo cierras, puedes dar una señal de qué tipo de PRs no se aceptan; si lo borras, esa ventaja se pierde

• El spam de PRs es un gran problema para los repositorios que ofrecen recompensas. Tal vez GitHub debería bloquear temporalmente la creación de PRs a cuentas a las que les rechazan más del 95% de sus PRs

  • Estaría bien que GitHub tuviera un sistema para emitir, por ejemplo, tokens de 1 PR
    Si alguien participa en una discusión con sentido y muestra buenas ideas para resolver un issue o implementar una función, al principio se le podría dar un token de PR; si la calidad de sus PRs es buena, se le dan algunos más, y eventualmente se le promueve a contribuidor con libertad para crear PRs. También estaría bien tener algo parecido para issues, aunque no tengo claro cómo se vería si los issues son el punto de partida de las contribuciones vía PR. De todos modos, GitHub/MS quiere vender suscripciones de Copilot y tokens, y los PRs generados por LLM también forman parte de ese modelo de negocio, así que no parece muy probable que ocurra
  • GitHub no tiene incentivos para bloquear la IA. Es como pedirle a una empresa de anuncios que meta un bloqueador de anuncios en su propio navegador
  • El problema es que los bots pueden crear cuentas nuevas de GitHub todas las veces que quieran y seguir enviando spam. Aun así, como defensa simple de arranque podría servir
  • GitHub y Microsoft están contribuyendo activamente a este problema, ¿por qué iban a admitir su propia culpa?

• Me pregunto si un sistema de puntuación basado en Elo serviría para reducir este tipo de problemas
  Algo que evalúe a quienes han logrado fusionar PRs con éxito en cierto proyecto, a quienes han reportado issues válidos, a quienes tienen respuestas cuya calidad se mide por la reacción de otros usuarios, etc., y que además multiplique eso por la importancia del proyecto donde ocurrió la actividad. No sería una división entre humanos e IA, sino un criterio para separar contribuciones realmente útiles y efectivas de aportes de bajo esfuerzo o tipo spam. Los issues y PRs podrían ordenarse o filtrarse por puntuación Elo. Aquí Elo es solo una metáfora de una puntuación basada en contexto, no una propuesta de trasladar el sistema Elo real de forma 1:1
  Las puntuaciones negativas podrían salir de reportes de otros usuarios sobre contenido spam o issues no reconocidos, y parece que haría falta una zona intermedia con puntuaciones neutrales o levemente positivas para casos donde hubo buena fe evidente pero no se llegó a un PR fusionado, o donde el issue no correspondía al repositorio correcto, o donde un buen PR requería trabajo previo

  • Elo es sorprendentemente fácil de manipular
    Por ejemplo, hubo un jugador de ajedrez bastante bueno en prisión, y creó un grupo de jugadores que obtenían un Elo alto al ganarle; luego los usaba para subir todavía más su propia puntuación. Solo hay que repetir el proceso
    Cualquier sistema que se pueda manipular, la IA encontrará cómo manipularlo. Incluso con el método del artículo original, si una IA logra obtener estatus de contribuidor, puede elevar a otras IAs a contribuidoras y vuelve a empezar el mismo problema. Ni siquiera hace falta un objetivo. Los trolls trolean, y los trolls con bots de IA pueden invertir energía infinita. Cuanto más trates de detenerlos, más divertido les resulta. Ojalá supiera la respuesta a este problema, pero no la sé
  • Como nota para quienes tengan curiosidad por Elo: no es una sigla, es el apellido de una persona. Más información aquí: https://en.wikipedia.org/wiki/Elo_rating_system
  • Es Elo, no ELO. Elo no es una sigla
    https://en.wikipedia.org/wiki/Elo_rating_system
  • Estoy construyendo algo parecido y actualmente estoy recopilando datos
    Frontier users: 527,865
    Light indexed: 527,865
    Ready to queue: 9,083
    Fast scores ready: 0
    Activity events 24h: 30,266
    Fast scores completed 24h: 19,123
    Deep jobs completed 24h: 3,043
    Fast-score ETA: n/a
    Deep-hydrate ETA: 69h
    Stale running jobs: 0
    GitHub backpressure jobs: 19,113
    High automation signals: 4,608
    Medium automation signals: 1,327
    Completed jobs: 74,714
    El mayor obstáculo es el límite de velocidad de GitHub. A este ritmo, llegar al 98% de cobertura tomaría dos meses más, pero después de eso el mantenimiento parece bastante simple
  • Suena algo parecido a Vouch de Mitchell Hashimoto: https://github.com/mitchellh/vouch

• Esto es el resultado de andar diciéndole a todo el mundo qué tan bien escribe código la IA
  Lo empezaron quienes venden IA y, de forma extraña, se subieron en masa también desarrolladores independientes, incluso algunos bastante respetados dentro de la industria. Que Facebook ahora despida gente diciendo que es porque la IA es tan buena solo echa más leña al fuego. Ahora hay personas convencidas de que su amigo IA produce código increíble, y lo están enviando a proyectos que ya quedaron completamente fuera de control

  • Tal vez lo que pasó es que los cowboy coders consiguieron vaqueras virtuales que programan y se las vendieron a todo el mundo
    Más allá de si son respetados o no, un desarrollador individual no siempre tiene las capacidades esenciales para no terminar actuando como cowboy. Puede ser por falta de experiencia o por falta de aptitud innata. Aun así, no compro del todo esa narrativa. Desde el “inicio” hubo un impulso fuerte de arriba hacia abajo

• Es irónico que sea un dominio .ai

  • No me parece particularmente irónico. No se está diciendo que la IA sea mala, sino que puede usarse mal
  • Ojalá el sitio arreglara un poco el código de scroll. Me irrita tanto que no puedo leer el artículo
  • Es como si una empresa basada en basura de IA dijera: “¡No sabía que la IA iba a llenar mi proyecto de basura!”
  • No es solo el dominio. Esto es un stack agentic. O sea, con el producto de esta empresa uno mismo puede crear exactamente los PRs de los que aquí se están lamentando

• ¿La solución a todo son más catgirls al final? [1] La prueba de trabajo originalmente buscaba responder al spam por email, y el spam de PRs es solo el caso más reciente de esa larga tradición
  1- https://anubis.techaro.lol

  • La prueba de trabajo no funciona aquí, igual que no funcionó con el email
    El esfuerzo requerido para producir una prueba de trabajo válida siempre termina perjudicando más a los usuarios legítimos, sin importar la implementación. Quien tiene incentivos para spamear siempre puede hacerlo más rápido y con más eficiencia
    ¿Tu laptop es demasiado lenta para enviar un PR? Entonces le alquilas hash power a alguien, y lo que terminas creando es un sistema donde le pagas al dueño de una botnet para subir una corrección de typo a un repositorio de GitHub. Hay una razón por la que HashCash no se usa en la práctica. Suena bonito, pero solo funciona si asumes un vacío donde nadie hace trampa, y los incentivos son absurdos
  • Anubis en realidad no es un gato. En la mitología egipcia original, Anubis es un dios de la muerte y tenía cabeza de cánido. A primera vista, una catgirl animada y una dog girl pueden parecerse
  • Yo entiendo que Anubis no es para crear agentes que hagan PRs, sino para bloquear crawlers. Aquí la prueba de trabajo no sirve. El agente simplemente hará el cómputo

• El tono de los documentos de onboarding tiene ese aire típico de IA. En la cita también se ven rayas largas y frases del tipo “no es A sino B”
  Entiendo que puede ser una forma de combatir fuego con fuego o, como ya se dijo, que simplemente no tenían tiempo. Aun así, en conjunto se siente como una respuesta a medias e insuficiente

  • Todo el texto claramente parece generado por LLM
    Se nota que una persona puso ahí ideas propias, pero pedirle a un LLM “convierte esto en una entrada de blog” me parecía contenido de bajo esfuerzo que no encaja con HN. Al menos generó una discusión sobre si el enfoque básico de “limitarlo a contribuidores” puede ser una mala idea desde el punto de vista de seguridad
  • Usar IA en tu propio proyecto y quedar abrumado por contribuciones de IA enviadas por otras personas o bots son problemas distintos

• Al leer la parte de “si el email coincide con la cuenta de GitHub, GitHub conecta el commit con el perfil y otorga estatus de contribuidor”, me preocupó si esto no se rompería cuando cambie la dirección de email del contribuidor
  Lo digo porque durante años contribuí a varios proyectos con una dirección de email que ya no existe
  Pero en la práctica parece que no usa la dirección de email registrada en el commit git original del autor, sino una dirección generada por GitHub que incluye como parte única el ID de usuario y el nombre de usuario de GitHub. En ese caso, podría seguir funcionando aunque el autor cambie su dirección de email. Aun así, podría romperse si el contribuidor pierde acceso a la cuenta y tiene que crear una nueva, pero eso probablemente sea menos común

• La respuesta a “¿deberíamos dejar de darles a los postulantes tareas de prueba divertidas?” es sí

  • Parece que esta empresa sí paga por completar esa tarea, así que quizá no sea tan malo
  • Desarrolladores: dejen de hacer entrevistas de whiteboard porque no miden cosas relacionadas con el trabajo real
    También desarrolladores: no nos hagan resolver problemas reales
  • Para empezar, ni siquiera sé para quién se supone que eso es divertido