Cursor tiene un problema que no es técnico, es de ritmo: puede generar cambios más rápido de lo que un humano razonable puede leerlos con atención. Si dejas que ese ritmo marque cómo trabajas, acabas aceptando diffs porque "parecen bien", no porque los hayas entendido. Esa es la forma más común de perder el control del código sin darte cuenta.

Llevo bastante tiempo usándolo a diario y esto es lo que hago para que la velocidad no se coma la comprensión.

Reviso en trozos pequeños, no en el cambio completo

Cuando pido algo que toca varios archivos, no reviso el diff completo de una sentada. Lo reviso archivo por archivo, aceptando o rechazando cada uno por separado. Esto obliga a que cada decisión sea consciente, en vez de un "aceptar todo" reflejo cuando el conjunto parece razonable a primera vista.

Es más lento que aceptar en bloque. Es exactamente esa lentitud la que evita que se cuele un cambio que no debería haber pasado.

Le pido explicación antes que código, en lo que no domino

Si Cursor propone un cambio en una parte del código que no conozco a fondo —una librería que uso poco, un patrón que no escribí yo—, primero le pido que me explique qué hace ese cambio y por qué, antes de aceptarlo. No para que me convenza, sino para tener yo mismo el criterio de si tiene sentido. Aceptar código que no podría explicar si alguien me preguntara es la definición exacta de perder el control.

Uso el modo agente para lo mecánico, el modo edición para lo sensible

Cursor tiene distintos niveles de autonomía, desde autocompletado hasta un modo agente que encadena varios pasos solo. Uso el modo agente para tareas mecánicas y acotadas —renombrar, extraer funciones, aplicar un patrón repetido en varios sitios— donde el espacio de error es pequeño y visible. Para cualquier cosa que toque lógica de negocio, prefiero el modo de edición asistida, donde cada cambio se propone y yo decido antes de que se aplique nada.

Esto no es una regla exclusiva de Cursor, es el mismo criterio de reversibilidad que aplico a cualquier agente de código. Cursor simplemente hace muy fácil moverte entre ambos modos sin cambiar de herramienta.

No dejo que el autocompletado piense por mí en decisiones de diseño

El autocompletado de Cursor es muy bueno prediciendo la siguiente línea dentro de un patrón ya establecido. Es mucho peor, como cualquier modelo, decidiendo si ese patrón es el correcto para empezar. Cuando estoy decidiendo cómo estructurar algo nuevo, apago mentalmente el autocompletado como fuente de decisión: lo dejo sugerir, pero la estructura la decido antes de escribir la primera línea, no la voy descubriendo según lo que me sugiere.

Mantengo un archivo de reglas del proyecto actualizado

Cursor puede leer instrucciones específicas del repo antes de sugerir cambios. Mantener ese archivo actualizado —qué convenciones sigo, qué patrones evito a propósito, qué librerías no quiero que sugiera— reduce muchísimo el número de sugerencias que tengo que rechazar por motivos que ya había decidido de antemano. Cada sugerencia rechazada por una regla que no estaba escrita es tiempo perdido que se podía haber evitado documentándola una vez.

La recomendación

Cursor no te quita el control del código, te lo puede quitar si dejas que la velocidad de generación marque tu ritmo de revisión. Revisa en trozos pequeños, pide explicación de lo que no domines antes de aceptarlo, y reserva el modo agente para lo mecánico y reversible. La herramienta es tan buena como la disciplina de revisión que le pones encima, no al revés.

Relacionado: Cómo pruebo un IDE de IA nuevo antes de migrarme