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 de shell, edita archivos y debe verificar su trabajo contra tests y linters en los que ya confías.
La postura por defecto que funciona es automatizar 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 vez de una procesión de entregas. Este artículo es la rampa de entrada a ese bucle.
El bucle, no el chat
Cursor Agent (impulsado por Composer) ejecuta decenas de turnos por tarea: grep, leer, editar, terminal, repetir. Cada acción cambia el entorno antes de la siguiente decisión. Eso es toma de decisiones secuencial desde la silla del desarrollador. El lado de entrenamiento del mismo bucle está en Aprendizaje por refuerzo para llamadas a herramientas en modelos agente.
El modo de fallo es un prompt vago y esperanza. El modo de éxito es una unidad de trabajo acotada — un bug, un endpoint, un refactor — que cabe en una sesión y termina con una señal inequívoca: tests en verde, build que 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 @ deben resolver a archivos reales. Añade un .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 las reglas cada sesión. AGENTS.md es la fuente canónica para comandos de build, pasos de test y límites. Un adaptador de una línea en .cursor/rules o CLAUDE.md gana a una segunda novela de instrucciones.
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 a un segundo revisor de modelo de lenguaje en la misma unidad de trabajo.
Opcional pero de alto apalancamiento: conecta un servidor MCP para algo que haces a diario — issue tracker, base de datos de solo lectura, API interna. Empieza con una integración. Amplía cuando el patrón sea aburrido.
Menos herramientas, con más señal, ganan a decenas de definiciones sueltas. Ese diseño está en 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. Carecen de memoria episódica humana.
La mecánica del repo vive en AGENTS.md en la raíz, con archivos anidados en paquetes de monorepo. El archivo más cercano gana.
Los hechos duraderos — personas, ventures, voz, gobernanza — pertenecen a una base de conocimiento privada, no a resúmenes de chat. Ese patrón está en Organizar conocimiento para agentes de IA.
La verdad de marketing pública permanece en fuentes de copy aprobadas antes de que cambie el sitio.
Las Skills de Cursor y las reglas de proyecto automatizan qué instrucciones se cargan para un tipo de tarea — flujos de email, deploys en la nube, gotchas de un framework — sin pegar el mismo preámbulo en cada prompt. Empaqueta flujos repetibles. Mantén AGENTS.md como la única fuente de verdad para los comandos del repo.
Automatiza la verificación (tu mejor crítico no es otro LLM)
Los tests ganan a los linters, que ganan a los typecheckers, que ganan a «¿se ve bien?». Pide al agente que ejecute la verificación, no que la simule. Los logs de CI, los hooks de pre-commit y los scripts locales son automatización que ya tienes. Cursor debería invocarlos.
Cuando la salida de los tests permanece en la misma sesión, el bucle de herramientas es el paso de crítica. Una aserción que falla es una señal inequívoca. Un segundo agente que resume el plan del primero es una entrega con pérdida. Esa es la cara práctica de Mantén el hilo.
Integra la verificación en AGENTS.md de forma explícita. «Ejecuta pnpm test antes de cada commit». «Los tests de integración necesitan Docker primero». Los agentes ejecutan los comandos listados cuando es relevante. Si lo documentas, espera que se ejecute.
Automatiza la ejecución (terminal, scripts, MCP, agentes asíncronos)
Documenta comandos de terminal seguros en AGENTS.md. Builds, suites de test, scripts de regeneración de locales, migraciones de base de datos — si un humano lo ejecuta de forma rutinaria, el agente también debería, dentro de los límites que fijes.
Expón sistemas externos como herramientas MCP en vez de pegar respuestas de API en el chat. Prefiere patrones search-and-execute cuando la superficie upstream es grande. Mantén los resultados intermedios fuera del contexto.
Background y Cloud Agents son para unidades asíncronas acotadas: arreglar CI en una rama, regenerar HTML localizado desde un catálogo, actualizar copy desde un archivo fuente aprobado. Dales reglas git claras — nombres de rama, política de push, sin secretos. El artefacto de entrega es el diff y el estado de CI, no un resumen en prosa. Revisa antes del merge. Automatiza todo hasta la decisión de merge.
Los pasos de regeneración pertenecen a scripts, no a la memoria muscular. Si tu sitio se construye desde un JSON de catálogo, documenta python3 website/scripts/build_locales.py (o tu equivalente) en AGENTS.md para que los agentes ejecuten el mismo pipeline que tú.
Modos de Cursor — cuándo usar cada uno
Tab y el completado inline son para ediciones locales, renombres y refactors pequeños. Tú diriges. La automatización es parcial. Esa es la velocidad correcta dentro de un archivo que ya entiendes.
El modo Agent, impulsado por Composer, es para features multi-archivo, depuración con bucle de tests y refactors de todo el repo. Tiene acceso completo a herramientas y terminal. Aquí es donde automatizar el bucle rinde: deja que el agente ejecute comandos e itere hasta que la verificación pase.
Ask, o solo lectura, es para explorar sin ejecución. Aprende un codebase desconocido antes de conceder acceso de escritura.
Background y Cloud Agents son para unidades asíncronas con un artefacto git. Automatiza el trabajo. Conserva el juicio humano en el merge. Emparéjalos con barreras en AGENTS.md: qué puede cambiar de forma autónoma y qué requiere preguntar primero.
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: «preguntar antes de cambiar CI», «nunca commitear .env».
Las bifurcaciones arquitectónicas necesitan juicio humano. El agente propone. Tú decides cuando el trade-off es a nivel de producto, no un fix de linter.
El modo YOLO — aceptar automáticamente cada edición — es para ramas desechables y experimentos, no tu default en main. La automatización debe producir artefactos verificables. La aprobación sigue siendo humana para acciones irreversibles.
Checklist de la primera semana
Semana 1 — configuración de Cursor y auditoría de automatizarlo-todo
Week 1 — Cursor setup
□ AGENTS.md at repo root (build, test, boundaries)
□ .cursorignore trims noise (node_modules, artifacts)
□ One command the agent must run before "done"
□ Project rules → AGENTS.md (no duplicate novels)
□ Optional: one MCP for a daily external system
□ First work unit: one bug or one file, tests green
□ Durable facts moved out of chat into the repo or a private knowledge base
Automate-everything audit (monthly)
□ Repeated chat instruction → rule or AGENTS.md line?
□ Repeated manual command → script + documented in AGENTS.md?
□ Repeated API call → MCP tool?
□ Repeated multi-step fix → Background Agent brief template?Resumen
Cursor recompensa a los equipos que tratan el IDE como un plano de control. El contexto vive en archivos. La verificación vive en tests. La ejecución vive en scripts y herramientas. El juicio vive 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 — no en volver a teclear comandos que ya documentaste.
Lee la serie Arquitectura de agentes en orden: este primer artículo, luego AGENTS.md, la organización de conocimiento privado, el diseño MCP, la especialización RL de Composer y los bucles de un solo agente. 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 material de referencia vivo, no como una instantánea congelada de los hacks de prompt del año pasado.