Primera tarea larga en Cursor Projects: checklist de delegación, memoria y triggers

Ejecuta la primera tarea larga como un experimento controlado

Antes de dejar que un agente ejecute una funcionalidad larga en tu repo, asígnale una tarea acotada y detente antes del merge. El objetivo es comprobar si la delegación, el aislamiento de ramas, la memoria y los triggers aguantan. La variable es cuánto autonomía recibe el agente, la salida esperada es un diff revisable y el rollback es una rama que puedes eliminar.

Cursor presentó Projects el 10 de septiembre de 2026. La función Projects estaba en beta y el despliegue a todos los usuarios de Cursor comenzó el mismo día. Los nuevos usuarios hacen merge de un 30% más de pull requests, y los usuarios que usan principalmente Projects hacen merge seis veces más. Considera ese aumento como un motivo para probar, no como una prueba. Projects no está disponible en planes Enterprise ni con Privacy Mode (Legacy), porque los agentes en la nube mantienen el código en la nube. Si tu repo no puede salir del edificio, detente antes de escribir el prompt.

Verifica la delegación y el aislamiento de ramas antes del merge

Usa este checklist para la primera ejecución. Cada punto es una verificación que puedes hacer antes de que la ejecución se vuelva costosa.

• Redacta un brief corto con alcance, cambios prohibidos y una definición de «hecho»; si un ingeniero nuevo no podría saber qué significa «hecho», reescríbelo.
• Observa el primer turno del coordinador: debería producir una lista de tareas y delegar, no abrir archivos y editar código.
• Pide aislamiento y comprueba que cada subagente tiene su propia rama o worktree antes de cualquier merge.
• Después de la ejecución, abre los archivos de memoria del proyecto y confirma que contienen notas útiles del codebase, no solo logs.
• Añade un trigger solo después de que la ejecución manual pase la revisión; si se activa, debería realizar una acción acotada.

Ejecuta la tarea manualmente primero. Deja que el coordinador planifique, que los subagentes trabajen y detente antes del merge. Si el plan es incorrecto, no has desperdiciado una ejecución larga; solo has gastado una revisión.

En Projects, el coordinador planifica el trabajo, lo divide en tareas y entrega la implementación a otros agentes en lugar de escribir código. El primer turno es una sonda útil. Si empieza a editar archivos, el brief era demasiado vago o el coordinador está haciendo el trabajo de un programador. Un buen plan debería ser aburrido: tareas pequeñas, responsables claros, sin dependencias ocultas.

Por defecto, los subagentes comparten el checkout del agente padre, por lo que las ediciones simultáneas pueden sobrescribirse entre sí a menos que pidas aislamiento. Cuando pides aislamiento, cada subagente obtiene su propio Git worktree o VM en la nube dedicada, y sus cambios permanecen en una rama separada hasta que el agente padre hace merge. Antes de que nada se integre, señala las ramas separadas e indica qué agente es dueño de cada una. Los checkouts compartidos van bien para un agente solo. Se convierten en un desastre cuando varios agentes tocan el mismo archivo al mismo tiempo.

Revisa la memoria y añade un trigger acotado

Un Project mantiene los archivos de contexto compartido sincronizados entre máquinas en la nube y locales, para que los agentes posteriores puedan reutilizar lo que las ejecuciones anteriores aprendieron sobre el codebase y tus preferencias. La revisión pregunta si un agente nuevo usaría la nota mañana. Si los archivos son en su mayoría logs, la memoria no ha merecido su lugar. La memoria debe ser corta, concreta y reutilizable: la función rara, la prueba que importa, la preferencia que ya declaraste.

Un Project puede escuchar un canal de Slack, activarse según un horario o reaccionar a eventos de pull request, y luego tomar una acción sin un prompt humano. Añade eso solo después de que la ejecución manual sea limpia. Un trigger es una instrucción permanente. Debe ser lo suficientemente acotado para que puedas leer la acción y decidir si fue razonable.

Si el trigger puede hacer muchas cosas, has construido un agente sin bucle de revisión. Una ejecución paralela de cinco subagentes usa aproximadamente cinco veces el costo en tokens de un agente único, y las tareas simples pueden ralentizarse porque cada subagente empieza con un contexto limpio. Revisa la acción antes de dejar que se ejecute de nuevo.