Llevo meses usando Cursor como editor principal para mis proyectos, incluida la app de pesca que tengo en desarrollo (Caladero) y otros experimentos personales. La pregunta que más me hacen no es "¿funciona bien?" sino "¿no te da miedo no entender lo que escribe la IA?". Es una pregunta razonable, y la respuesta corta es: sí me daría miedo si lo dejara escribir sin revisar. Por eso tengo un flujo de trabajo concreto para no perder el hilo de mi propio código.

Por qué elegí Cursor y no otra cosa

No voy a hacer publicidad gratuita. Elegí Cursor porque es un fork de VS Code, así que no tuve que aprender un editor nuevo desde cero, y porque el autocompletado y el chat integrado funcionan sobre el contexto real del proyecto, no solo sobre el archivo abierto. Eso importa cuando trabajas con una base de código que ya tiene cierta arquitectura: modelos de datos, capas de repositorio, convenciones de nombres. Un asistente que solo ve el archivo actual tiende a proponer soluciones que rompen esas convenciones sin darse cuenta.

Dicho esto, el editor no es lo importante. Lo importante es el proceso que uno construye alrededor de la herramienta.

Mi regla número uno: nunca acepto un cambio que no entiendo

Esto suena obvio pero es fácil de romper cuando llevas tres horas seguidas programando y la IA te ofrece una solución que "parece" funcionar. Mi regla es simple: si no puedo explicar en voz alta qué hace cada línea del diff que me proponen, no lo acepto. Lo pido reescrito, lo pido comentado, o lo reviso yo mismo hasta entenderlo.

En la práctica esto se traduce en tres pasos que repito casi siempre:

  1. Pido cambios pequeños y acotados, nunca "reescribe todo el módulo".
  2. Reviso el diff completo antes de aplicarlo, no solo el resultado final en pantalla.
  3. Ejecuto o pruebo el cambio inmediatamente después, no acumulo varios cambios sin verificar.

Un ejemplo práctico: añadir una función de exportación

Hace poco necesitaba añadir una función que exportara los puntos guardados de un usuario a un archivo local en formato GeoJSON, dentro del proyecto de la app de pesca que sigo desarrollando. Podría haberle pedido a Cursor "añade exportación a GeoJSON" y dejar que resolviera todo. En vez de eso, el proceso fue este:

Primero le pedí que me explicara qué estructura de datos tenía ya el modelo de "punto guardado" en el proyecto, sin tocar nada. Eso me sirvió para confirmar que la IA había entendido bien el contexto antes de escribir código. Después le pedí solo la función de conversión de mi modelo interno al formato GeoJSON, sin tocar la parte de escritura a disco. Revisé esa función a mano: comprobé que las coordenadas se escribían en el orden correcto (longitud, latitud, que es el que exige el estándar GeoJSON y que mucha gente confunde con latitud, longitud). Solo cuando esa parte estaba clara pedí la función que escribe el archivo, y hasta entonces no toqué el flujo de la interfaz.

Ese desglose en pasos pequeños es lo que me permite decir, con sinceridad, que entiendo el código que hay en el proyecto aunque no lo haya tecleado yo letra por letra.

Cómo reviso los cambios antes de aceptarlos

Uso el panel de diferencias de Cursor como si fuera una revisión de pull request de otra persona. No me fío del resumen en lenguaje natural que a veces acompaña al cambio ("he añadido la función X"); leo el código propuesto directamente. Presto atención especial a:

  • Imports nuevos que no esperaba, porque a veces la IA añade una dependencia que no hace falta.
  • Cambios en archivos que no pedí tocar, que Cursor a veces sugiere "de paso".
  • Manejo de errores ausente o genérico, un catch vacío o un try/except demasiado amplio.
  • Nombres de variables o funciones que no siguen la convención que ya tenía el proyecto.

Cuando algo de esto aparece, pido explícitamente que se corrija antes de aplicar el cambio. No es raro que tenga que iterar dos o tres veces sobre una misma petición pequeña.

Errores que cometí al principio

Al principio caí en la trampa de pedir cambios demasiado grandes de golpe, del tipo "migra este módulo a Compose" o "refactoriza toda la capa de red". El resultado eran diffs de cientos de líneas que era imposible revisar con cuidado, así que terminaba aceptándolos casi a ciegas. Eso me generó un par de bugs que tardé más en encontrar que si hubiera escrito el código yo mismo desde el principio.

También aprendí a desconfiar de mi propia atención cuando llevo muchas horas delante de la pantalla. Una vez acepté una sugerencia de Cursor que duplicaba una condición dentro de un if sin darme cuenta, porque estaba revisando el diff en diagonal. El código compilaba y funcionaba en el caso normal, pero fallaba en un caso límite que no formaba parte de mis pruebas manuales. Desde entonces reviso también las condiciones booleanas con más calma, no solo el flujo general del cambio.

Otro límite que le pongo a la herramienta: no le pido que tome decisiones de arquitectura por mí. Puede sugerir alternativas, puede explicarme ventajas y desventajas, pero la decisión de, por ejemplo, si un dato se guarda local o se sincroniza con un backend la tomo yo, normalmente por escrito en un documento corto antes de tocar código (hablo de esto con más detalle en el artículo sobre qué es un ADR).

Dónde sí delego más control

No todo es desconfianza. Hay tareas donde dejo que Cursor trabaje con más autonomía porque el coste de un error es bajo y fácil de detectar: generar tests unitarios a partir de una función ya revisada, escribir documentación de funciones existentes, o proponer nombres alternativos para variables poco claras. En esos casos el riesgo de que algo se rompa de forma silenciosa es mucho menor, y la revisión posterior es rápida.

Conclusión

Usar Cursor no ha cambiado la responsabilidad que tengo sobre mi código, solo ha cambiado cuánto tiempo tardo en escribir la primera versión. La parte de entender, revisar y decidir sigue siendo enteramente mía, y creo que ahí está la diferencia entre usar una IA como herramienta o dejar que sea ella quien decida por ti. Si algo he aprendido programando con asistencia de IA es que ir más rápido solo vale la pena si sigues sabiendo, en todo momento, qué hace cada parte de tu proyecto.