El 10 de septiembre Cursor lanzó Projects en beta y, en cuanto leí el anuncio, me sonó a déjà vu con tono de keynote. Un coordinador que no escribe código pero puede delegar en miles de subagentes, mantener contexto durante meses, seguir tu canal de Slack y arreglar el CI cuando falla. Suena espectacular. También suena a la misma promesa que llevamos escuchando desde febrero, cuando Michael Truell hablaba de la «tercera era» del desarrollo con software: flotas de agentes que se encargan de cuerpos de trabajo enteros mientras tú te dedicas a «dirigir el trabajo en sí».
Yo no voy a negar que la idea tiene lógica. Las migraciones que arrancan con entusiasmo y mueren a la tercera PR porque nadie quiere seguir limpiando conflictos son un clásico en cualquier equipo mediano. Cursor dice que Projects mantiene archivos de contexto compartidos entre máquinas locales y nubes, que los agentes van aprendiendo cómo prefieres que se pruebe un servicio y que el coordinador reutiliza eso en tareas futuras. En papel, es justo lo que falta cuando cierras un chat y al día siguiente el modelo vuelve a preguntarte dónde está el docker-compose.
Pero aquí es donde empiezo a ponerme incómodo. Porque entre «coordinador» y «responsable» hay un abismo que en el marketing desaparece con elegancia.
El coordinador que no escribe código (y tampoco firma el despliegue)
Según el propio changelog de Cursor, el agente coordinador planifica, crea subagentes para investigar, implementar y probar, y te devuelve el trabajo terminado para que lo revises. No escribe código él mismo, lo cual en teoría evita el bloqueo de un agente único atascado en un refactor interminable. Bien. El problema es quién revisa ese output cuando el coordinador puede lanzar «tantos en paralelo como el trabajo necesite» y habla de miles de subagentes.
Cursor publica cifras internas llamativas: usuarios nuevos fusionan un 30% más de PRs, y quienes usan Projects sobre todo lo demás, seis veces más. Me interesa menos el porcentaje que la pregunta obvia: ¿de qué calidad? Fusionar más no es lo mismo que entregar más valor. Un coordinador que vigila Slack y abre PRs cada vez que entra un bug report puede multiplicar el ruido en tu repositorio más rápido que cualquier junior con acceso a Copilot y café doble.
En mi experiencia, el cuello de botella nunca ha sido «escribir la PR», sino entender por qué esa PR no rompe facturación un martes a las nueve. Delegar la implementación sin delegar el criterio es la receta perfecta para acumular deuda técnica con commit messages impecables.
Contexto persistente: memoria o archivo de excusas
La pieza más seductora de Projects es el contexto compartido que crece con el tiempo. Planes, demos, instrucciones de testing, preferencias de estilo. Si un agente descubre cómo levantar un servicio en local, los siguientes deberían heredarlo. Perfecto en un equipo pequeño con convenciones claras.
Ahora piensa en una pyme con tres developers, uno de ellos freelance que entra dos días a la semana, y un coordinador que lleva semanas acumulando «lecciones aprendidas» en archivos que nadie audita. Ese contexto no es documentación: es estado opaco. Si el coordinador aprende mal —porque el primer agente pasó los tests con un mock cutre—, lo aprendido mal se propaga. Cursor lo vende como ventaja compuesta; yo lo veo como un vector de errores sistemáticos difíciles de rastrear porque ya no viven en un chat que puedes borrar, viven en la infraestructura del proyecto.
Slack, CI y la tentación de automatizar la supervisión
Lo que más me ha hecho levantar la ceja son las «suscripciones»: el coordinador puede seguir un canal de Slack, monitorizar PRs, reaccionar a fallos de CI o ejecutarse en horario. Conectas el canal de bugs y empieza a delegar cada aviso. Suena a soporte nivel dos automatizado. También suena a escenario donde un agente cierra tickets tocando síntomas porque el pipeline vuelve a verde, no porque el bug desaparezca.
RuntimeWire recoge bien el matiz: Cursor no detalla en el lanzamiento los límites por cuenta ni el coste de compute cuando escalas a cientos de subagentes en la nube. Cada Project corre en «su propio ordenador en la nube», así que cerrar el portátil no frena el trabajo. Genial para una migración larga. Menos genial si no sabes cuánto te va a costar ese ordenador corriendo un fin de semana mientras el coordinador reintenta arreglar tests flaky que nunca debiste mergear.
Y aquí encaja con lo que se comenta en reviews como la de eesel AI: el coordinador «nunca está bloqueado» porque no es quien edita. Eso mejora la UX de dirección, sí. No resuelve el problema de fondo: alguien tiene que leer el diff. Si tu equipo ya no revisa PRs pequeñas hechas a mano, ¿vas a revisar un árbol de subagentes con worktrees en paralelo?
La tercera era que olvida la primera
Cursor enmarca Projects como la implementación concreta de su tesis de febrero: pasar de autocompletado a agentes síncronos y llegar a flotas autónomas. Es narrativa bonita. Pero la primera era —entender qué hace tu software— no caduca porque llegue la tercera. De hecho, cuanto más agentes metes en el flujo, más necesitas trazabilidad, no menos.
Comparo esto con GPT-6 Astra y Claude Fable 5.1, que han salido la misma semana prometiendo autonomía en el ordenador y luego admitiendo que vigilar el razonamiento interno es más difícil que nunca. Cursor no tiene ese problema de caja negra neuronal, pero sí tiene una caja gris operativa: miles de decisiones pequeñas distribuidas en subagentes con contexto compartido. El resultado final puede ser código que compila, tests que pasan y un dashboard en verde. Eso no es lo mismo que software que entiendes.
Para equipos de producto con presupuesto, cultura de revisión fuerte y migraciones claras —sustituir un design system, adoptar un framework— Projects puede ser una palanca seria. Para la pyme típica de ticweb.es, que mantiene un WordPress con plugins de terceros y un WooCommerce que ya da suficientes sustos, me da miedo que «seis veces más PRs» se lea como «seis veces menos tiempo pensando».
No digo que lo pruebes. Digo que si lo pruebas, trata al coordinador como a un becario muy rápido y muy confiado: con checklist de revisión, límites de scope y alguien humano que firme lo que sale a producción. Porque el día que el coordinador arregle el CI a las tres de la mañana mientras duermes, el verde del pipeline no te va a despertar más tranquilo si no sabes qué cambió.
Si mañana tu coordinador de Cursor te propusiera fusionar automáticamente todo lo que pase CI en una rama de staging sin pedirte confirmación, ¿confiarías en el contexto acumulado del proyecto o preferirías seguir aprobando PR a PR aunque el pipeline tarde el triple?