Cursor lanza Projects en beta para tareas de código de larga duración

Cursor ha lanzado Projects en beta. Es un espacio de trabajo pensado para tareas de programación que se alargan en el tiempo. En lugar de un único agente que va haciendo todo de forma secuencial, Projects usa un agente coordinador que planifica el trabajo y delega la implementación en varios subagentes que corren en paralelo. El despliegue empieza hoy.

Cómo funciona

Los proyectos se ejecutan en equipos en la nube. Eso permite mantener el trabajo en marcha sin depender de que el portátil del desarrollador esté encendido o conectado. Cuando hace falta probar algo en la máquina del usuario, Projects puede levantar un agente local. Es decir, la parte de planificación e implementación vive en la nube, pero la validación puede bajar al entorno real del programador.

Cada proyecto mantiene un contexto compartido entre sus agentes. Ese es el punto que evita que cada subagente trabaje a ciegas: el coordinador reparte tareas, pero todos parten de la misma información. Cursor no ha detallado cómo se resuelven los conflictos cuando dos subagentes tocan el mismo archivo, ni qué límites tiene la beta.

Projects también puede suscribirse a señales externas: Slack, programaciones o pull requests. Cuando detecta algo relevante, actúa. La idea es que el sistema no solo responda a una instrucción manual, sino que se active con eventos del flujo de trabajo. Un pull request nuevo, un mensaje en un canal o una tarea programada pueden convertirse en el disparador para que los agentes se pongan en marcha.

Qué cambia para un equipo

Para quien ya usa asistentes de código, el salto está en el modelo de ejecución. Muchas herramientas actuales funcionan en modo conversación o completado dentro del editor. Projects apunta a tareas más largas, con varios agentes y ejecución en la nube. Eso encaja con trabajos de refactorización, migraciones, corrección de errores repetitivos o generación de pruebas, donde el cuello de botella no es escribir una función sino coordinar muchos cambios pequeños.

También introduce preguntas operativas. Si los agentes corren en la nube, hay que ver cómo se factura el tiempo de cómputo y qué aislamiento tienen esos entornos. Si se conectan a Slack y a pull requests, entran en juego los permisos: qué puede leer el agente, qué puede escribir y con qué identidad aparece en el repositorio. Y si lanzan un agente local para pruebas, habrá que definir qué partes del proyecto salen de la máquina y cuáles no.

La beta arranca hoy. El anuncio no incluye precios, límites ni una lista de integraciones soportadas más allá de Slack, programaciones y pull requests. Para un equipo de desarrollo, la utilidad real dependerá de si el coordinador aguanta tareas largas sin perder el hilo y de si los subagentes paralelos no generan más ruido que trabajo aprovechable. Esa es la parte que aún no se puede comprobar.