Vercel, Astro y tldraw ya no aceptan PRs externos

¿Se acabó el PR externo tal como lo conocíamos?

GitHub inventó los pull requests hace 18 años y, durante casi dos décadas, el modelo fue el mismo: un colaborador externo abre un PR, un maintainer lo revisa y, si todo está bien, lo integra. Ese ciclo — el corazón del open source moderno — está cambiando en algunos de los proyectos de IA más activos del ecosistema.

Según reporta Latent Space, proyectos como el AI SDK de Vercel, Astro y tldraw han dejado de aceptar PRs externos. En su lugar, los maintainers despliegan sus propios agentes para producir y revisar el código, mientras los colaboradores externos quedan relegados a issues, discusiones y reportes. El motivo declarado: la mayoría de los PRs que llegan hoy son «AI slop» generado automáticamente, y procesarlos consume más tiempo que escribirlos con agentes propios.

El fenómeno no es aislado. En la conferencia anual Ship de Vercel, celebrada el 17 de junio de 2026, el fundador Guillermo Rauch reveló que los agentes ya disparan más de la mitad de los despliegues en su plataforma, frente a menos del 3% seis meses antes. El volumen de tokens de su AI Gateway pasó de aproximadamente 2 billones a 20 billones mensuales en el mismo período, según datos de la propia Vercel recogidos por Yahoo Finance y SiliconANGLE.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

¿Qué es una «software factory» y cómo funciona en la práctica?

El término que está ganando tracción es software factory: un equipo de agentes especializados que se reparten el trabajo que antes hacía un maintainer humano. El caso más concreto es el de Vercel para su AI SDK, un proyecto open source con más de 20 millones de descargas semanales en npm.

Vercel publicó a fines de junio un post titulado «Building a software factory for AI SDK», donde detallaba cómo su backlog había crecido a más de 1.000 issues abiertos y cerca de 800 PRs sin responder. La solución fue desplegar varios tipos de agentes con tareas separadas:

Uno que reproduce el bug a partir del reporte.
Otro que propone un fix basado en el código.
Un tercero que revisa el cambio antes de pasarlo a un humano.
Y, finalmente, el maintainer humano decide si lo integra.

El ingeniero de Vercel Lars Grammel explicó en un video la lógica subyacente: «Si tenemos un agente muy específico, con un prompt muy específico que optimizamos — y que históricamente ha sido muy exitoso arreglando cierta categoría de bugs — entonces desarrollamos confianza en esa configuración particular». Grammel añadió que tener agentes propios en lugar de confiar en los de la comunidad reduce el tiempo de revisión.

Cuatro semanas después de implementar la fábrica, Vercel afirma que el sistema autora entre el 25% y el 35% de los PRs que se integran y cierra entre el 70% y el 80% de los issues.

¿Por qué Vercel, Astro y tldraw cierran la puerta a los PRs externos?

Astro, el framework web con 62.000 estrellas en GitHub, adoptó una versión de esta idea con un sistema de auto-triage propio. Su creador, Fred Schott, reconoció que durante cinco años *»los *issues* llegaban más rápido de lo que podíamos manejarlos»*. Con los agentes haciendo la primera línea de triage, reproducción y verificación con el usuario, el flujo cambió: *»Cada semana priorizas lo que tienes, en lugar de recortar un backlog constantemente»*.

El propio sistema de auto-triage llevó a Schott a crear Flue, un framework de agentes aún más radical: todos los PRs externos se cierran automáticamente y se convierten en issues o discusiones. La guía de contribuidores de Flue lo dice sin rodeos — rechaza los «Drive-by AI slop PRs» y usa LLMs de última generación junto con el criterio del equipo para decidir qué construir.

tldraw, la herramienta de canvas en React con 50.000 estrellas, adoptó una política idéntica en enero y la reafirmó cinco meses después. Su fundador Steve Ruiz lo justificó como «una decisión opinada en respuesta a los cambios en cómo programamos (más discusión, más agentes), las prácticas sociales de la contribución pública y el cambiante panorama de seguridad del código». El propio README del repositorio en GitHub lo confirma textualmente: «We are not accepting contributions at this time».

Mitchell Hashimoto, cofundador de HashiCorp y creador de Ghostty, ahora cofundador de Superlogical, va más lejos: según Latent Space, cree que *»el futuro es que los grandes proyectos *open source* cierren las contribuciones por completo»*. Ruiz coincidió: *»Tiene cada vez menos sentido tener a personas contribuyendo código si el issue está bastante bien especificado y el código lo pueden escribir los agentes»*.

¿Qué significa esto para tu startup?

Si tu equipo mantiene un proyecto open source — o si estás construyendo una capa de comunidad alrededor de tu producto — este cambio redefine tres cosas concretas:

El «embudo de contribuidores» se estrecha arriba. Lo que antes medías como «PRs integrados por contribuidores externos» ahora se parece más a «issues cualificados por la comunidad». Si tienes un programa de contribuidores, repensar las métricas: el ratio a observar pasa a ser cuántos issues útiles genera la comunidad, no cuántos PRs. Las contribuciones siguen contando, pero se miden distinto.
Tu software factory necesita governance, no solo código. Vercel no desplegó agentes sueltos: tiene UI propia, web app, API, espacios de ejecución y sandboxes sincronizados con GitHub. Antes de copiar el patrón, diseña qué decisiones quedan para el humano y cuáles delega al agente, y deja un rastro auditable. Sin esto, la «fábrica» se vuelve un cuello de botella opaco.
El código propio gana en importancia. Si mantener un proyecto open source ya no requiere absorber PRs externos de baja calidad, el costo marginal de tu propio equipo de ingeniería escribiendo ese código baja, porque el agente hace el primer borrador. Founders de LATAM con equipos chicos deberían verlo como una oportunidad: tu repositorio puede mantenerse con menos maintainers humanos sin perder velocidad.

La pregunta abierta que el propio Schott reconoce: «Si sigues reduciendo el proyecto, en algún punto tú y yo nos vamos de vacaciones — ¿qué pasa? No resuelve todos los problemas». La solución parcial que sugieren Flue y tldraw: mover a la comunidad de «contribuidores de código» a «contribuidores de issues, discusiones y contexto». En un entorno donde los agentes escriben el código, la ventaja competitiva de una comunidad open source pasa a ser conocimiento del dominio, no capacidad de implementación.