Cursor añade modo de equipo a Projects: los agentes de los compañeros comparten contexto y tareas

Si has probado a ejecutar varios agentes de programación en paralelo, sabes cómo se ve en la práctica. Una persona, un coordinador, un puñado de workers. Todo va bien mientras trabajas solo. En cuanto se incorpora un segundo ingeniero a la tarea, cada uno acaba con su propio conjunto de chats, su propio contexto y su propia versión de lo que está pasando. Cursor ha decidido resolver precisamente este problema: Projects se ha vuelto «multijugador».

Qué ha cambiado

Recordemos que Projects es un modo en el que el ingeniero lleva una tarea grande a través de un coordinador, que reparte el trabajo entre agentes. Antes, este sistema atendía a una sola persona. Ahora se puede invitar a colegas a un Project, y todo el equipo trabaja en un mismo espacio junto con todos los agentes.

La compañía destaca tres cosas.

La primera es un tablero de tareas común. En él se ve quién está haciendo qué, en qué trabajan los agentes de cada participante y qué pull request hay detrás de cada tarea. Las personas y los agentes miran la misma imagen actualizada, en lugar de reconstruirla a partir de chats e hilos.

La segunda es una capa de contexto compartida. Cada participante sigue teniendo un chat personal con el coordinador y workers con su propio contexto local. Por encima hay una base común: requisitos, diagramas, especificaciones técnicas, maquetas. Una decisión tomada en un chat pasa a estar disponible para todos los agentes del proyecto. Cuando una persona nueva llega a un Project, el contexto ya está configurado y actualizado.

La tercera es la comunicación de los agentes entre sí. Los coordinadores de los colegas ven lo que hacen los demás y pueden ponerse de acuerdo sin intervención humana.

Cómo se ve en ejemplos

Cursor presenta varios escenarios. El más terrenal son las guardias (on-call). Varios equipos de la compañía hacen la rotación en un Project común. Cuando un ingeniero recibió el turno de un colega, su coordinador primero comprobó que todo fuera correcto y luego continuó desde donde lo había dejado el anterior. Ya sabía qué tareas estaban en curso, qué solicitudes quedaban sin atender, qué había que transmitir sobre incidentes y notas, y qué canales, tableros de Linear e hilos vigilar. El trabajo sin terminar se puede traspasar directamente: el agente del nuevo guardia simplemente lo retoma.

Otros dos ejemplos tratan de conflictos. Un ingeniero añade reseñas a la página de un producto mientras un diseñador la rediseña. Los coordinadores detectan el solapamiento con antelación y las reseñas se integran directamente en el nuevo diseño, sin refactorizar después. O tu funcionalidad lee de la base de datos y un colega cambia el esquema: los agentes acuerdan de antemano el orden de los trabajos y al final no hay que desenredar conflictos de merge.

La idea es clara y conocida: lo que antes se resolvía en una reunión o por mensajes se traslada a los coordinadores.

Qué conviene tener en cuenta

Todo esto es, por ahora, una descripción del propio proveedor. No hay cifras: ni cuánto tiempo ahorra el contexto compartido, ni con qué frecuencia los agentes detectan realmente solapamientos, ni con qué frecuencia se equivocan. Los ejemplos de las reseñas y el esquema de la base de datos parecen ilustraciones, no resultados de mediciones. Solo las guardias se describen como práctica real, y aun así dentro de la propia compañía.

También quedan preguntas abiertas. ¿Quién y cómo verifica la capa de contexto compartida si se cuela una decisión incorrecta que ahora ven todos los agentes? ¿Cómo se gestionan los permisos de acceso a documentos y canales? ¿Qué ocurre si los coordinadores acuerdan un orden pero las personas piensan otra cosa? El blog no responde a esto. Además, el modo acaba de llegar a beta.

Qué hacer en la práctica

Si tu equipo ya usa Cursor, tiene sentido probar un Project en una tarea pequeña pero real, en la que participen dos o tres personas. Buenos candidatos: traspaso de guardias, una funcionalidad que se solapa con el trabajo de otro, la incorporación de un nuevo desarrollador. Se puede crear un Project en el menú izquierdo y luego invitar a los colegas.

Hazte enseguida dos preguntas. ¿Se dedica menos tiempo a explicar el contexto a los recién llegados? ¿Ha disminuido el número de conflictos al fusionar? Si las respuestas son positivas, es una señal de que la capa de contexto compartida funciona. Si no, por ahora es una idea bonita y no una herramienta de trabajo. Para product managers y líderes de equipo, la conclusión principal es sencilla: la competencia entre agentes de programación se desplaza de «cuyo agente es más listo» a «cuyo sistema organiza mejor el trabajo de varias personas y varios agentes juntos».