Cómo usar Cursor: describe el cambio y revisa el diff que te deja listo

Qué es Cursor

Le pides una función nueva, le dices en qué archivos tocar y qué no debe romper, y el agente de Cursor lee el código relevante, escribe el cambio en varios archivos a la vez y te deja el diff listo para revisar — sin que tengas que ir archivo por archivo tú mismo. Cursor es un editor de código creado originalmente por Anysphere, construido sobre la base abierta de VS Code, con ese agente integrado en el propio editor, no como una extensión aparte.

Al estar basado en VS Code, conserva sus atajos, temas y la mayoría de sus extensiones, aunque usa el registro Open VSX en lugar del Marketplace oficial de Microsoft.

Cambio corporativo reciente y relevante: según el blog de Cursor del 14 de agosto de 2026, Cursor fue «adquirida oficialmente por SpaceX». Cursor mantiene su marca. La fuente primaria no da el precio ni la valoración de la operación, y HubdAI no repite las cifras de la prensa. Tampoco se ha encontrado una declaración de cursor.com sobre qué implica el cambio para el tratamiento de los datos de los usuarios, algo que merece la pena vigilar en equipos con requisitos de cumplimiento.

Cómo empezar con Cursor

1. 1. Descargar Cursor

   Entra en cursor.com y descarga la aplicación para tu sistema operativo, o instala la CLI.

2. 2. Abrir tu proyecto

   Si vienes de VS Code, Cursor puede importar tus atajos, tema y extensiones automáticamente.

3. 3. Empezar con el plan gratuito

   El plan Gratis no pide tarjeta y permite probar el autocompletado (Tab) y el agente con límites de uso.

4. 4. Configurar .cursorignore

   Define, con sintaxis de gitignore, qué archivos quedan fuera del indexado, del autocompletado y de las herramientas del agente — importante en repositorios grandes para reducir ruido y tiempo de indexado.

5. 5. Activar el modo de privacidad

   Recomendado si vas a trabajar con código privado o sensible — evita que tus conversaciones se usen para entrenar modelos, y está disponible incluso en el plan gratuito.

Flujo de trabajo: encargar una funcionalidad multi-archivo al agente

La propia documentación de Cursor da una plantilla explícita para un buen encargo al agente: describir el objetivo, la zona del código a tocar, el comportamiento esperado, qué NO debe tocarse, y cómo se comprueba que la tarea está terminada (por ejemplo, que pasen los tests).

Objetivo: añadir un botón de 'exportar a CSV' en la tabla de pedidos (src/components/OrdersTable.tsx). Alcance: solo ese componente y el hook useOrders — no toques el backend ni otras tablas. Criterio de éxito: al pulsar el botón se descarga un CSV con las columnas visibles de la tabla actual, y los tests existentes de OrdersTable siguen pasando.

1. 1. Abrir el panel de Agent y elegir modelo

   Según el equilibrio deseado entre velocidad, coste y capacidad de razonamiento.

2. 2. Escribir el encargo con objetivo, alcance y criterio de éxito

   Cuanto más concreto, menos probable que el agente toque algo fuera de lo pedido.

3. 3. Dejar que explore el repositorio y proponga un plan

   El agente busca y lee el código relevante antes de editar nada.

4. 4. Revisar el diff antes de aceptar

   La propia guía de buenas prácticas de Cursor advierte explícitamente contra aceptar cambios multi-archivo sin revisar — un pitfall real y repetido: el agente a veces borra y recrea un archivo entero en vez de editarlo, lo que destruye el historial de git y puede reintroducir errores ya corregidos.

5. 5. Dividir tareas grandes en subtareas

   Para trabajos extensos, encargar partes más pequeñas por separado suele dar mejor resultado que un único encargo enorme.

Flujo de trabajo: Cursor Rules para las convenciones del proyecto

Las reglas viven como archivos .mdc dentro de .cursor/rules/ (el antiguo archivo único .cursorrules en la raíz del proyecto sigue funcionando pero está marcado como heredado). Cursor también recoge automáticamente un archivo CLAUDE.md en la raíz del proyecto si existe, y lo aplica siempre — un dato útil de interoperabilidad entre herramientas de distintos fabricantes.

• Always Apply: la regla se aplica en cada conversación.
• Apply Intelligently: el propio agente decide cuándo es relevante.
• Apply to Specific Files: coincidencia con un patrón de archivos (por ejemplo, *.tsx).
• Apply Manually: solo cuando se menciona explícitamente en el chat.

Flujo de trabajo: Cursor CLI y agentes en la nube

Cursor CLI ofrece los mismos modos que el editor pero desde terminal: modo Agent (ejecuta directamente), modo Plan (diseña un enfoque antes de tocar código) y modo Ask (explora y responde sin editar nada) — una forma segura de pedirle primero que investigue antes de dejarle escribir. Los agentes en la nube, por su parte, clonan el repositorio (GitHub, GitLab, Azure DevOps o Bitbucket Cloud), trabajan en una rama separada y devuelven los cambios para revisión — se pueden lanzar desde el propio editor, la web, la app de iOS, Slack, GitHub, Bitbucket o Linear.

Todo lo que trae Cursor, aparte del autocompletado

• Tab: autocompletado multi-línea que predice a partir del archivo, el contexto del proyecto y ediciones recientes, con salto automático al siguiente punto que necesita el mismo cambio tras aceptar una sugerencia (útil en renombrados repetitivos).
• Agent: lee y escribe en varios archivos, ejecuta comandos de terminal y corrige errores por su cuenta, con puntos de control para revertir cambios.
• Cursor Rules: convenciones del proyecto en archivos .mdc, con distintos modos de aplicación.
• Cursor CLI: los mismos modos de trabajo (Agent, Plan, Ask) desde la terminal, con detección automática de servidores MCP.
• Agentes en la nube: tareas en un entorno remoto y aislado, lanzables desde el editor, la web, iOS, Slack, GitHub, Bitbucket o Linear.
• Bugbot: revisión de código automatizada en cada pull request, ahora con facturación por uso en vez de una cuota fija mensual.
• Acceso a modelos de varios proveedores (OpenAI, Anthropic, Google, xAI y el modelo propio Composer), eligiendo el equilibrio entre inteligencia, velocidad y coste según la tarea.
• Modo de privacidad, disponible incluso en el plan gratuito.

Qué modelo elegir dentro de Cursor

Lo que cuesta Cursor, plan por plan

Planes de cursor.com/es/pricing el 16 de octubre de 2026, en dólares sin impuestos: Gratis 0 $; Plus 8 $ (solo modelos de Grok); Premium 30 $ (4 veces el uso de Plus, con agentes en la nube, Origin, Bugbot y modelos de terceros a precio de catálogo); Super 100 $ (15 veces); Ultra 200 $ (50 veces); Teams desde 30 $ por usuario y mes; y Empresas a medida. Los planes anteriores Hobby, Pro y Pro+ ya no aparecen. Los planes incluyen funciones de X y de Grok, y los modelos de terceros se facturan aparte según el uso. Las respuestas de las preguntas frecuentes de precios están plegadas y no se citan: la fuente fiable siempre es cursor.com/pricing.

Encargos reales que le puedes dar a Cursor

Situación: necesitas un componente nuevo (un formulario, un modal) y ya sabes qué pinta debe tener, pero no te apetece escribirlo desde cero. Qué hace Cursor: se lo describes al agente, que crea el archivo, lo conecta con el resto del proyecto y te deja el diff listo. Resultado esperado: un componente funcional que revisas y ajustas en vez de escribir desde una página en blanco. Advertencia: cuanto más concreto el encargo (props exactas, dónde debe vivir el archivo), menos vueltas tendrás que dar después.

Situación: un cambio pequeño en la lógica de negocio hay que reflejarlo en ocho archivos distintos, y hacerlo a mano es tedioso y propenso a error. Qué hace Cursor: el agente aplica el mismo tipo de cambio en los ocho archivos de una vez, respetando las particularidades de cada uno. Resultado esperado: los ocho archivos actualizados, con un único diff que revisar. Advertencia: revisa igual cada archivo — el agente a veces borra y recrea uno entero en vez de editarlo, lo que se carga el historial de git.

Situación: un usuario reporta un error, pero solo te ha dado el síntoma ('el botón no responde'), no la causa. Qué hace Cursor: le describes el síntoma al agente, que busca en el código, encuentra la causa probable y propone una corrección. Resultado esperado: ahorras el tiempo de localizar tú mismo dónde está el problema. Advertencia: para bugs que dependen del entorno (un dispositivo concreto, una condición de red) el agente puede necesitar más contexto del que le diste al principio.

Situación: tienes una función ya escrita, sin ningún test, y sabes que deberías tenerlos antes de tocarla. Qué hace Cursor: le pides que genere pruebas automáticas para esa función, cubriendo los casos normales y los límite. Resultado esperado: una batería de tests que puedes ejecutar antes de cualquier cambio futuro. Advertencia: revisa que los tests comprueben el comportamiento correcto, no solo lo que la función hace ahora mismo — que podría ya ser un bug.

Situación: quieres lanzar una tarea larga (un refactor grande) sin dejar de trabajar en otra cosa en tu máquina. Qué hace Cursor: envías la tarea a un agente en la nube, que clona el repositorio, trabaja en una rama aparte y avisa cuando termina. Resultado esperado: sigues trabajando en local mientras el refactor avanza en paralelo. Advertencia: revisa la rama que te devuelve con la misma atención que revisarías un pull request de un compañero, antes de fusionarla.

Cómo la gente se lía al delegarle trabajo a Cursor

• Encargos vagos: la causa más citada de resultados pobres es no especificar objetivo, alcance y criterio de éxito con claridad.
• Aceptar diffs multi-archivo sin revisar: el agente puede tocar algo fuera del alcance pedido, o borrar y recrear un archivo en vez de editarlo, perdiendo el historial de git.
• No tener en cuenta el coste de los modelos de frontera: usar manualmente un modelo caro consume la cuota de uso incluida del plan más rápido que dejar la selección de modelo en automático.
• Ignorar .cursorignore en repositorios grandes: sin ajustarlo, el indexado tarda más y la recuperación de contexto trae más ruido irrelevante.
• Confundir qué modelo usar para qué: hay varios hilos de la propia comunidad de Cursor preguntando explícitamente cuándo usar el modelo propio frente a uno de frontera — es una confusión real, no hipotética.
• Asumir cobertura total del repositorio: incluso con ventanas de contexto grandes, un monorepo real puede tener muchísimos más tokens de los que caben de una vez — Cursor depende de recuperación (embeddings + búsqueda), que puede fallar en refactors que cruzan varios servicios.

Lo que Cursor no hace (o no hace bien) por ahora

• El uso de los modelos de terceros se factura aparte según el consumo, más allá de lo incluido en cada plan.
• No tiene acceso directo al Marketplace oficial de extensiones de Microsoft; usa el registro Open VSX, por lo que alguna extensión concreta puede no estar disponible.
• Delegar tareas a un agente que edita varios archivos exige revisar los cambios con atención, sobre todo en código en producción.
• El cambio de propiedad hacia SpaceX es reciente y no se ha encontrado una declaración pública propia de Cursor sobre su impacto en el tratamiento de datos — un punto a vigilar para compradores de nivel Empresas.