Cursor en la práctica: 6 tareas donde ahorra más tiempo

👁 114 lecturas

Cursor ahorra más tiempo no al escribir código nuevo, sino en todo lo que haces alrededor: leer proyectos ajenos, correcciones en múltiples archivos, tests y buscar por qué algo no funciona. He recopilado seis tareas donde la diferencia es mayor, con ejemplos de comandos.

Si acabas de instalar Cursor, empieza por el tutorial paso a paso. Aquí asumo que conoces el panel del Agente y el Plan Mode.

Entender un proyecto ajeno

Recibes un repositorio que nunca has visto y mañana tienes que modificar algo. En lugar de pasar horas navegando por archivos, preguntas al Agente por los puntos de entrada principales, módulos clave y qué vale la pena leer antes de hacer cambios. Este comando lo propone el propio quickstart de Cursor. Luego preguntas específicamente: dónde está la lógica de pagos, de dónde sale este valor, quién llama a esta función. Cursor responde señalando archivos, no con generalidades.

Cambios que afectan múltiples archivos

Cambiar el nombre de un campo en la base de datos, añadir un parámetro a una función usada en veinte lugares, migrar a una nueva versión de una librería. Hacerlo manualmente es tedioso y propenso a errores. En Plan Mode describes el cambio, Cursor primero revisa el proyecto y muestra un plan, y tú lo apruebas antes de la primera edición. Luego revisas la comparación de cambios archivo por archivo.

Tests para código que no los tiene

Todo proyecto tiene fragmentos sin tests porque siempre había algo más urgente. Seleccionas un módulo y pides tests de casos límite. Lo clave es que Cursor los ejecute inmediatamente y corrija los que fallan por problemas del test, no del código. El quickstart recomienda explícitamente pedir al agente que ejecute las comprobaciones que el proyecto ya usa.

Buscar la causa de un error

Pegas el mensaje de error o un fragmento de logs y pides que señale la causa, no que lo corrija directamente. Primero diagnóstico, luego cambio, porque un agente al que pides arreglar algo de inmediato puede enmascarar el síntoma en lugar de eliminar la causa. Solo cuando la explicación tiene sentido, pides la corrección.

Correcciones rápidas en un solo lugar

Para cosas pequeñas no necesitas el Agente. Seleccionas una función, pulsas Cmd + K (Ctrl + K) y escribes qué debe cambiar: añade manejo de lista vacía, reescribe como async, añade validación. Es el uso más frecuente porque toma pocos segundos.

En estas correcciones funciona una regla que vale para todo lo demás: cuanto menor sea el fragmento que selecciones, más preciso el cambio. Seleccionar una función da un resultado predecible, seleccionar todo el archivo invita a Cursor a corregir cosas que no pediste.

Documentación y descripciones de cambios

Descripción de pull request, comentario para una función compleja, instrucciones para ejecutar el proyecto. Cursor conoce el código que acabas de cambiar, así que lo describe con más precisión que un chat genérico al que tendrías que pegarlo todo.

Ejemplo: de un error en logs a la corrección

Así se ve una conversación completa ante un error típico, desglosada en pasos. Supongamos que un formulario de pedido a veces guarda una dirección vacía.

• Diagnóstico. Pegas un fragmento de logs y escribes: «A veces el pedido se guarda con dirección vacía. Encuentra posibles causas, no cambies el código todavía.» Cursor señala dónde se valida la dirección y dónde puede sobrescribirse.
• Confirmación. Pides un test que reproduzca el error. Si el test falla, tienes prueba de que la causa es correcta.
• Corrección. Solo ahora pides un cambio que haga pasar el test, sin tocar otras partes del formulario.
• Control. Pides ejecutar todos los tests para comprobar que la corrección no rompió nada más.

Cuatro comandos cortos en lugar de un «arréglalo» dan un cambio que entiendes y en el que confías. De paso queda un test que atrapará este error si vuelve algún día.

Ejemplo: nueva función en proyecto ajeno

Otro escenario frecuente es añadir una función a código que no escribiste. Empiezas preguntando dónde hay funciones similares ya hechas, por ejemplo cómo es la exportación de datos existente. Luego pides un plan en Plan Mode, basado en lo que ya hay en el proyecto. Así el código nuevo se parece al resto, no a un pegote de otro mundo, y es más fácil de revisar para alguien del equipo.

Dónde Cursor no sustituye pensar

Honestamente sobre los límites, porque también escribí sobre que un editor con IA no ayuda si no sabes qué preguntar:

• decisiones arquitectónicas las tomas tú, Cursor solo puede prepararlas,
• seguridad requiere revisión humana, especialmente en autenticación y datos de clientes,
• cambios sin tests son igual de arriesgados que al escribir manualmente, solo que surgen más rápido.

Pro o Pro+

El plan Pro basta para el trabajo diario en uno o dos proyectos. Pro+ tiene sentido en sprints intensivos, cuando el agente trabaja por ti la mayor parte del día. Los detalles de límites los describí en el texto Cuánto cuesta Cursor, y sobre cambiar modelos en la guía de Grok en Cursor.

// sigue leyendoFactory en la práctica: revisiones, tests y tareas pendientesGuíasCustomer.io en la práctica: casos de uso y automatizacionesRevistaBrain.fm en la práctica: trabajo profundo, estudio y concentraciónRevista