Cómo usar Cursor IA: guía práctica para programar con un agente (2026)

Si buscas "Cursor IA" o "cómo usar Cursor", la pregunta real no es si el editor es inteligente. Es qué superficie usar para cada tarea. Cursor junta tres cosas distintas: autocompletado mientras escribes, un agente que edita y corre comandos, y un historial de checkpoints que no es Git. Mezclarlas es lo que produce diffs imposibles de revisar.

Esta guía es el tutorial de uso. La comparativa de superficies está en Cursor vs Claude Code. El mapa de opciones (CLI, IDE, agente en la nube) está en mejores agentes de código en 2026.

Qué es Cursor, en una frase útil

Cursor es un editor basado en VS Code con dos modos de asistencia documentados:

1. Tab: sugiere código mientras escribes, según ediciones recientes, contexto cercano y errores del linter.
2. Agent: un asistente que busca en el repo, edita archivos, corre la terminal y, si lo permites, abre un navegador.

La documentación de Agent lo describe con tres piezas: instrucciones, herramientas y el modelo que eliges. No es magia. Es un bucle de herramientas con un techo de permisos.

Tab: el modo que deberías usar el 70% del tiempo

Tab no abre un chat. Escribe delante del cursor, en gris. Según la guía oficial de Tab:

• Tab acepta la sugerencia completa.
• Escape o seguir tecleando la rechaza.
• Cmd + flecha derecha (Ctrl en Windows/Linux) acepta palabra por palabra.
• Después de aceptar, Tab otra vez salta al siguiente punto de edición.
• Puede proponer cambios en otros archivos cuando un import o un tipo quedó desfasado.

Úsalo para: completar un handler, cerrar un test, añadir un import, renombrar en el archivo actual.

No lo uses para: "reescribe este módulo", "arregla el CI", "explica el repo". Eso es trabajo de Agent, y si lo metes en Tab vas a aceptar cambios que no leíste.

Agent: cuándo sí y cómo no romper el repo

Abre Agent en el panel lateral (Cmd+I / Ctrl+I). La overview oficial lista las herramientas: buscar archivos, leer, editar, terminal, web, browser, reglas del repo y preguntas de aclaración. No hay un tope fijo de llamadas a herramientas por tarea.

Antes de pegar un prompt largo, decide el objetivo comprobable:

Pedido vago	Pedido que se puede revisar
Mejora este archivo	Extrae la validación de email a src/lib/email.ts y añade 3 tests
Arregla el bug	Reproduce el 500 de /api/subscribe, escribe el test que falla y luego el arreglo
Documenta el proyecto	Crea AGENTS.md con build, test, lint y lo que el agente no debe tocar

Si el repo ya tiene convenciones, no las inventes en el chat. Cárgalas en AGENTS.md para que Cursor, Claude Code y Codex lean las mismas reglas.

Checkpoints no son Git

Agent crea checkpoints locales antes de cambios grandes. Sirven para volver atrás el trabajo del agente. La docs lo dice claro: los checkpoints no reemplazan Git. Restaurar un checkpoint revierte archivos, no borra el hilo del chat.

Regla práctica: un checkpoint es "deshacer al agente". Un commit es "esto ya lo revisé". Si el agente corre git add . o git commit sin que lo pidas, detén la corrida. Añade paths explícitos y vuelve al hub de construcción cuando el trabajo deje de ser un archivo y pase a ser un agente.

Flujo de 45 minutos para tu primer día

No empieces con "construye la app". Empieza con una tarea que ya sabes hacer a mano.

1. Abre un repo real, no un sandbox vacío. El agente necesita archivos, tests y un lockfile.
2. Lee package.json o pyproject.toml tú. Anota el comando de test y el de lint. Si no los conoces, no se los delegues.
3. Prueba Tab 10 minutos. Completa una función que ya habías empezado. Mide si las sugerencias respetan el estilo del archivo.
4. Lanza Agent con un objetivo de un archivo. Ejemplo: "Añade validación de page en src/lib/pagination.ts y un test que rechace page=0."
5. Revisa el diff archivo por archivo. Si no puedes explicar el cambio, no lo commits.
6. Corre tú el test. El agente puede reportar verde y haberte tapado un caso. La verificación es tuya.
7. Haz un commit con paths explícitos. Nunca git add ..

Si tu prioridad no es el IDE sino un agente de terminal mínimo, la ruta Pi.dev cubre instalación, AGENTS.md y modos print/SDK.

Tres errores que se ven en LATAM (y en todos lados)

1. Pedir un feature y un refactor en el mismo hilo. Agent acumula contexto y mezcla responsabilidades. Un hilo = un objetivo. Si surge un cleanup, ábrelo en otro chat o anótalo para después.

2. Dejar que el agente "mejore" nombres y formato. Eso ensucia el diff. Si el repo tiene EditorConfig, dilo. Si no, prohíbelo en el prompt: "no reformatees archivos que no toques".

3. Tratar el modelo como si fuera el producto. Cursor orquesta instrucciones y tools por modelo. Cambiar de modelo a mitad de un refactor largo suele cambiar el estilo del parche. Elige el modelo al inicio. Los precios y límites viven en la página oficial de models and pricing; no copies un tweet con "el mejor modelo".

Checklist de salida

Usa esto antes de mergear algo que escribió Agent:

• El objetivo del hilo cabe en una oración.
• El diff toca solo los paths que pediste.
• Corriste test y lint en tu máquina, no solo en el relato del agente.
• No hay secretos nuevos en el parche (.env, tokens, dumps).
• Hay un commit revisado. El checkpoint quedó como respaldo, no como historial.

Cuándo no usar Cursor

Cursor no gana si tu trabajo es un servidor 24/7, un bot de WhatsApp o un agente con webhook. Ahí necesitas runtime, colas y permisos, no un IDE. Empieza por qué es un agente de IA y, si quieres canales, por la ruta OpenClaw.

Cursor sí gana cuando pasas el día en un repo: completar código, un bug local, un test que falta, un refactor acotado. Si después de 45 minutos no puedes revisar el diff, el problema no es el modelo. Es el tamaño del pedido.