AIREITERLa arquitectura de Cursor basada en un coordinador y varios subagentes resulta realmente útil para migraciones grandes de bases de código, pero no funciona como un botón de reescritura desatendida. Su mayor ventaja aparece cuando el trabajo puede dividirse en piezas acotadas y comprobables; el riesgo aumenta cuando los agentes comparten contratos, archivos o reglas de negocio que no están documentadas. También conviene tomar con cautela la etiqueta «Projects»: la documentación oficial actual se centra en subagentes, ejecución asíncrona, agentes en la nube y tareas de programación de larga duración, no en una única página de producto de Projects documentada de forma coherente.
Qué aporta realmente Cursor Projects beta a los equipos de migración
La documentación actual de subagentes de Cursor describe un Agent principal que delega tareas especializadas en ventanas de contexto independientes. Cada subagente devuelve su resultado al agente principal, puede ejecutarse en primer plano o en segundo plano y configurarse con sus propias herramientas, modelo y permisos de escritura.
Esta es la unidad arquitectónica que resulta útil en una migración: un coordinador mantiene el alcance y las decisiones, mientras los especialistas exploran el repositorio, implementan cambios acotados, ejecutan pruebas o revisan el resultado. Cursor también documenta subagentes en la nube con su propia máquina virtual, rama y clon del repositorio; una configuración bastante más segura que permitir que varios agentes editen el mismo checkout.
La advertencia sobre la beta es importante. En una discusión de lanzamiento de Cursor de febrero de 2026 se anunciaron subagentes asíncronos y anidados, pero algunos usuarios informaron de problemas de fiabilidad al activar tareas en segundo plano. Un miembro del equipo de Cursor respondió que el problema relacionado con is_background: true debía solucionarse en Cursor 2.6. Por tanto, considera su disponibilidad y comportamiento dependientes de la versión, no un plano de control garantizado.
El flujo de migración que más partido saca de la coordinación
Un coordinador aporta valor cuando se encarga de la secuencia, no cuando intenta escribir cada línea. En una migración de framework o de lenguaje, esta división del trabajo resulta práctica:
| Rol | Resultado útil | Por qué conviene separarlo en otro contexto |
|---|---|---|
| Explorador del repositorio | Mapa de dependencias, puntos de entrada y límites del código generado | Los resultados de búsqueda pueden saturar el hilo principal |
| Planificador de la migración | Paquetes de trabajo ordenados e invariantes | La planificación necesita una visión completa del repositorio |
| Implementador | Cambios en un módulo, servicio o worktree | Un alcance reducido limita las ediciones no relacionadas |
| Agente de pruebas | Comprobaciones nuevas y existentes para una pieza concreta | Los registros de pruebas son extensos y se pueden aprovechar de forma independiente |
| Revisor | Hallazgos sobre regresiones, seguridad y convenciones | Un contexto nuevo está menos condicionado por la implementación |
| Coordinador | Comprobaciones de contratos, decisiones ante conflictos y siguiente oleada | Hace falta un único punto que reconcilie resultados incompatibles |
El informe de Cursor sobre programación de larga duración describe una estructura similar de planificadores, trabajadores y juez. En su experimento de migración de Solid a React, Cursor habla de más de tres semanas de trabajo y aproximadamente 266.000 adiciones y 193.000 eliminaciones, aunque también señala que fue necesaria una revisión cuidadosa. Es una prueba de que la arquitectura puede sostener un esfuerzo grande, no de que una migración sea segura para producción por defecto.
Dónde ayuda la arquitectura en bases de código grandes
1. Inventario y mapa de dependencias
Las migraciones grandes suelen fallar desde el principio cuando el equipo pasa por alto un punto de llamada, un script de compilación, un archivo generado o una suposición del despliegue. Un explorador dedicado puede rastrear esas superficies mientras el coordinador convierte los hallazgos en un registro de migración.
Es mejor que pedirle a un único agente que «migre el repositorio», porque el resultado se puede inspeccionar: paquetes afectados, relaciones de dependencia, interfaces públicas, cobertura de pruebas y supuestos pendientes de resolver. La guía de modernización de Cursor recomienda Plan Mode, .cursor/plans/ y reglas de migración como .cursor/rules/migration.mdc.
2. Transformaciones repetitivas y acotadas
Los subagentes encajan bien en tareas como actualizar llamadas a API obsoletas, convertir módulos contenidos o migrar servicios con interfaces estables. El límite seguro no es simplemente el nombre de una carpeta, sino una pieza que tenga:
- Un responsable y un alcance de archivos definidos.
- Un contrato de entrada y salida por escrito.
- Un comando de compilación y pruebas.
- Una rama o worktree aislado.
- Una definición clara de terminado.
La documentación de Cursor advierte que varios subagentes que comparten el checkout predeterminado pueden sobrescribirse entre sí. Los worktrees aislados o las ramas en la nube mantienen los cambios separados hasta que el coordinador o una persona los integre.
3. Colas de mantenimiento y verificación en segundo plano
El mantenimiento suele ofrecer un paralelismo natural: investigar pruebas inestables, revisar advertencias de dependencias, actualizar la documentación y analizar una pull request son tareas que pueden avanzar por separado. La ejecución en segundo plano mantiene disponible el agente principal, mientras que los agentes en la nube pueden continuar en sus propias máquinas virtuales.
Para las revisiones, la documentación de Agent Review de Cursor ofrece los modos Quick y Deep. Deep es más lento y caro, y Cursor lo recomienda para lógica compleja, código sensible desde el punto de vista de la seguridad y refactorizaciones grandes. El flujo de Source Control compara todo el conjunto de cambios local con la rama principal, no solo la edición más reciente.
Esto hace que la arquitectura sea útil para el mantenimiento, pero la revisión debe seguir siendo un punto de control. El informe aprobado de un subagente no equivale a una prueba de integración superada ni a una pull request aprobada.
Dónde se rompen los flujos de coordinador y subagentes
Los contratos transversales limitan el paralelismo seguro
Los cambios de frontend, backend, base de datos y servicios no siempre se pueden paralelizar solo porque estén en directorios distintos. Un cambio de esquema puede invalidar una API; un cambio en la API puede invalidar clientes generados; y una utilidad compartida puede hacer que dos ediciones aparentemente independientes entren en conflicto.
Una petición de funcionalidad en el foro de Cursor para un «Monorepo Execution Plan» describe bien la disciplina que falta: los trabajadores con alcance limitado deberían recibir los requisitos globales, los contratos de API y los cambios de esquema, y después un coordinador tendría que validar rutas, tipos y esquemas antes de la integración. Esa publicación es una petición, no una prueba de que todo este flujo esté resuelto de extremo a extremo hoy.
En una migración, congela los contratos antes de lanzar agentes de implementación. Si un contrato tiene que cambiar, crea una fase de compatibilidad o convierte ese cambio en la siguiente decisión serializada del coordinador.
El aislamiento del contexto también implica perder contexto
Los subagentes empiezan con un contexto limpio; no heredan automáticamente la conversación del agente principal. El coordinador debe transmitir de forma explícita las reglas relevantes, los patrones de destino, las restricciones y los artefactos necesarios. Un resumen breve puede omitir justo el caso límite que resulte decisivo seis horas después.
Usa artefactos duraderos en lugar de depender de la memoria de la conversación:
migration-plan.mdpara el alcance y la secuencia.migration-ledger.csvpara el estado de los paquetes y las excepciones.contracts/para instantáneas de las API y los esquemas.decisions.mdpara las alternativas descartadas.- Un informe de pruebas adjunto a cada rama de implementación.
Esto también ayuda a combatir las decisiones obsoletas. Un coordinador persistente puede conservar el historial, pero el historial no se convierte automáticamente en verdad. Hay que volver a validar los supuestos después de actualizar dependencias, cambiar esquemas o descubrir un comportamiento heredado nuevo.
Más agentes también pueden significar más coste e interferencias
La documentación de Cursor estima que cinco subagentes en paralelo consumen aproximadamente cinco veces los tokens de un trabajo comparable realizado por un único agente. La misma documentación indica que la selección del modelo puede sufrir un fallback si un administrador bloquea un modelo, el plan no lo admite o un plan antiguo requiere Max Mode. No hagas el presupuesto basándote únicamente en el modelo del agente principal.
Los comentarios de usuarios reales muestran por qué hace falta un bucle de control explícito:
«con muy pocos, los mensajes se quedan en cola para siempre; con demasiados, empiezan a interferir entre sí» — @siggelabor, X
Una discusión en Reddit recoge casos de usuarios que vieron cómo los subagentes consumían más uso de modelos del esperado y recurrieron a .cursorrules para desaconsejar la delegación, aunque también señala que esa regla no estaba garantizada. Limita la concurrencia, asigna modelos más económicos a la exploración, reserva los modelos más potentes para la planificación y la revisión, y comprueba el consumo antes de ampliar la siguiente oleada.
Que las pruebas pasen no demuestra que la migración esté completa
El preprint de SWE Refactor Bench sirve como advertencia útil para cualquier análisis de Cursor Projects. De 520 ejecuciones que cubrían 20 tareas de migración de repositorios completos, solo 28 —el 5,4 %— superaron la auditoría de migración, las pruebas de comportamiento corregidas y la verificación adversarial. El artículo también concluyó que las reescrituras de lenguaje obtuvieron una media de 5,6/100, frente a 31,4/100 en las reescrituras de herramientas de compilación.
La lección es metodológica: una migración necesita controles separados para comprobar la sustitución y la preservación. Verifica que el stack antiguo haya desaparecido del código fuente y del cierre de compilación; después compara el comportamiento; por último, utiliza una verificación independiente para detectar diferencias ocultas. «La CI está en verde» es una señal, no el veredicto.
Una forma más segura de usar Cursor en una migración
- Establece una línea base del sistema antiguo. Registra los comandos de compilación, las interfaces públicas, resultados representativos, rutas sensibles al rendimiento y excepciones conocidas antes de modificar el código.
- Pide a un explorador de solo lectura que mapee el repositorio. Incluye paquetes, artefactos generados, configuración, scripts de despliegue y carencias de pruebas.
- Crea un plan y un registro de migración. Divide el trabajo por comportamiento y responsabilidad, no solo por directorio.
- Prueba primero una pieza contenida. Usa una implementación de referencia ya migrada para fijar las convenciones de nombres, gestión de errores, compatibilidad y pruebas.
- Lanza implementadores con alcance limitado en ramas aisladas. Incluye en cada prompt el contrato exacto y las rutas que no se pueden tocar.
- Ejecuta la validación local por pieza. Exige comprobaciones de tipos, pruebas unitarias, pruebas de integración, resultado de compilación y un resumen del diff antes de informar de que el trabajo está terminado.
- Haz una revisión independiente. Usa un revisor nuevo y elige Deep Agent Review para cambios de alto riesgo o transversales.
- Integra por oleadas. El coordinador reconcilia los contratos; una persona debe aprobar las fusiones que impliquen datos, autenticación, infraestructura o API públicas.
- Repite las comprobaciones diferenciales. Compara el sistema migrado con la línea base usando entradas representativas y rutas de error.
- Detente cuando empeoren las evidencias. Más paralelismo no significa avanzar si aumentan las colas, los conflictos, los reintentos o los hallazgos de revisión.
Veredicto de Cursor Projects beta según el tipo de carga
| Carga de trabajo | Encaje | Recomendación |
|---|---|---|
| Cambios repetitivos en módulos independientes | Alto | Usa implementadores en paralelo con ramas aisladas y reglas compartidas |
| Actualización de dependencias o framework | Medio-alto | Planifica primero, prueba un módulo piloto y amplía después por oleadas |
| Reescritura de lenguaje grande con pocas pruebas | Medio-bajo | Usa agentes para el inventario y piezas concretas; mantén la validación del comportamiento bajo control humano |
| Migración de esquemas y API entre servicios | Medio | Serializa las decisiones sobre contratos y paraleliza la implementación solo después de estabilizarlos |
| Mantenimiento continuo de pruebas, PR y dependencias | Alto | Usa agentes en segundo plano o en la nube con límites de concurrencia y coste |
| Tareas puntuales de formato o changelog | Bajo | Usa un comando o una skill; un subagente añade una sobrecarga innecesaria |
| Renombrado masivo determinista con pruebas sólidas | Medio | Prioriza scripts y CI cuando la transformación sea mecánica y fácil de revertir |
Mi conclusión: merece la pena probar la arquitectura de coordinador y subagentes de Cursor en migraciones grandes cuando el repositorio tiene límites comprobables y el equipo puede imponer el aislamiento por ramas. En un sistema mal documentado y con poca cobertura de comportamiento, usa el coordinador como responsable del inventario y la verificación, no como implementador autónomo.
Preguntas frecuentes sobre Cursor Projects beta
¿Cursor Projects beta es lo mismo que los subagentes de Cursor?
La documentación oficial de Cursor está organizada en torno a subagentes, ejecución asíncrona, agentes en la nube y programación multiagente; «Projects» es una etiqueta beta cuyo alcance puede variar según la versión y la cuenta.
¿Los subagentes de Cursor pueden ejecutarse en paralelo?
Sí, pero incluso las tareas independientes necesitan alcances, contratos y worktrees aislados definidos de forma explícita para evitar conflictos.
¿Puede un subagente lanzar otro subagente?
Cursor documenta los subagentes anidados. Úsalos con moderación, porque los árboles más profundos aumentan la coordinación, el consumo de tokens y la carga de verificación.
¿Los agentes seguirán trabajando si cierro el portátil?
Los subagentes en la nube pueden continuar en sus propias máquinas virtuales; Cursor señala que la configuración local de MCP no se reutiliza automáticamente en la nube.
¿Puedo imponer un modelo concreto para cada subagente?
Cursor permite usar modelos heredados o específicos, pero las reglas del administrador, del plan y de los planes antiguos pueden activar un fallback, así que debes comprobar el uso real.
¿Cómo puedo impedir que los subagentes sigan generándose?
Usa instrucciones de tarea y reglas del repositorio, y después comprueba el comportamiento según tu plan y versión; los informes de usuarios sugieren que estos controles no siempre están garantizados.
La decisión que debes tomar antes de activar un enjambre
Haz una prueba piloto de una semana con una única pieza de migración. Adóptalo solo si no aumentan las regresiones que llegan a producción y el tiempo ahorrado supera el trabajo adicional del coordinador, el tiempo de revisión y la sobrecarga por uso de modelos. Si no es así, utiliza scripts, CI o un único agente para esa clase de cambio.