Next.js usa agentes con sandbox y revisión humana para limpiar su backlog de incidencias

El equipo de Next.js ha descrito un uso de agentes de programación que resulta más instructivo que una demostración de generación de código. El problema era mantener útil el repositorio de incidencias: el proyecto tenía 2.244 reportes abiertos el 10 de agosto de 2026, muchos mezclados con duplicados, errores ya corregidos, versiones sin soporte o regresiones actuales. En unas tres semanas, el equipo redujo la cifra a menos de mil y cerró 1.462 incidencias en todo el repositorio.

La primera lección es que la inactividad no equivale a irrelevancia. Next.js ya había probado un flujo que marcaba como obsoletas las incidencias sin actividad durante un periodo largo, pero esa señal temporal no podía distinguir un problema abandonado de un bug real que nadie había vuelto a investigar. El nuevo sistema, llamado closability, intenta reconstruir el contexto técnico antes de recomendar una acción.

Cada investigación se ejecuta en un sandbox nuevo con el repositorio de Next.js, Node.js, Playwright y Chromium. El agente lee la conversación de GitHub, comprueba las versiones soportadas, busca incidencias y pull requests relacionados, revisa commits y documentación, e intenta reproducir el comportamiento en la versión afectada, en la estable más reciente y en canary cuando resulta necesario. La salida no es una frase libre, sino un resultado estructurado con confianza, motivo principal, evidencias y referencias.

Ese diseño contiene varias decisiones de ingeniería que merecen atención. El agente es de solo lectura fuera de su sandbox: puede investigar, pero no comentar, cerrar incidencias, subir código ni desplegar. También debe buscar pruebas que contradigan su primera conclusión. Un fallo al reproducir no basta para cerrar un reporte y una confianza alta exige evidencia actual sin indicios creíbles en sentido contrario. En un sistema donde el texto de las incidencias puede contener instrucciones maliciosas, ignorar instrucciones encontradas en el propio material analizado añade una defensa básica contra prompt injection.

Los mantenedores revisaron la evidencia antes de ejecutar el cierre masivo. De las 1.462 incidencias, 543 correspondían a problemas ya corregidos, 278 eran duplicados, 237 describían un comportamiento esperado, 89 dejaron de reproducirse y 66 afectaban a versiones obsoletas o no soportadas. La reapertura automática durante catorce días ofreció una válvula de seguridad: solo tres incidencias se reabrieron y el 99,8 % seguía cerrado el 4 de septiembre.

La arquitectura no convierte al agente en autoridad absoluta. Next.js mantiene agentes separados para reproducir problemas, verificar canary, localizar regresiones, crear pruebas end-to-end y preparar arreglos. Para los casos más claros, el proyecto ha empezado a automatizar cierres con una segunda revisión independiente, pero los cambios de código siguen necesitando revisión humana.

La conclusión aplicable a otros equipos es sobria: la automatización útil necesita límites, trazabilidad y reversibilidad. Un agente de mantenimiento debe tener un entorno reproducible, salidas verificables, acceso mínimo, una política conservadora de confianza y un mecanismo sencillo para deshacer decisiones. El valor no está en cerrar más tickets, sino en convertir el backlog en conocimiento técnico fiable sin borrar las señales que todavía necesitan atención.