GitHub inventó los pull requests y durante 18 años estuvieron abiertos por omisión. Ahora algunos de los principales proyectos de código abierto nativos de IA los están apagando, porque encontraron una forma que consideran mejor.
Proyectos como Flue y tldraw rechazan los pull requests de colaboradores externos, en parte porque suelen venir generados con IA. En su lugar, los mantenedores prefieren usar sus propios agentes para crear y gestionar esos cambios.
Además, muchos proyectos empezaron a usar lo que llaman una fábrica de software para administrar los aportes de la comunidad. En la práctica esto implica un equipo de agentes que clasifica un pull request, reproduce el problema si es un error, implementa la corrección o la nueva funcionalidad, la revisa y la devuelve a una persona para que la fusione.
La fábrica de software de Vercel para el AI SDK
Vercel publicó hace poco un artículo titulado Building a software factory for AI SDK. Ahí describe cómo el proyecto de código abierto AI SDK, que supera los 20 millones de descargas semanales en npm, desplegó agentes para recuperar el control de su acumulación de pull requests y problemas abiertos, que a fines de junio había llegado a "más de 1.000 problemas abiertos y casi 800 pull requests".
El sistema de Vercel tiene varios tipos de agentes, cada uno enfocado en una tarea distinta. Hay un agente que reproduce un error, otro que aplica la corrección y otro más que revisa esa corrección.
Una de las razones principales por las que Vercel montó esta fábrica es que confía más en sus propios agentes que en los que ejecutan los miembros de la comunidad.
"Si tenemos un agente muy específico con una indicación muy específica que optimizamos, y sabemos que a lo largo del tiempo fue muy exitoso corrigiendo cierta categoría de errores, entonces desarrollamos confianza en esa configuración de agente en particular", explicó el ingeniero de Vercel Lars Grammel en un video de YouTube.
"Para los proyectos de código abierto, vale la pena considerar tener tus propios agentes y tu propia configuración, y no necesariamente confiar en la comunidad, porque en realidad puede reducir tu tiempo de revisión", agregó.
Grammel también mostró la arquitectura de despliegue del sistema y señaló que "hay una interfaz de usuario, hay una aplicación web, hay una API por debajo, hay un espacio de ejecución y hay entornos aislados". Eso después se sincroniza con GitHub, que dispara otras acciones automáticamente. La interfaz que mencionó Grammel es de desarrollo propio.
Apenas cuatro semanas después de implementar la fábrica, Vercel afirma que ahora "escribe entre 25% y 35% de los pull requests que fusionamos y cierra entre 70% y 80% de los problemas reportados".
¿Qué cambió en Astro con la clasificación automática?
El framework web Astro, que tiene 62.000 estrellas en GitHub, también adoptó lo que su creador Fred Schott llama "esa idea de fábrica de software".
"Durante cinco años estuvimos en este lugar donde los problemas entraban más rápido de lo que podíamos manejarlos", dijo Schott a Latent Space. Ahora, con agentes encargados de la clasificación, recuperaron el control.
"Cambió por completo en los últimos seis meses", señaló. "Ahora podemos resolver estos problemas con estas automatizaciones, que manejan la clasificación, la reproducción y hacen que el usuario verifique la corrección que sugiere el bot antes de que nosotros siquiera la miremos".
El resultado no fue solo una baja fuerte en los problemas abiertos, sino un cambio completo en la forma en que el equipo de Astro trata las solicitudes entrantes de la comunidad.
"Nunca vi eso en más de una década de experiencia con código abierto", dijo Schott. "Poder tratar los problemas como algo que cada semana priorizas, pase lo que pase, en vez de una acumulación que estás recortando constantemente".
El sistema de clasificación automática de Astro llevó directamente a que Schott creara un framework de agentes nuevo, llamado Flue.
Flue no acepta tus pull requests, pero sí la discusión
Con Flue, Schott intenta un enfoque todavía más radical. La guía de colaboradores de Flue declara que "vamos a intentar reimaginar las cosas", en parte para evitar lo que llama "pull requests de relleno con IA al pasar".
Básicamente, explicó Schott, cada pull request externo del proyecto Flue se cierra automáticamente y se convierte en un problema o una discusión. Los reportes de errores y las propuestas de corrección pasan a problemas; las solicitudes de funcionalidades, a discusiones.
"Si envías un pull request, sin resentimientos, simplemente vamos a representarlo por ti como problemas y discusiones. Y desde ahí, tratar de encontrar la forma correcta de sumar gente".
Es algo parecido a tratar las solicitudes entrantes como leads comerciales, en vez de como una pieza de trabajo que un mantenedor se siente obligado a revisar. La guía explica que el proyecto combina la experiencia del equipo con "los mejores modelos de lenguaje de vanguardia a los que tenemos acceso" para decidir en qué trabajar. Una vez tomada la decisión en el problema o la discusión, se despliegan agentes para "investigación, diseño, implementación y revisión inicial".
Si nuestros agentes escriben el código, tu aporte externo pierde valor
Al igual que Flue, la herramienta de dibujo en React tldraw, de código disponible y 50.000 estrellas, cierra automáticamente los pull requests externos.
Su creador, Steve Ruiz, anunció la política en enero y cinco meses después la reiteró, señalando que fue "una decisión con criterio, tomada en respuesta a los cambios en la forma en que estamos programando (más discusión, más agentes), a las prácticas sociales alrededor de la contribución pública y al panorama cambiante de la seguridad del código".
Mitchell Hashimoto, cofundador de HashiCorp, creador de Ghostty y hoy cofundador de Superlogical, va todavía más lejos. Piensa que "el futuro es que los proyectos grandes de código abierto van a cerrar las contribuciones por completo".
Ruiz respondió: "Tiene menos sentido que haya gente aportando código si el problema está decentemente especificado y el código lo pueden escribir agentes".
Puesto en una tabla, el giro se ve así:
| Proyecto | Escala | Política con aportes externos |
|---|---|---|
| AI SDK (Vercel) | 20 millones de descargas semanales | Abierto, con agentes que escriben 25-35% de lo fusionado |
| Astro | 62.000 estrellas | Abierto, con clasificación y reproducción automáticas |
| Flue | Framework nuevo | Cierra todo pull request y lo convierte en problema o discusión |
| tldraw | 50.000 estrellas | Cierra automáticamente los pull requests externos |
¿Y qué pasa con la comunidad?
Tradicionalmente en código abierto, los pull requests fueron revisados por los mantenedores no solo por el código, sino para formar a quienes aportan y evaluarlos como futuros mantenedores. Si proyectos como AI SDK y Astro usan sus agentes para hacer gran parte de la revisión y la implementación, queda la pregunta de dónde deja eso a los miembros de la comunidad que quieren involucrarse más.
Schott reconoce el riesgo. "Igual deja este hoyo abierto de, bueno, si sigues estrechando el proyecto, en cierto punto tú y yo nos vamos de vacaciones, y qué pasa. No resuelve realmente todos los problemas".
Sin embargo, que tanto Flue como tldraw no acepten pull requests pero sí acepten problemas y discusiones nuevas quizás apunta a una salida: que al hablar más entre ellos, los miembros de la comunidad se conozcan mejor y se ganen la confianza mutua, lo que sirve tanto para aprender de los pares como para demostrar que se merece ser mantenedor.
En cuanto al código, si a los mantenedores les resulta más fácil usar IA que aceptar aportes externos, entonces, como lo puso Steve Ruiz, "es mejor limitar la contribución de la comunidad a los lugares donde todavía importa: reportar, discutir, aportar perspectiva y cuidado".
