De 2.244 issues a menos de mil en unas tres semanas: lo que me llevo del caso Next.js.
- claude-code
- agentes-de-codigo
- nextjs
- subagentes
- automatizacion
- mcp
- ia
- productividad
El 10 de agosto de 2026, el backlog de Next.js tenía 2.244 issues abiertos. Unas tres semanas después, según el propio equipo, estaba por debajo de mil, y entre una fecha y otra habían entrado 218 reportes nuevos.
La cuenta está en un post publicado el 4 de septiembre, cuyo título habla de "un mes". Si hacés la resta (2.244 menos 1.462 cerrados más 218 nuevos) da justo 1.000, así que tomo las cifras como orden de magnitud.
La explicación corta, según el post, es un agente de investigación y maintainers que leyeron la evidencia detrás de cada resultado, más algunos cierres hechos por fuera de esa revisión.
Lo leí como alguien que usa agentes todos los días y mira primero qué le dejaron hacer al agente y qué no. En mi flujo de trabajo suelo dejar que un agente haga una primera pasada de revisión antes de que yo abra un PR. La decisión sigue siendo mía.
Ver esa misma lógica aplicada a miles de issues me pareció un buen caso para desarmar.
¿Qué hizo exactamente el agente?
El repositorio recibe en promedio 36 reportes nuevos por semana, y el backlog había llegado a su pico de 3.109 issues abiertos en enero de 2025. Según cuentan, los agentes de código hicieron más fácil presentar reportes detallados, y eso trae un volumen bastante mayor para revisar.
Ya habían probado marcar como inactivos y cerrar los issues sin movimiento, primero a los dos años y después a los 18 meses. Ayudó a bajar el backlog, pero la inactividad resultó un mal reemplazo de la relevancia: cerraron algunos reportes que debían quedar abiertos.
Entonces armaron closability, un agente que corre sobre eve, el framework open source de agentes de Vercel. Para cada issue trabaja en un sandbox limpio con el repositorio, Node, Playwright y Chromium.
Lee la conversación y las versiones soportadas, busca issues, PRs, commits, releases y documentación relacionados y, cuando hace falta, intenta reproducir el bug en la versión reportada, en la última estable y en canary. Al final busca evidencia que contradiga su primera conclusión.
Devuelve datos estructurados: puntaje de confianza, motivo principal, resumen, evidencia y referencias. Cada investigación tardó en promedio 30 minutos, y para recorrer todo el backlog fueron subiendo la concurrencia hasta tener 200 sesiones a la vez.
Un detalle que me pareció honesto de contar: la corrida sobre todo el backlog la hicieron con GPT-5.6 Luna, con el esfuerzo de razonamiento al máximo. El post no dice qué modelo usan los otros agentes. Lo que se puede copiar es el diseño, no un modelo en particular.
El resultado fueron 1.462 issues cerrados, con la aclaración de que en esa cuenta hay algunos cierres hechos por fuera de esta revisión.
Los límites que le pusieron
Lo que más me llamó la atención fue lo que no le dejaron hacer. closability es uno de varios agentes de su "Maintainer Agent" (otros reproducen, verifican, hacen bisect, crean tests e2e y preparan fixes). Fuera de su sandbox solo puede leer: no comenta, no cierra, no pushea ni despliega.
Además lo configuraron para ignorar instrucciones que encuentre dentro de los issues o del repositorio, una defensa contra prompt injection. Y su puntaje de confianza es conservador: que no pueda reproducir un bug no alcanza para recomendar cerrarlo.
Según el post, los maintainers leyeron la evidencia detrás de cada resultado en una cola de cierre. En la mayoría de los casos alcanzaba con leer el resumen y revisar las fuentes ya reunidas.
Según la clasificación del agente, de los issues cerrados el 37% ya estaba arreglado, el 19% eran duplicados y el 16% era comportamiento esperado. Otro 17% quedó en "otros".
Antes de empezar sumaron una acción de GitHub para poder reabrir un issue si el cierre era un error, y después la usaron para chequear los resultados. Yo lo leo también como lo que les dio margen para ir rápido: si se equivocaban, había forma de volver atrás.
La autonomía llegó después. Al momento del post, dejan que los agentes cierren solos los casos más claros: el primer agente revisa y, si su puntaje es 80 o más, un segundo agente busca razones para dejar el issue abierto. Si los dos recomiendan cerrar, el segundo elige el motivo y redacta el comentario, y una acción de GitHub aparte cierra el issue.
Empezaron con hasta 25 por semana, y la gente puede reabrir el issue si se equivocan. Cada lunes, además, el agente investiga hasta 100 issues sin actividad hace al menos 30 días. Todo cambio de código sigue pasando por revisión humana antes de entrar a Next.js.
¿Qué me llevo para mi propio trabajo?
Simon Willison escribió el 24 de septiembre que los agentes hacen la ingeniería todavía más difícil: sacarles todo el potencial pide una disciplina y un conocimiento extraordinarios. Para mí, Next.js lo muestra bien: buena parte del resultado salió del sistema que armaron alrededor del agente.
Mi versión chica de todo esto es este blog. Tiene un MCP donde un agente crea los artículos: le cuento qué quiero escribir y el borrador aparece en mi panel, en español y en inglés, enlazados. Este artículo llegó así.
Borrar solo funciona sobre borradores, y eso lo impone el código. Publicar lo decido yo.