Modo Agent de Cursor en la práctica: 10 trucos que tardé tres meses en dominar

Mirando el quinto archivo erróneo que Agent acaba de generar. Tercera refactorización de esta función esta noche. Empiezo a dudar: este modo Agent que promete completar tareas complejas de forma automática, ¿viene a ayudar o a torturar?

Hace tres meses, la primera vez que vi el interruptor del modo Agent en Cursor, me emocioné como si hubiera descubierto un continente nuevo. La fantasía era bonita: le cuentas a la IA lo que necesitas y ella crea archivos, instala dependencias, escribe código y corrige bugs mientras tú te tomas un café. La realidad es más áspera: sí trabaja sola, pero a menudo lo hace para estropearlo todo.

Tras tres meses de prueba y error, la relación con Agent pasó de amor-odio a colaboración fluida. Ahora es mi asistente más fiable, siempre que sepas cómo manejarlo. Este artículo recoge los tropiezos y las lecciones de ese tiempo.

Qué es el modo Agent: entiende primero la diferencia con el Chat normal

Abres Composer en Cursor y verás un interruptor Agent arriba a la derecha. No lo subestimes: activarlo es como darle manos y pies a la IA.

En modo normal, la IA solo te sugiere: te dice que deberías añadir una función aquí o que el bug puede deberse a…, y tú actúas a mano. En modo Agent, se pone a trabajar: crea archivos, modifica código, instala paquetes npm y ejecuta comandos de un tirón.

Suena genial, ¿verdad? Ahí está también el problema. Imagina que mandas a un becario a tocar código: lo hace, pero al revisar descubres que también cambió otros archivos y alteró la lógica central. Agent es ese becario aplicado pero poco fiable.

Por eso ahora uso Chat para tareas pequeñas (por ejemplo, explícame este código) y Agent para operaciones en varios archivos (por ejemplo, añade tipos TypeScript a todos los componentes). La clave es saber cuándo soltar la rienda y cuándo vigilar de cerca.

Truco 1: el arte de dividir tareas — no dejes que Agent se atragante

Mi mayor error fue lanzarle a Agent una tarea enorme de una sola vez.

Quería refactorizar un proyecto antiguo y le dije: ayúdame a migrar de JavaScript a TypeScript, optimiza el rendimiento y añade login. Empezó a crear archivos a lo loco; al terminar, el proyecto ni arrancaba. Me llevé un día entero revirtiendo código.

Aprendí la lección. Ahora lo divido así:

1. Primera ronda: añade tipos TypeScript a los archivos de src/components
2. Segunda ronda: define los tipos de src/utils
3. Tercera ronda: configura tsconfig.json para que compile bien

Tras cada paso ejecuto los tests y, si todo va bien, sigo. Si algo falla, localizo rápido en qué paso ocurrió.

Un truco: al dividir, intenta que cada tarea afecte como máximo a 3-5 archivos. Por encima de eso, Agent pierde el foco. No mandarías a un becario a tocar 20 archivos de golpe, ¿no? Misma lógica.

Truco 2: gestión del contexto — dile a Agent qué debe mirar

Agent tiene un defecto: no sabe qué archivos importan y cuáles ignorar. Tu proyecto puede tener miles de archivos; node_modules ocupa una buena parte. Si los escanea todos, va lentísimo y se distrae fácilmente.

Antes de cada tarea con Agent hago dos cosas:

Paso 1: configurar .cursorignore

Este archivo indica a Cursor qué directorios no indexar. Mi plantilla:

node_modules/
dist/
build/
.next/
.git/
*.log
coverage/

Con esto, la respuesta de Agent puede ser un 30% más rápida o más. No parece mucho, pero en un día suma.

Alibaba Cloud - Opción preferida para desarrolladores, 15 % de descuento exclusivo en Lighthouse

Obtener 15% dto. →Anuncio

Paso 2: referencias precisas con @

Cuando quiero que modifique archivos concretos, uso @nombreArchivo para fijar el contexto. Por ejemplo: siguiendo el patrón de @api.ts, añade manejo de errores también en @user.ts. Así no va revolviendo archivos a ciegas.

Una vez olvidé el @ y dije solo sigue el patrón del archivo API. Encontró uno viejo de hace dos años y aplicó un patrón obsoleto. Qué experiencia.

Truco 3: el control de versiones es tu salvavidas

Esta lección me costó lágrimas.

Un viernes por la tarde pedí a Agent que refactorizara un módulo y me fui a una reunión. Al volver, había tocado más de 30 archivos. Pensé: qué eficiencia. Por la noche, en pruebas, el login estaba roto.

El problema: no recordaba qué había cambiado.

Esa noche comparé archivo por archivo durante tres horas hasta localizar el fallo. Desde entonces tengo una regla de hierro: antes de usar Agent, commit obligatorio.

Mi flujo ahora:

# Commit antes de empezar
git add .
git commit -m "Copia de seguridad antes de usar Agent"

# Luego dejas que Agent trabaje

# Al terminar, revisa los cambios
git diff

Si Agent se equivoca, git reset —hard y empiezas de nuevo. Me ha salvado muchísimas veces.

Otro detalle: que Agent cambie solo un módulo funcional y commit justo después. Si algo falla, revertir cuesta poco. Como guardar a menudo en un juego.

Truco 4: aprende a decir basta — cuando Agent falla, no dejes que siga cavando

Agent, una vez en marcha, corre hasta el final. Si hay un error en el camino, sigue igual y el desastre crece.

Lo peor que vi: no encontraba una dependencia, inventó una falsa y siguió escribiendo código sobre ella. Cuando me di cuenta, ya había modificado una docena de archivos con esa premisa errónea.

Ahora superviso. Cuando Agent trabaja, miro los logs:

• ¿Error en rojo? ESC al instante
• ¿Archivo raro creado? Para
• ¿Tocó lógica central que no debía? Corta

Tras parar, reviso qué hizo:

• Si va bien, conservo esa parte y ajusto las instrucciones
• Si ya se desvió, git reset y nuevas instrucciones

No te cortes por interrumpirlo. Agent no es una persona; no se ofende. Si dejas que implemente toda la lógica errónea, limpiar después cuesta mucho más.

Truco 5: nunca confíes ciegamente en el código de Agent

La calidad del código que genera es como una caja sorpresa: a veces te alegra, a veces te asusta.

Al principio pensaba: si la IA es tan lista, el código estará bien. Dos caídas en entorno de pruebas me enseñaron que la revisión no se negocia.

Tras cada tarea de Agent hago esto:

Paso 1: ejecutar tests

npm test

Básico, pero muchos lo olvidan. Agent no corre los tests por ti; escribe y da la tarea por cerrada.

Paso 2: lista de revisión

• ✓ Corrección lógica: ¿hace lo que debe?
• ✓ Casos límite: ¿null, excepciones, vacíos?
• ✓ Rendimiento: ¿cuellos de botella obvios?
• ✓ Estilo: ¿encaja con el proyecto?
• ✓ Seguridad: ¿SQL injection, XSS?

Paso 3: ¿tomó atajos?
Agent tiende a ir por la vía rápida. Si pides optimizar consultas a base de datos, puede que solo añada caché sin tocar el SQL. Mira qué cambió de verdad.

Una vez dejó una lógica compleja en // TODO: pendiente de implementar. Listo, me dejó el agujero.

Truco 6: cómo usar Agent bien en proyectos grandes

En proyectos pequeños, Agent es casi trampa. En grandes —cientos de archivos, dependencias enredadas, estilos de varios desarrolladores— se pierde fácil.

Tengo un proyecto Next.js con más de 200 componentes. Al principio le pedí optimizar el rendimiento de todos los componentes. Tardó diez minutos solo buscando archivos, tocó cosas irrelevantes y no llegó a los componentes críticos.

Railway - Plataforma de despliegue moderna, sin ops complejas, en producción en minutos

Empezar ahora →Anuncio

Con el tiempo armé un enfoque para proyectos grandes:

Estrategia 1: por módulos
No enfrentes a Agent con todo el repo; delimita:

• Solo archivos en src/components/auth
• Solo código relacionado con el login

Así concentra la atención y no se distrae con ruido.

Estrategia 2: .cursorrules como frontera
En la raíz del proyecto, un archivo .cursorrules con las reglas:

# Reglas del proyecto
- Todos los componentes deben usar TypeScript
- Las llamadas API usan @/lib/api
- No modificar la lógica core en @/lib/core
- Los archivos nuevos deben incluir comentarios JSDoc

No garantiza obediencia total, pero da un marco, como un manual para el becario.

Estrategia 3: módulos independientes primero
Utilidades y componentes genéricos, poco acoplados, son terreno ideal: si algo sale mal, el impacto es acotado; si sale bien, beneficia a todo el proyecto.

Truco 7: la dupla Agent y Composer

Mucha gente no aclara la relación. En la práctica se complementan; no es uno u otro.

En resumen: Composer es el taller; Agent es el interruptor de automatización.

Escenario 1: refactor en varios archivos = Composer + Agent ON
Cambios coordinados en muchos archivos, por ejemplo añadir manejo de errores y reintentos a todas las llamadas API. Agent brilla aquí.

Escenario 2: cambio profundo en un archivo = Composer + Agent OFF
Si solo retocas la lógica de un componente, apago Agent y uso Composer normal: la IA sugiere y yo aplico paso a paso.

Escenario 3: consulta rápida = Chat
Para qué significa este error o cómo optimizar este fragmento, Chat basta; abrir Composer sobra.

Puedes alternar Agent en Composer: empiezas con él activo y, si algo huele mal, lo apagas y tomas el control. Flexibilidad, no camino único.

Truco 8: trampas que conviene evitar

Tras tanto uso, estas son las más habituales. No digo que nunca las hagas, pero piénsalo dos veces.

Trampa 1: que Agent toque la base de datos directamente
Una vez pedí limpiar registros duplicados en la base de pruebas. También borró datos de producción. En .env tenía la conexión de prod; no cambia de entorno solo.

Lección: operaciones de BD a mano, o con backup antes.

Trampa 2: cambiar un patrón en todos los archivos de golpe
Cambiar var por let en todos suena simple, pero Agent puede tocar var en comentarios, strings e incluso librerías de terceros. El código corre, pero el diff es un caos.

Mejor: un directorio, revisar, luego ampliar.

Trampa 3: soltar a Agent en un proyecto sin tests
Refactoricé un proyecto legacy sin tests. En local se veía bien; en producción cayeron tres funciones. Sin red de tests, no sabes qué rompió Agent.

O escribes tests primero, o avanzas en pasos pequeños con verificación manual.

Trampa 4: depender demasiado de Agent
La trampa mental: con el tiempo tu primer reflejo es pedírselo todo a Agent. Algunas cosas hay que pensarlas tú. He visto gente que hasta nombra variables con Agent. Demasiado.

Agent es herramienta, no niñera. Acelera, no sustituye el pensamiento.

Truco 9: trucos para que Agent vaya más rápido

A veces tarda una eternidad en cambiar pocos archivos. Hay formas de aligerarlo.

Vultr - Servidor cloud NVMe de alto rendimiento, 32 ubicaciones globales, despliegue Docker con un clic

Ver precios →Anuncio

Truco 1: reducir el índice
.cursorignore es la base. También puedes acotar el índice del Codebase en ajustes: suelo indexar solo src/ y lib/, no documentación ni configs sueltas.

Truco 2: limpiar el historial del chat
Agent usa el contexto previo. Conversaciones largas ralentizan cada turno. Tras una tarea grande, abro chat nuevo. Como vaciar el carrito.

Truco 3: modelos más rápidos
Cursor suele usar GPT-4: calidad alta, más lento. Para tareas simples (renombrado en lote, formateo), Claude Sonnet o GPT-3.5 pueden ir el doble de rápido.

Mi regla: lógica compleja con GPT-4; tareas mecánicas con modelos rápidos.

Truco 4: lotes en lugar de todo de una vez
100 archivos con comentarios nuevos: no los hagas en una sola orden. Cinco tandas de 20, con revisión entre medias. Detectas errores antes y el contexto de cada tanda es menor.

En resumen, Agent también necesita optimización. No harías un SELECT sin índice en toda la tabla; aligera su carga y corre mejor.

Truco 10: mi checklist antes de usar Agent

Después de tanto uso, repaso esto antes de activar Agent:

Antes de empezar:

• ✓ Git commiteado, working tree limpio
• ✓ .cursorignore configurado
• ✓ Alcance claro (qué archivos toca)
• ✓ Rama correcta (no cambios directos en main)
• ✓ Entorno de pruebas listo

Durante la ejecución:

• ✓ Vigilar logs; parar ante anomalías
• ✓ Observar cambios de archivos; evitar tocar core por error
• ✓ Si se desvía, ESC
• ✓ Tareas complejas por pasos, sin codicia

Al terminar:

• ✓ git diff en todos los cambios
• ✓ Tests (npm test)
• ✓ Revisión (lógica, rendimiento, seguridad)
• ✓ Commit solo tras pruebas locales OK
• ✓ Limpiar historial de chat innecesario

Parece pesado, pero evita accidentes. Como la checklist de un piloto antes del despegue.

La regla de oro: nunca mandes a Agent un cambio grande un viernes por la tarde. Aprendido a las duras: arreglar bugs el fin de semana no mola.

Conclusión

Volviendo a las dos de la madrugada del principio: ya no dejo que Agent genere cinco archivos erróneos seguidos. Sé cuándo soltar y cuándo parar; cómo dividir y delimitar; y que Agent no es magia, sino una herramienta que hay que dominar.

Tres meses de prueba por diez trucos. El modo Agent puede duplicar la productividad, si aprendes a convivir con él. Es como un becario con mucha energía y poca experiencia: con buenas instrucciones hace mucho; sin supervisión, puede dejar el proyecto hecho un lío.

Mi consejo: no tengas miedo de equivocarte, pero ten siempre forma de revertir. Empieza con tareas pequeñas y gana confianza. Cuando os entendáis, verás que es un aliado de verdad.

Una actitud final: Agent amplía tu capacidad, no sustituye tu capacidad de pensar. Antes de delegar, piensa tú la solución. Con eso no quedarás atado a la herramienta.

Si acabas de empezar con Cursor Agent, configura Git primero. No es broma: poder revertir te da valor para experimentar.

Que te vaya bien con Agent. Si tienes trucos o historias de tropiezos, compártelos en comentarios; entre todos evitamos más pozos que solos.