Cursor pasó de ser una curiosidad entre developers a convertirse en el editor por defecto de muchos equipos. Pero la diferencia entre quien duplica su velocidad y quien lo usa como un autocompletado glorificado no está en la herramienta: está en la configuración y en la forma de pedirle las cosas. Esta guía cubre las dos.

El contexto de por qué vale la pena aprenderlo bien: Cursor llegó a mil millones de dólares de ingresos recurrentes anuales en tres años y superó el millón de usuarios. Con el lanzamiento de Cursor 2.0 la herramienta pasó a una interfaz centrada en agentes más que en archivos, y sumó su propio modelo de código, Composer, diseñado para completar la mayoría de los turnos en menos de treinta segundos.

Instalación y primeros cinco minutos

Cursor es un fork de VS Code, así que la migración es directa: al abrirlo por primera vez importa extensiones, temas y atajos de teclado. Si venís de VS Code, no perdés nada.

Lo que sí conviene hacer antes de escribir la primera línea:

1. Indexar el proyecto. Cursor construye un índice del codebase; sin esto, las respuestas ignoran tu arquitectura.

2. Configurar los modelos. Definí qué modelo usar para tareas rápidas y cuál para razonamiento complejo. Usar el modelo más potente para todo desperdicia cuota y suma latencia sin necesidad.

3. Crear el archivo de reglas del proyecto. Es el paso que más impacto tiene y el que más gente saltea.

El archivo de reglas: el 80% del resultado

Las reglas del proyecto son instrucciones permanentes que Cursor aplica en cada interacción. Sin ellas, repetís el mismo contexto en cada prompt y el modelo genera código que no respeta las convenciones del equipo.

Qué conviene incluir:

• Stack y versiones. Framework, versión del lenguaje, gestor de paquetes.

• Convenciones de código. Nombres, estructura de carpetas, patrón de manejo de errores.

• Lo que está prohibido. "No usar librerías nuevas sin pedir", "no modificar archivos de migración", "no usar any en TypeScript". Las prohibiciones explícitas evitan la mayoría de los problemas.

• Estilo de tests. Framework, ubicación de los archivos, nivel de cobertura esperado.

Una regla práctica: cada vez que corrijas al modelo dos veces por lo mismo, esa corrección va al archivo de reglas.

Los cuatro modos y cuándo usar cada uno

Tab (autocompletado predictivo)

Predice ediciones múltiples, no solo la línea siguiente. Es el modo de mayor uso diario y el que menos se piensa. Rinde mejor cuando el archivo ya tiene contexto: escribí primero la firma y el nombre descriptivo, y dejá que complete el cuerpo.

Inline edit (edición en el archivo)

Seleccionás código y pedís un cambio puntual. Es el modo ideal para refactorings acotados: extraer una función, cambiar un patrón, agregar manejo de errores.

Chat con contexto

Para entender código ajeno, planificar antes de escribir y discutir alternativas. Se potencia con referencias explícitas a archivos, carpetas o documentación externa.

Agent y Composer (multi-archivo)

Es donde está la ganancia real de velocidad. El agente ejecuta tareas de varios pasos y toca varios archivos: crea el endpoint, el modelo, la validación y el test. Composer trabaja edición multi-archivo a escala y permite correr varios agentes en paralelo sobre el mismo proyecto con espacios de trabajo aislados, lo que lo vuelve especialmente útil para refactorings grandes.

Regla de uso: el agente rinde en tareas bien delimitadas con criterio de éxito claro. En tareas ambiguas genera mucho código plausible y difícil de revisar.

Prompts que funcionan en Cursor

La diferencia entre un prompt malo y uno bueno se mide en minutos de revisión ahorrados.

Débil: "agregá autenticación".

Bueno: "Agregá autenticación con JWT en el módulo de usuarios siguiendo el patrón de @src/modules/orders. Middleware de verificación, refresh token con expiración de 7 días, y tests para token válido, expirado e inválido. No agregues librerías nuevas: usá las que ya están en package.json."

Cuatro técnicas que rinden

1. Referenciá un archivo modelo. "Seguí el patrón de X" es la instrucción más eficiente que existe: transmite decenas de convenciones en cinco palabras.

2. Pedí el plan antes del código. En tareas grandes, pedir primero los pasos permite corregir el enfoque antes de generar 400 líneas equivocadas.

3. Definí el criterio de terminado. "Terminado significa: tests pasando, sin warnings de tipo, y sin cambios en la API pública."

4. Trabajá en commits chicos. Un cambio del agente por commit. Si algo sale mal, el rollback es trivial.

Cursor vs. GitHub Copilot: comparación honesta

Cuándo conviene cada uno. Si tu trabajo son refactorings grandes, features que cruzan varios archivos y exploración de código ajeno, Cursor gana con claridad. Si tu equipo está muy atado al ecosistema de GitHub, o si no querés cambiar de editor, Copilot es la opción de menor fricción. Si querés el desglose completo, existe una comparativa entre Claude Code, Cursor y GitHub Copilot que cubre también el escenario de terminal.

Cuatro errores que anulan la ganancia de velocidad

1. Aceptar sin leer. El código generado puede compilar y estar conceptualmente mal. La revisión es parte del flujo, no un paso opcional.

2. No configurar reglas. Sin reglas, el modelo inventa convenciones y generás deuda técnica más rápido de lo que generás features.

3. Usar el agente para todo. Para cambiar tres líneas, el inline edit es más rápido y mucho más fácil de revisar.

4. Delegar el diseño. La herramienta acelera la implementación. Decidir la arquitectura sigue siendo trabajo tuyo, y es lo que define si el proyecto escala.

Si querés arrancar por lo básico antes de meterte en agentes, conviene leer qué es Cursor AI y cómo empezar a usarlo, que cubre la puesta a punto inicial en detalle.

Cursos recomendados de Coderhouse

• Si te falta base de programación: el Curso de JavaScript y el Curso de Python son el prerrequisito real. Un asistente de IA multiplica lo que sabés; no lo reemplaza.

• Si querés el perfil de desarrollo completo: la Carrera de Desarrollo Full Stack y la Diplomatura Full Stack cubren el recorrido de punta a punta.

• Si querés construir con IA y no solo programar más rápido: el Curso de AI Engineering te lleva del uso de asistentes a la construcción de productos con modelos.

Preguntas frecuentes

¿Cursor sirve si recién empiezo a programar?

Sirve, con un cuidado importante: aceptar código que no entendés frena el aprendizaje. La recomendación para perfiles iniciales es usar Tab y Chat para entender, y evitar el agente hasta poder revisar con criterio lo que genera.

¿Cuánta velocidad se gana realmente?

Los reportes de usuarios hablan de mejoras cercanas al 40% en productividad, y hasta 3x en refactorings complejos con Composer. La variable que más explica la diferencia entre usuarios no es el plan contratado: es tener reglas de proyecto bien configuradas y el hábito de prompts específicos.

¿Cursor o GitHub Copilot?

Cursor es mejor en contexto de proyecto y trabajo multi-archivo. Copilot es mejor si no querés cambiar de editor y tu equipo vive en el ecosistema de GitHub. Muchos developers usan Cursor como editor principal y mantienen Copilot en otros entornos.

¿Es seguro usarlo con código privado?

Cursor ofrece un modo de privacidad donde el código no se almacena ni se usa para entrenamiento, y hay planes empresariales con controles adicionales. Antes de usarlo en un repositorio corporativo, conviene revisar la política y confirmar con el equipo de seguridad.

¿El agente puede romper mi proyecto?

Puede introducir cambios amplios difíciles de revisar. Las tres protecciones que funcionan: trabajar siempre en una rama, hacer commits chicos por tarea, y tener tests que corran rápido. Con eso, el peor caso es un rollback de dos minutos.