Cursor 2.0 a fondo: Composer, codificación multiagente, precios, riesgos de seguridad y la carrera de los AI IDEs

Puntos clave

• Cursor 2.0 marca el paso de la edición asistida por IA al desarrollo dirigido por agentes. Ya no es solo una capa de autocompletado sobre un editor tipo VS Code; avanza hacia un espacio de trabajo coordinado por agentes.
• Composer es el intento de Cursor de crear una ventaja estratégica propia. Al introducir su propio modelo de codificación, Cursor reduce la dependencia total de modelos frontier de terceros y puede optimizar latencia, coste y flujos dentro del editor.
• La interfaz multiagente cambia el papel del desarrollador. En lugar de pedir una respuesta a un asistente, los desarrolladores pueden comparar varias implementaciones generadas por agentes antes de fusionar.
• La seguridad ya es un criterio de compra central. Los IDEs agentivos pueden escribir archivos, ejecutar comandos, modificar configuración y llamar herramientas MCP, por lo que prompt injection y confianza del workspace son más serios que en editores tradicionales.
• Cursor sigue siendo más fuerte para equipos de producto que iteran rápido. Es menos ideal para equipos que exigen salida totalmente determinista, ejecución solo local o gobernanza enterprise madura sin controles adicionales.

Por qué importa Cursor 2.0

La ventaja inicial de Cursor fue sencilla: hizo que programar con IA se sintiera nativo dentro del editor. Los desarrolladores podían autocompletar, chatear con la codebase, editar varios archivos y refactorizar sin copiar código a otro chatbot.

Cursor 2.0 va más allá. Replantea el IDE alrededor de agentes, planes, diffs revisables y ejecución en paralelo. Cursor presentó oficialmente Cursor 2.0 y Composer el 29 de octubre de 2025, destacando dos cambios principales: su primer modelo de codificación, Composer, y una nueva interfaz para trabajar con múltiples agentes en paralelo. ([Cursor][1])

Esto importa porque el mercado ha cambiado. Antes la competencia era sobre calidad de completions; ahora es sobre control del flujo de trabajo:

• ¿La herramienta entiende la estructura del proyecto?
• ¿Puede planificar antes de editar?
• ¿Puede ejecutar varias alternativas de forma segura?
• ¿Puede revisar sus propios cambios?
• ¿Puede el equipo gobernar lo que el agente lee, escribe y ejecuta?

Cursor 2.0 ataca directamente estos problemas de workflow de nivel superior.

Cursor 2.0 en una frase

Cursor 2.0 es un editor de código AI-native que combina un modelo propio de codificación, orquestación multiagente, flujos de planificación, herramientas frontend con contexto de navegador y superficies cloud/CLI en un entorno agentivo de desarrollo.

La página oficial también refleja este cambio: describe un agente que funciona en escritorio, CLI, GitHub, Slack, Linear, web y móvil. ([Cursor][2])

Para los desarrolladores, Cursor ya no es solo un reemplazo de editor. Se está convirtiendo en un plano de control de desarrollo para tareas de código.

Composer: el modelo de codificación propio de Cursor

La parte más importante de Cursor 2.0 es Composer. Tener un modelo propio permite optimizar todo el ciclo: construcción de prompts desde el estado del editor, recuperación de contexto, descomposición de tareas largas, generación de diffs, uso de herramientas, latencia y enrutamiento de costes.

Cursor afirma que Composer fue diseñado para programación y workflows agentivos. En la práctica, esto permite ajustar el modelo a acciones comunes del IDE en lugar de tratarlo como un endpoint genérico de chat.

Composer no elimina Claude, GPT, Gemini u otros modelos. Le da a Cursor más control sobre la ruta por defecto de las tareas cotidianas.

Codificación multiagente

La interfaz multiagente de Cursor 2.0 no es un simple truco de productividad. Un solo agente puede elegir una arquitectura incorrecta, editar demasiado o demasiado poco, o acertar la sintaxis sin entender la intención del producto.

Varios agentes en paralelo dan al desarrollador diversidad de implementación. En lugar de aceptar una solución, puede comparar diffs alternativos.

Los casos de mayor valor incluyen grandes refactorizaciones, rediseños frontend, cambios de API, optimización de rendimiento y bugs con causa incierta. La mención a hasta 8 agentes coincide con descripciones de terceros sobre agentes que trabajan en worktrees aislados o entornos remotos antes de la revisión. ([Codecademy][3])

La conclusión práctica: el modo multiagente sirve más cuando existen varias soluciones plausibles. Para cambios pequeños, una instrucción precisa es suficiente.

Plan Mode: la capa de fiabilidad

Plan Mode aborda la debilidad más peligrosa de los agentes de código: la ejecución sin control. Sin planificación, un agente puede editar antes de entender el repositorio, cambiar archivos incorrectos, romper convenciones o reescribir código estable sin necesidad.

Un flujo fiable consiste en inspeccionar la codebase, identificar archivos relevantes, proponer un plan, esperar revisión o avanzar con restricciones, generar cambios y presentar diffs.

Para trabajo complejo, conviene pedir:

Analiza primero la codebase. Identifica los archivos implicados, explica el plan de implementación, enumera riesgos y espera antes de editar.

Esto reduce cambios amplios accidentales y permite corregir supuestos antes de modificar código.

Herramientas de navegador y diseño

Cursor ha mejorado en frontend porque conecta mejor los cambios de código con la salida visual. En junio de 2026, Cursor describió mejoras de Design Mode para seleccionar múltiples elementos UI, entender relaciones de layout y usar voz para encolar cambios. ([Cursor][4])

Esto importa porque muchos bugs frontend no son textuales. CSS, layout, espaciado, responsive, estado de componentes y jerarquía visual son difíciles de corregir solo con contexto de código.

Cursor ayuda a convertir requisitos UI en componentes React, corregir regresiones visuales, ajustar Tailwind/CSS, conectar estados a APIs y generar pruebas de flujos. Aun así, producción requiere pruebas en navegador, responsive checks, accesibilidad, revisión de screenshots y pruebas de componentes.

Precios: lo que realmente hay que mirar

El precio de Cursor no se entiende solo por la etiqueta mensual. Importa la forma de uso.

La página oficial lista Hobby gratuito, planes individuales desde 20 USD/mes, Teams a 40 USD/usuario/mes y Enterprise con pooled usage, controles de repositorio/modelo/MCP, audit logs y service accounts. ([Cursor][5])

Cada plan incluye cierta cantidad de uso de modelos; al consumirla, se puede seguir con on-demand usage facturado después. ([Cursor][5]) Cursor también aclaró en 2025 que pasó de precio por request a included usage, y que “unlimited usage” aplica a Auto routing, no a todos los modelos. ([Cursor][6])

La pregunta correcta no es “¿Cursor cuesta 20 dólares?”, sino:

¿Con qué frecuencia el equipo usará tareas agentivas caras de largo contexto en vez de autocompletado ligero y Auto routing?

Riesgos de seguridad

Una reseña seria de Cursor debe hablar de seguridad. Los IDEs agentivos pueden leer archivos, escribir código, alterar configuración, ejecutar tests, lanzar shell commands, llamar MCP, interactuar con navegadores y generar feedback de PR. Eso los convierte en parte de la cadena de suministro de software.

Un ejemplo importante es CVE-2025-59944. La NVD explica que Cursor 1.6.23 y anteriores tenían comprobaciones case-sensitive al proteger archivos sensibles como .cursor/mcp.json, lo que permitía modificarlos mediante prompt injection y potencialmente lograr ejecución remota en sistemas case-insensitive. Se corrigió en la versión 1.7. ([NVD][7]) El advisory de GitHub describe el mismo bypass de sobrescritura de archivos sensibles. ([GitHub][8])

La lección: permisos de agente, protección de archivos y configuración MCP son fronteras de seguridad.

Checklist de hardening de Cursor

• Actualiza Cursor con rapidez.
• Activa Privacy Mode cuando corresponda. Cursor indica que impide usar datos de clientes para entrenamiento y mantiene acuerdos de zero data retention con proveedores de modelos. ([Cursor][9])
• Restringe servidores MCP. Aprueba solo herramientas de confianza y revisa cambios en .cursor/mcp.json.
• Aplica mínimo privilegio en terminal.
• Separa repositorios experimentales y de producción.
• Añade reglas de repositorio.
• Exige revisión humana de los diffs generados.

Ejemplo de regla:

Antes de editar, inspecciona los archivos relevantes y propón un plan.
No modifiques autenticación, facturación, despliegue o seguridad sin aprobación explícita.
No crees ni modifiques archivos MCP salvo que la tarea lo requiera.
Ejecuta tests después de los cambios y resume fallos con honestidad.
Prefiere diffs mínimos antes que reescrituras amplias.

Privacy Mode: qué resuelve y qué no

Privacy Mode es útil, pero no es un programa completo de seguridad enterprise. Reduce el uso de datos para entrenamiento, pero no resuelve contenido malicioso en repositorios, MCP inseguro, secrets en archivos locales, permisos de terminal demasiado amplios, revisión débil, dependencias vulnerables generadas ni requisitos de logging de compliance.

En enterprise debe combinarse con SSO, audit logs, controles de acceso, políticas de repositorio y restricciones de modelos/herramientas.

Cursor vs GitHub Copilot

GitHub Copilot sigue siendo el asistente por defecto para muchos equipos por su integración con GitHub, VS Code, JetBrains IDEs y el ecosistema Microsoft.

Cursor destaca por una orquestación agentiva más profunda dentro del editor.

Elige Cursor si la IA debe modificar activamente el proyecto. Elige Copilot si quieres baja fricción en herramientas existentes.

Cursor vs Windsurf

Windsurf compite directamente con Cursor. Cursor tiene más mindshare, una hoja de ruta agentiva agresiva y movimiento hacia infraestructura propia de modelos. Windsurf puede atraer a quienes prefieren una experiencia de edición más guiada.

• Usa Cursor para multiagente, tareas complejas de codebase y funciones agentivas rápidas.
• Usa Windsurf si el equipo prefiere una experiencia guiada antes de comprometerse.

Cursor vs Claude Code

Claude Code es más un agente de terminal que un IDE competidor. Cursor es mejor para contexto visual, inline diffs, flujos browser/design, extensiones estilo VS Code y revisión dentro del IDE. Claude Code es mejor para automatización CLI-first, workflows scriptables, comportamiento terminal-native y fuerte conexión con Claude.

Muchos usuarios avanzados usarán ambos: Cursor para edición interactiva y Claude Code para tareas pesadas de terminal.

Cursor vs JetBrains AI

JetBrains AI es fuerte para desarrolladores ya comprometidos con IntelliJ IDEA, WebStorm, PyCharm, GoLand u otros IDEs JetBrains. Cursor gana por diseño AI-first; JetBrains gana por tooling maduro de lenguaje, inspecciones, refactorización y profundidad enterprise.

En Java/Kotlin grande, backend enterprise o equipos ya estandarizados en JetBrains, reemplazar el IDE puede ser disruptivo. En TypeScript, React, startups y prototipado intensivo con IA, Cursor suele ser más fácil de justificar.

Mejor workflow para proyectos reales

Los mejores usuarios de Cursor no dicen “construye esta app”. Crean tareas acotadas para agentes.

1. Da contexto.
2. Pide un plan primero.
3. Limita el alcance.
4. Revisa el plan.
5. Ejecuta la implementación.
6. Inspecciona el diff.
7. Ejecuta tests y lint.
8. Haz revisión humana.

Ejemplo:

Estás en un proyecto Next.js TypeScript.
Objetivo: añadir una página saved-games que liste los juegos guardados del usuario actual.
Restricciones:
- No cambies la lógica de autenticación.
- No modifiques el esquema de base de datos.
- Reutiliza los API client utilities existentes.
- Mantén el diff mínimo.
Primero inspecciona los archivos relevantes y propón un plan. Espera aprobación antes de editar.

Errores comunes

• Dejar que los agentes editen sin plan.
• Usar multiagente para cambios triviales.
• Ignorar dependencias generadas.
• Aceptar diffs grandes a ciegas.
• Dejar herramientas MCP sin restricciones.
• Probar solo el happy path.
• Tratar Privacy Mode como seguridad completa.

Quién debería usar Cursor 2.0

Cursor encaja con startups que lanzan rápido, solo builders, frontend engineers en apps UI-heavy, full-stack developers que tocan muchos archivos, equipos que experimentan con AI-native workflows y desarrolladores cómodos revisando diffs generados.

Encaja peor con equipos que no pueden adoptar un nuevo editor, entornos regulados sin gobernanza adicional, desarrolladores que requieren ejecución IA solo local, trabajo low-level donde errores pequeños cuestan caro y organizaciones sin disciplina de code review.

Veredicto final

Cursor 2.0 muestra claramente hacia dónde van los AI IDEs: del autocomplete a la orquestación de agentes.

Sus puntos fuertes son Composer, multiagente, edición consciente del proyecto, herramientas browser/design e iteración rápida. Sus riesgos son seguridad, gobernanza, coste impredecible y dependencia excesiva del código generado.

Para individuos y equipos rápidos puede ser un gran multiplicador de productividad. Para empresas debe evaluarse como parte de la plataforma de desarrollo, no como otro editor.

Conclusión

Cursor 2.0 cambia el workflow de “escribir código con sugerencias” a “dirigir, revisar y gobernar agentes de codificación”. Es potente, pero exige mejores hábitos: prompts claros, revisión estricta, uso seguro de MCP y controles de repositorio.

Quienes comparen AI IDEs deberían evaluar Cursor junto a Windsurf, GitHub Copilot, Claude Code y JetBrains AI con tareas reales, no demos. El siguiente paso ideal es ejecutar la misma refactorización, bug fix y tarea frontend en varias herramientas y comparar calidad del diff, esfuerzo de revisión, coste y controles de seguridad.