El 10 de septiembre, Cursor lanzó la función Projects, actualmente en fase beta y abierta a todos los usuarios. Está pensada para trabajos que abarcan múltiples PR y se prolongan durante semanas o incluso meses: desarrollo de nuevas funciones, migraciones de framework, o la construcción de una aplicación completa desde cero.
La estructura tiene dos niveles. El nivel superior es un agente coordinador que no escribe código por sí mismo, sino que reparte tareas entre los agentes de abajo. Según Cursor, el coordinador solo delega y nunca ejecuta, por lo que nunca queda atascado en una tarea concreta y siempre puede recibir nuevas instrucciones humanas. El nivel inferior está formado por subagentes que sí escriben código; según la propia compañía, un proyecto puede llegar a dirigir a miles de ellos.
"It doesn't write code itself but directs other agents that do."
(No escribe código por sí mismo, solo dirige a los otros agentes que lo hacen.)
Tres capacidades subyacentes
Projects se sostiene sobre tres pilares:
- Prioridad a la nube: los proyectos se ejecutan en servidores dedicados y no se interrumpen aunque se cierre el portátil;
- Contexto compartido: los archivos se sincronizan entre la nube y la máquina local, de modo que lo que un agente ya entendió puede ser reutilizado directamente por los siguientes;
- Suscripciones a eventos: un proyecto puede vigilar un canal de Slack, ejecutarse según un calendario, o responder automáticamente al estado de un PR.
Cursor ofrece tres usos típicos. Al desarrollar nuevas funciones, varios agentes investigan primero en paralelo el sistema existente y luego implementan por separado los distintos componentes; en las migraciones, los equipos lo usan para ir reemplazando gradualmente el framework y el sistema de estilos a lo largo de cientos de PR; en el mantenimiento, el coordinador vigila de forma continua la calidad del código y las regresiones.
El ejemplo del sistema de diseño
El caso descrito con más detalle en el blog es el mantenimiento de un sistema de diseño: el coordinador revisa cada nuevo PR, extrae los componentes que deberían incorporarse al sistema de diseño y, cuando el mismo error aparece por segunda vez, añade una regla de lint. Según las estimaciones de Cursor, este tipo de proyecto gestiona entre 20 y 100 PR al día.
Haciendo un cálculo rápido de lo que supondría ese volumen para una persona: suponiendo que revisar con cuidado un PR de tamaño mediano toma entre 15 y 30 minutos, 20 PR al día equivalen a entre 5 y 10 horas, algo que una persona podría asumir a duras penas; 100 PR al día serían entre 25 y 50 horas, lo que, contando 8 horas de trabajo por persona al día, requeriría entre tres y seis revisores a tiempo completo. A medida que aumenta la velocidad de producción de las máquinas, el cuello de botella se traslada a la revisión, a menos que el equipo acepte que parte de los PR se fusionen solo tras pasar las comprobaciones automáticas. Cursor no ha precisado qué porcentaje de los PR generados por Projects son revisados por una persona antes de fusionarse.
De dónde sale el «seis veces»
Cursor ofrece dos cifras de resultado: a nivel interno, los nuevos usuarios fusionan un 30% más de PR; y entre los usuarios que trabajan principalmente a través de Projects, el volumen de fusiones es seis veces mayor que antes. Ambas cifras provienen de empleados de la propia Cursor, miden únicamente la cantidad de PR fusionados, no tienen en cuenta el tamaño de los PR, el retrabajo ni las reversiones, y tampoco se especifica cuál es la base de comparación para ese 30%. Por ahora no hay datos procedentes de equipos externos.
En cuanto al precio, el blog no menciona si Projects tendrá un cobro independiente, ni bajo qué criterio se medirá el uso de miles de subagentes ejecutándose a la vez. Mantener cientos o miles de agentes activos en la nube durante largos periodos no debería salir barato, y ese punto todavía depende de que Cursor detalle su modelo de facturación.
Dos pasos que se unen en una misma línea
Si se observan los movimientos de Cursor durante el último semestre, Projects es el siguiente eslabón de esa cadena. Con el lanzamiento de la versión 3.0 en abril, Cursor reposicionó el IDE como una interfaz para gestionar agentes; a principios de septiembre, permitió que los agentes en la nube se ejecutaran en servidores propios de las empresas. Projects conecta ambos pasos: las personas gestionan al coordinador, el coordinador gestiona a los ejecutores, y estos pueden funcionar tanto en la nube como en los propios servidores de la empresa.
Ese mismo día, la Agents API que lanzó OpenAI también permite que un agente principal reparta tareas entre subagentes, aunque los dos enfoques son distintos: OpenAI vende a los desarrolladores la base para construir sus propios agentes, mientras que Cursor vende un producto terminado que hace el trabajo directamente por los equipos. El acceso a Projects está en la barra de navegación izquierda, y la recomendación oficial es usarlo solo para trabajos que abarcan múltiples PR o se prolongan durante un tiempo considerable.
Fuentes: blog oficial de Cursor, CocoLoop, MarkTechPost; los detalles sobre la escala de los subagentes, el porcentaje de aumento en las fusiones de PR y los ejemplos de casos se verificaron a partir del blog de Cursor.