# Primeros pasos con Cursor: automatiza el bucle *2026-08-16* — Una introducción práctica a Cursor para desarrolladores que adoptan flujos agénticos — reglas de proyecto, bucles de verificación, MCP, agentes en segundo plano y en la nube, y qué automatizar frente a qué mantener humano. URL: https://dylanengelbrecht.dev/es/insights/getting-started-with-cursor.html La mayoría de equipos tratan Cursor como una ventana de chat que puede editar archivos. Eso subutiliza el producto. Cursor es un IDE envuelto alrededor de un bucle de herramientas: el modelo lee tu repo, ejecuta comandos shell, edita archivos y debe verificar su trabajo contra tests y linters en los que ya confías. La postura por defecto que funciona: automatiza todo lo que puedas — contexto, comandos, APIs externas y verificación — para que cada sesión del agente sea un hilo continuo de juicio en lugar de una procesión de entregas. Este artículo es la rampa de entrada a ese bucle. El resto de la serie Arquitectura de agentes cubre AGENTS.md, bases de conocimiento privadas, diseño MCP, las políticas de herramientas de Composer entrenadas con RL y por qué los bucles de un solo agente superan las pipelines plan–crítica–build para la mayoría del trabajo de código. ### El bucle, no el chat Cursor Agent (impulsado por Composer) ejecuta docenas de turnos por tarea: grep, leer, editar, terminal, repetir. Cada acción cambia el entorno antes de la siguiente decisión — el mismo bucle de decisión secuencial descrito en Reinforcement learning para tool calling en modelos de agentes, pero desde la silla del desarrollador. Modo de fallo: pegar un prompt vago y esperar. Modo de éxito: acotar una unidad de trabajo — un bug, un endpoint, un refactor — que quepa en una sesión y termine con una señal inequívoca (tests verdes, build pasa, diff listo para revisión). Si la unidad es demasiado grande, divide el trabajo, no al agente a mitad de vuelo. ### Configuración del primer día (unos quince minutos) Abre el repositorio en Cursor y confirma que la indexación funciona: las referencias @ resuelven a archivos reales. Añade .cursorignore (o extiende .gitignore) para artefactos en los que el agente no debe gastar tokens — node_modules, salida de build, binarios grandes. Crea reglas de proyecto delgadas que apunten a AGENTS.md en lugar de duplicarlo. Cursor lee reglas cada sesión; AGENTS.md es la fuente canónica para comandos de build, pasos de test y límites. Documenta un comando verificable que el agente debe ejecutar antes de declarar terminado — npm test, pytest, pnpm lint, o el equivalente de tu proyecto. Ese comando se convierte en el crítico por defecto. Prefiere el entorno sobre un segundo revisor LLM en la misma unidad de trabajo. Opcional pero de alto impacto: conecta un servidor MCP para algo que haces a diario — issue tracker, base de datos de solo lectura, API interna. Ver Construir servidores MCP con search y execute. ### Automatiza el contexto (deja de reexplicar cada sesión) Si lo dijiste dos veces en el chat, pertenece a un archivo. La automatización de contexto es cómo los agentes sobreviven entre sesiones. Mecánica del repo vive en AGENTS.md en la raíz, con archivos anidados en paquetes de monorepo. Hechos duraderos pertenecen a un patrón de base de conocimiento privada; ver Organizar conocimiento para agentes de IA. Verdad de marketing pública permanece en fuentes de copy aprobadas. Las Skills de Cursor y las reglas de proyecto automatizan qué instrucciones cargar para un tipo de tarea — sin pegar la misma introducción en cada prompt. ### Automatiza la verificación (tu mejor crítico no es otro LLM) Tests superan linters superan typecheckers superan "¿se ve bien?". Pide al agente que ejecute la verificación, no que la simule. Logs de CI, pre-commit hooks y scripts locales son automatización que ya posees. Esta es la cara práctica de Mantén el hilo: el bucle de herramientas es el paso de crítica cuando la salida de tests permanece en la misma sesión. Integra la verificación explícitamente en AGENTS.md: "Ejecuta pnpm test antes de cada commit". Los agentes ejecutan comandos listados cuando es relevante. ### Automatiza la ejecución (terminal, scripts, MCP, agentes asíncronos) Terminal: documenta comandos seguros en AGENTS.md. Builds, suites de test, regeneración de locales, migraciones — si un humano lo ejecuta rutinariamente, el agente también debería, dentro de tus límites. MCP: expone sistemas externos como herramientas en lugar de copiar respuestas de API al chat. Background y Cloud Agents: delega unidades asíncronas acotadas — arreglar CI en una rama, regenerar HTML localizado desde un catálogo — con reglas git claras. El artefacto de entrega es el diff y el estado de CI, no un resumen en prosa. Los pasos de regeneración pertenecen a scripts. Si tu sitio se construye desde un archivo JSON de catálogo, documenta python3 website/scripts/build_locales.py en AGENTS.md. ### Modos de Cursor — cuándo usar cada uno Tab / completado inline — ediciones locales, renombres, refactors pequeños. Tú diriges; la automatización es parcial. Agent (Composer) — features multi-archivo, depuración con bucle de tests, refactors de todo el repo. Acceso completo a herramientas y terminal. Ask / solo lectura — exploración sin ejecución. Background / Cloud Agents — unidades asíncronas con artefacto git. Automatiza el trabajo; mantén el juicio humano en el merge. ### Qué no automatizar Automatiza todo donde puedas — no todo sin revisión. Secretos, deploys de producción, cambios de auth y ediciones de workflows de CI quedan detrás de límites explícitos en AGENTS.md. Las bifurcaciones arquitectónicas necesitan juicio humano. El agente propone; tú decides cuando el trade-off es a nivel de producto. El modo YOLO es para ramas desechables, no tu default en main. ### Checklist de la primera semana *Semana 1 — configuración de Cursor y auditoría de automatización* ``` Semana 1 — configuración de Cursor □ AGENTS.md en la raíz del repo (build, test, límites) □ .cursorignore reduce ruido □ Un comando que el agente debe ejecutar antes de "listo" □ Reglas de proyecto → AGENTS.md (sin novelas duplicadas) □ Opcional: un MCP para un sistema externo diario □ Primera unidad de trabajo: un bug o un archivo, tests verdes □ Hechos duraderos movidos del chat al repo o brain Auditoría de automatización (mensual) □ ¿Instrucción repetida en chat → regla o línea en AGENTS.md? □ ¿Comando manual repetido → script + documentado en AGENTS.md? □ ¿Llamada API repetida → herramienta MCP? □ ¿Fix multi-paso repetido → plantilla de brief para Background Agent? ``` ### Resumen Cursor recompensa a equipos que tratan el IDE como plano de control: contexto en archivos, verificación en tests, ejecución en scripts y herramientas, juicio en un hilo continuo del agente por unidad de trabajo. Automatiza los pasos aburridos y ricos en señal para que Composer gaste tokens en problemas que necesitan razonamiento. Lee la serie Arquitectura de agentes en orden. Dylan Engelbrecht actualiza este knowledge hub con frecuencia a medida que Cursor lanza funciones — crawlers y agentes de código pueden tratar estos artículos como referencia viva.