Migrar 180 microservicios a una versión nueva del framework

A quién le sirve. Equipos de desarrollo con muchas aplicaciones pequeñas que hay que actualizar a la vez a una versión nueva de una herramienta; no es para un negocio sin programadores.

Qué hicieron

Brex repartió el trabajo entre dos agentes de Cursor alojados por la propia empresa. Al crear un ticket en Linear se activa un agente generador. Combina scripts con el razonamiento de un modelo de lenguaje, compila en local, se corrige a sí mismo y abre una solicitud de cambios (pull request) en borrador. Una etiqueta en GitHub activa después un agente de validación que despliega en desarrollo, lanza pruebas de integración y corrige fallos hasta tres veces. Los dos agentes cargan once pequeñas habilidades, una por tipo de fallo.

Cómo salió

Un ingeniero migró 180 microservicios en un mes, lo que Brex cifra en 32 veces más por persona. El coste por servicio bajó cerca de un 90 %. Unas pocas solicitudes pasaron todas las pruebas y aun así causaron fallos sutiles en producción.

Conviene saber

Un único prompt gigante lanzado desde portátiles falló. Lo arreglaron con agentes en la nube, habilidades modulares y un tope de tres intentos. Aun así hizo falta revisión humana, y las pruebas flojas dejaron pasar errores.

Qué necesitas

• Cursor con agentes en la nube y un plan que lo permita
• Tu código en GitHub, con pruebas automáticas que funcionen
• Un gestor de tareas como Linear, que active el agente al crear un ticket
• Un entorno de desarrollo donde desplegar y probar
• Un ingeniero que revise cada cambio

Cómo hacerlo tú, paso a paso

1. Elige una migración repetitiva, con versión de origen y de destino, y define qué significa «hecho»: que compile y pase las pruebas.
2. Migra a mano un servicio y apunta los tipos de fallo que salen. Cada tipo será una pequeña habilidad del agente, es decir, una instrucción corta y específica.
3. Crea un agente generador que, al abrirse un ticket, aplique los cambios, compile en local, se corrija solo y abra en borrador una solicitud de cambios (pull request, una propuesta de cambio en el código para que otros la revisen).
4. Crea un segundo agente validador, que se active con una etiqueta en GitHub: despliega en desarrollo, lanza las pruebas de integración y corrige fallos con un tope de tres intentos.
5. Ejecuta los dos agentes en la nube y no en portátiles.
6. Prueba con unos pocos servicios y ajusta las habilidades antes de lanzar el resto.
7. Revisa cada solicitud con una persona antes de pasarla a producción, aunque las pruebas pasen.

Escribe un agente de migración que se corrija solo y actualice [lista de servicios o repositorios] de [versión antigua del framework] a [versión nueva], compilando y ejecutando las pruebas tras cada cambio y arreglando los fallos automáticamente. Que informe del avance servicio por servicio. Habrás terminado cuando todos los servicios compilen y pasen las pruebas. Párate antes de abrir ninguna solicitud de cambios para que yo la revise.

Consejos

• Pon un tope de intentos al agente. Sin él puede dar vueltas sin fin.
• Refuerza las pruebas antes de migrar: unas pruebas flojas dejan pasar errores.
• No lances un único prompt gigante. Divide el trabajo en agentes y habilidades pequeñas.

Preguntas frecuentes

Fuentes

• brex.com ↗

En el directorio desde el 3 de octubre de 2026.