Tangled lanzó en 2026 un sistema nativo de vouching que permite a los mantenedores de proyectos open source marcar colaboradores como confiables o problemáticos, creando una red de confianza explícita para combatir spam pull requests IA. Los usuarios avalados reciben un escudo verde en su perfil; los denunciados, uno rojo. Sin bloqueos automáticos, pero con señales claras de quién es quién.
En 30 segundos
- Tangled integró vouching nativo: mantenedores pueden avalar o denunciar colaboradores con un campo de razón textual.
- Los LLMs bajaron la barrera de contribución a cero, generando PRs que “parecen” correctos pero tienen errores sutiles que consumen tiempo de revisión.
- El sistema no bloquea a nadie todavía: los denunciados solo reciben una etiqueta roja en la UI, sin restricciones de acceso.
- Mitchell Hashimoto lanzó Vouch, una herramienta separada para proyectos fuera de Tangled que usa archivos .td y Nushell.
- Datadog desarrolló BewAIre, que clasifica PRs como benign/malicious con 99.3% de precisión según sus propios tests internos.
El Problema: Spam de IA en Pull Requests de Open Source
Ponele que mantenés un proyecto open source con 200 estrellas en GitHub. Un día aparece un PR de 400 líneas. El código se ve razonable, los comentarios están prolijos, el commit message es impecable. Empezás a revisar y, a los diez minutos, te das cuenta que la función central tiene una condición de borde incorrecta que se va a romper en producción. Fue generado con un LLM y nadie lo testeó de verdad antes de mandarlo.
Eso, multiplicado por docenas de PRs por semana, es lo que están viviendo los mantenedores de proyectos populares en 2026.
Según análisis publicados por mantenedores activos, CodeRabbit encontró 1.7 veces más issues en PRs con co-autoría de IA versus los puramente humanos. Y hay casos extremos: Jeff Geerling documentó en su blog cómo recibió un PR de 128,000 líneas generado con Claude para un proyecto que no lo pedía. Alguien apretó “generar” y mandó sin leer.
La herramienta de generación de código bajó la barrera de entrada a cero (y con eso también bajó la barrera de entrada del spam). El costo de revisar un PR malformado lo paga el mantenedor, no quien lo mandó.
¿Qué es un Sistema de Vouching?
Un sistema de vouching es una red de confianza explícita. En vez de asumir que cualquier usuario de GitHub es un colaborador de buena fe hasta que demuestre lo contrario, el vouching te pide que lo declares.
Tangled es una plataforma de alojamiento de código construida sobre ATProto (el protocolo de Bluesky) que integró este sistema de forma nativa. Según el anuncio oficial de Tangled, los usuarios avalados aparecen con un escudo verde junto a su foto de perfil en toda interacción: comentarios, issues, PRs. Los denunciados, con uno rojo.
El cambio de paradigma es concreto: pasás de “confianza implícita hasta que algo salga mal” a “confianza explícita declarada por alguien de tu red”. Complementá con seguridad corporativa y control de acceso.
Cómo Funciona el Vouching en Tangled
El sistema tiene algunas decisiones de diseño interesantes que vale la pena entender antes de pensar que es otro sistema de reputación genérico.
Primero, la atenuación: no ves las decisiones de vouching de toda la red, solo las de tu círculo directo. Si yo voucheo a alguien y vos no me seguís, no ves mi vouch. Eso previene cascadas de reputación mal calibradas donde un usuario popular con criterios dudosos infla la reputación de media red.
Segundo, sin bloqueo inmediato. Los usuarios denunciados no son bloqueados del proyecto; solo reciben la etiqueta roja en la UI. Es más una señal para el mantenedor que una sanción automática. El equipo de Tangled lo dice directo en su anuncio: “no consequences to being denounced” en esta versión inicial.
Tercero, los datos de vouching/denounce se almacenan en el PDS (Personal Data Server) de cada usuario, usando ATProto. Un appview centralizado los agrega para mostrar los badges. Arquitectónicamente, eso significa que el historial de confianza te pertenece, no a la plataforma.
El campo de razón textual es importante también. No es un simple like/dislike: cuando vouchés o denunciás a alguien, podés (y deberías) explicar por qué. “Revisé tres PRs suyos, todos bien documentados y sin regresiones” o “mandó el mismo PR generado con IA a cinco proyectos diferentes sin adaptar nada” son tipos de razones que hacen el sistema útil.
Comparando Soluciones para combatir spam pull requests IA
No es la única herramienta que salió a atacar el problema. Conviene ver el panorama. Relacionado: ChatGPT y sus riesgos actuales.
| Herramienta | Tipo | Mecanismo | Acción sobre denunciados | Integración |
|---|---|---|---|---|
| Tangled Vouching | Plataforma integrada | Red de confianza explícita con ATProto | Badge rojo, sin bloqueo | Nativa en Tangled |
| Vouch (Mitchell Hashimoto) | Herramienta separada | Archivos .td + Nushell | Configurable por el mantenedor | Manual, cualquier repo |
| GitHub PR permissions | Configuración de plataforma | Restricción de acceso por tipo de usuario | Bloqueo total de contribución | Nativa en GitHub |
| BewAIre (Datadog) | Herramienta de análisis | Clasificación ML de PRs benign/malicious | Alerta, no bloqueo directo | Integración custom |
Vouch de Mitchell Hashimoto (sí, el creador de Vagrant y HashiCorp) apunta a proyectos que no están en Tangled. Usa archivos .td en el repositorio para declarar colaboradores confiables y scripts en Nushell para procesar las decisiones. Es más artesanal, pero funciona con cualquier repo Git.
GitHub permite configurar restricciones de PR para usuarios nuevos o colaboradores externos, pero es binario: contribuyen o no contribuyen. No tiene la granularidad de badges contextuales.
BewAIre de Datadog es distinto: en vez de declarar confianza humana a humano, analiza el PR mismo y clasifica si el comportamiento es malicioso (cambios de permisos, ofuscación Unicode, modificaciones a archivos de CI) o benigno. Según el post de ingeniería de Datadog, su modelo alcanza 99.3% de precisión en sus tests internos (tomalo con pinzas, es el propio fabricante).
Decay de Vouches: El Detalle que Importa a Largo Plazo
El equipo de Tangled ya tiene en el radar un problema que parece menor pero no lo es: los vouches no deberían durar para siempre.
La idea de “decay temporal” es que un vouch emitido hace tres años por alguien que ya no mantiene proyectos activos debería perder peso. Los colaboradores cambian, los proyectos cambian, y la confianza calibrada en 2023 no necesariamente refleja el comportamiento de 2026.
El otro feature pendiente son los rastros de evidencia: vincular un vouch a un PR específico. “Te voucheo porque revisé y aprobé este PR concreto” tiene mucho más valor que “te voucheo porque me parece bien”. Sin esa vinculación, el sistema puede llenarse de vouches por amistad o por reciprocidad, no por mérito real.
Ninguno de estos dos features está en producción todavía. Son los próximos pasos declarados por el equipo.
Señales de Alerta: Cómo Identificar Pull Requests Sospechosos
Si no usás Tangled, o si usás GitHub y querés empezar a detectar PRs problemáticos sin herramientas extra, hay patrones que se repiten. Más contexto en modelos de lenguaje modernos.
El más tramposo es el “uncanny valley” de código: el PR se ve correcto a primera vista, pasa el linter, los tests no fallan (porque los tests también los generó el LLM y están diseñados para pasar, no para validar la lógica real). Revisando despacio aparece la falla: un caso borde no contemplado, una asunción incorrecta sobre el estado del sistema, una función que llama a algo que no existe en tu versión.
Otros red flags más fáciles de detectar:
- Múltiples PRs del mismo usuario a distintos proyectos con el mismo patrón de commit y descripción.
- Cambios en archivos de CI/CD, permisos, o configuración de secretos que no tienen relación con el issue que supuestamente resuelven.
- Caracteres Unicode homoglifos para ofuscar lógica maliciosa (buscar caracteres que “parecen” ASCII pero no lo son).
- Descripción del PR más larga y elaborada que el código mismo, con explicaciones que no cierran con lo que hace el diff.
- El PR resuelve el título del issue pero no su descripción real.
¿Y cuántos de los LLMs populares introducen fallas de seguridad? Según datos de Veracode de 2026, 45% del código generado por los modelos testados incluye al menos una falla del OWASP Top 10. No todos los PRs de IA son maliciosos, pero la proporción de código con problemas es alta.
Cómo Implementar Verificación en Tu Proyecto Hoy
Pasos concretos según el stack que usés.
Si tu proyecto está en Tangled
Activá vouching desde la configuración del proyecto. Empezá voucheando a los colaboradores con los que ya tenés historial positivo. Cuando alguien nuevo mande un PR, revisá si alguien de tu red lo voucheó antes de invertir tiempo en revisión profunda. Si hay bandera roja, pedí que el contribuidor explique el proceso detrás del PR antes de abrirlo.
Si usás GitHub
Configurá “Require approval of new contributors” en los settings de PRs del repo. Eso te da una capa de fricción sin bloquear a todos. Agregá a tu CONTRIBUTING.md una sección de disclosure de IA (Ghostty lo hace: piden que se indique si el código fue asistido por IA y qué partes). Usá GitHub Actions para correr análisis de seguridad en cada PR; si el repo tiene configuración de Secrets, revisá que el PR no las toque.
Para proyectos en cualquier plataforma
La herramienta Vouch de Hashimoto funciona con cualquier repo Git. Creás un archivo .td donde declarás colaboradores de confianza y usás los scripts para procesar decisiones. Es más trabajo inicial, pero no depende de ninguna plataforma específica. Si tu proyecto está en una instancia propia de Gitea o en donweb.com con hosting propio, es la única opción nativa.
Errores Comunes al Gestionar PRs Sospechosos
Error 1: Rechazar PRs de IA por principio, no por calidad. El problema no es el uso de IA, es el código de baja calidad o malicioso. Un PR generado con asistencia de IA que fue revisado, testeado y ajustado por un humano puede ser perfectamente válido. Mezclar ambas cosas lleva a perder colaboradores de buena fe.
Error 2: Asumir que los tests que pasan = PR correcto. Un LLM puede generar tests que validan su propio código incorrecto. Los tests pasan porque fueron diseñados para pasar ese código específico, no para validar el comportamiento real del sistema. Revisión humana del happy path y casos borde es irremplazable. Sobre eso hablamos en Google y detección de contenido.
Error 3: Denounce sin razón textual. Si denunciás a alguien en Tangled sin explicar por qué, el dato es casi inútil para el resto de la red. “PR malicioso” sin contexto no le dice nada a otro mantenedor. “Mandó tres PRs con ofuscación Unicode en el parser de autenticación” sí le dice algo.
Preguntas Frecuentes
¿Cómo puedo proteger mi proyecto open source del spam de pull requests generado por IA?
Si usás Tangled, activá vouching para ver badges de confianza de tu red antes de revisar PRs. En GitHub, configurá aprobación requerida para nuevos contribuidores y agregá disclosure de IA en tu CONTRIBUTING.md. Para análisis automatizado de PRs potencialmente maliciosos, herramientas como BewAIre de Datadog clasifican comportamientos sospechosos (cambios en permisos, ofuscación) con alta precisión.
¿Qué es un sistema de vouching y cómo funciona en práctica?
Es una red de confianza explícita donde los mantenedores declaran formalmente si un colaborador es confiable o no, con una razón textual. En Tangled, los usuarios avalados muestran un escudo verde en comentarios, issues y PRs; los denunciados muestran uno rojo. Solo ves las decisiones de tu círculo directo (atenuación), lo que evita que la reputación de un usuario popular distorsione toda la red.
¿Cuál es la diferencia entre un pull request malicioso y uno de mala calidad?
Un PR de mala calidad tiene código incorrecto, tests que no cubren los casos importantes, o no resuelve el problema declarado. Uno malicioso tiene intención de comprometer el proyecto: puede introducir código con ofuscación Unicode, modificar archivos de CI para exfiltrar secretos, o cambiar configuraciones de permisos de forma encubierta. Según el análisis de Datadog, los PRs maliciosos tienen patrones detectables distintos de los simplemente malos.
¿Qué es Vouch de Mitchell Hashimoto y en qué se diferencia de Tangled?
Vouch es una herramienta independiente creada por Mitchell Hashimoto (fundador de HashiCorp) que funciona con cualquier repositorio Git, no solo Tangled. Usa archivos .td para declarar colaboradores de confianza y scripts Nushell para procesar decisiones. Tangled integra el vouching en la plataforma social con ATProto, lo que permite que los datos de confianza sean portables y vivan en el PDS del usuario, no en el servidor de la plataforma.
¿Los usuarios denunciados en Tangled quedan bloqueados del proyecto?
No, al menos en esta versión inicial del sistema. Un usuario denunciado solo ve una etiqueta roja en la UI de Tangled; no hay restricción de acceso ni bloqueo automático. La lógica es que la señal sirve para informar la decisión del mantenedor, no para sancionarlo automáticamente. El equipo de Tangled planea agregar más consecuencias opcionales en versiones futuras.
Conclusión
El sistema de vouching de Tangled no es una solución mágica. Es un paso concreto en la dirección correcta: pasar de confiar implícitamente en cualquiera que abra un PR, a construir señales explícitas de reputación que viajan con el colaborador a través de proyectos.
Lo que cambió en 2026 es que el problema ya no es teórico. Los mantenedores de proyectos reales están invirtiendo horas en revisar código generado automáticamente, y eso tiene un costo que no aparece en ningún benchmark de productividad de IA. Cualquier fricción bien diseñada que reduzca ese costo tiene valor real.
El decay temporal de vouches y los rastros de evidencia vinculados a PRs concretos van a ser los features que determinen si esto escala o queda como un sistema de amigos-avalan-amigos. Por ahora, si mantenés proyectos en Tangled, vale activarlo. Si estás en GitHub, Vouch de Hashimoto o las restricciones nativas de PR son un punto de partida razonable.