Cuando empecé a usar Cursor a diario, mis primeros prompts eran frases cortas del tipo "arregla este error" o "mejora esta función". A veces funcionaban razonablemente bien, porque el contexto era obvio con solo mirar el archivo abierto. Muchas otras veces el resultado se quedaba corto, no porque la herramienta no pudiera hacerlo mejor, sino porque yo no le había dado suficiente información para acertar a la primera.

Un buen prompt no es una cuestión de estilo ni de encontrar la frase mágica. Es, sobre todo, una cuestión de contexto: qué existe ya, qué no se puede tocar y qué cuenta como un resultado válido.

El contexto que casi siempre falta

El error más habitual al escribir un prompt rápido es asumir que la herramienta ve el proyecto igual que yo lo veo en la cabeza. Ve el código, sí, pero no ve las decisiones que no están escritas: por qué una función se hizo de una manera concreta, qué otra parte del sistema depende de ese comportamiento, o qué alternativa ya se descartó antes por un motivo que ya no está documentado en ningún sitio.

Por eso, cuando el cambio no es trivial, incluyo en el prompt el porqué, no solo el qué. No es lo mismo pedir "cambia esta validación" que pedir "cambia esta validación para que acepte también el caso X, sin afectar al caso Y que ya está cubierto por una prueba existente".

Los límites del cambio, explícitos

Un prompt sin límites tiende a producir cambios más amplios de lo necesario, porque sin una frontera clara la herramienta puede interpretar razonablemente que "mejorar" incluye tocar cosas cercanas al problema original. Si solo quiero resolver un fallo concreto, lo digo así: qué archivos entran en el alcance del cambio y, si es relevante, qué archivos quiero que se dejen exactamente como están.

Esto es especialmente importante en proyectos con reglas de no regresión, donde un cambio que se sale de su alcance previsto puede tocar sin querer un comportamiento que ya funcionaba bien.

Qué cuenta como resultado aceptable

Otra parte que suelo olvidar cuando tengo prisa es explicar qué necesito para considerar el resultado correcto. No es lo mismo pedir un cambio que "compile" que pedir un cambio que además pase un conjunto concreto de pruebas, o que mantenga un comportamiento específico en un caso límite que me importa especialmente. Cuanto más claro dejo ese criterio de aceptación en el propio prompt, menos vueltas hacen falta después para llegar al resultado que realmente necesitaba.

Ejemplo práctico

Un prompt corto como "haz que el mapa muestre solo zonas aproximadas para los puntos privados" deja demasiadas decisiones abiertas: qué pasa con los puntos ya públicos, qué tamaño debe tener la zona aproximada, si el cambio afecta a la API o solo a la pantalla. Un prompt con más contexto explicaría, por ejemplo, que los puntos privados ya tienen una coordenada base y que se necesita calcular una coordenada de presentación en el servidor antes de enviarla al cliente, que los puntos ya marcados como públicos no deben tocarse, y que el resultado se considera correcto si una prueba concreta —que puedo indicar por nombre— sigue pasando después del cambio.

La diferencia entre ambos prompts no es de longitud por capricho: es la diferencia entre dejar que la herramienta adivine y darle la información que ya tengo yo en la cabeza pero que, si no la escribo, simplemente no existe para ella.

Iterar sobre la respuesta sin perder el hilo

Casi ningún cambio no trivial se resuelve en un único intercambio. Lo normal es recibir una primera propuesta, revisarla y pedir un ajuste concreto. Ahí también cuido el prompt: en lugar de escribir "no está bien, arréglalo", intento señalar exactamente qué parte de la respuesta no encaja y por qué, igual que haría al comentar el trabajo de otra persona. Un prompt de corrección vago suele producir un segundo intento tan alejado del objetivo como el primero, solo que en una dirección distinta.

Cuando el cambio necesita varias iteraciones, prefiero mantener el hilo de conversación centrado en ese cambio concreto en lugar de mezclarlo con tareas nuevas sin relación. Si surge algo distinto a mitad de camino, lo anoto para otro momento en vez de pedirlo en el mismo prompt: mezclar objetivos distintos suele diluir el resultado de ambos.

Errores frecuentes al escribir prompts

El primero es pedir demasiado en un solo prompt, mezclando un cambio funcional con una refactorización de estilo, porque entonces resulta difícil saber después qué parte del resultado corresponde a qué intención. El segundo es no indicar qué no se debe hacer: a veces es tan importante decir "no toques la lógica de puntuación, solo la interfaz" como describir lo que sí se quiere cambiar. El tercero es no revisar el resultado con el mismo criterio que aplicaría a un cambio propio: un buen prompt reduce el trabajo de revisión, pero no lo elimina.

Conclusión

Escribir un buen prompt para Cursor se parece más a escribir una buena descripción de tarea para un compañero que se une al proyecto hoy, que a encontrar una fórmula ingeniosa. Contexto, límites y criterio de aceptación son las tres piezas que marcan la diferencia entre iterar una vez y iterar cinco veces para llegar al mismo sitio. Esa misma preparación previa es la que explico, a otro nivel, en por qué planificar antes de programar no es perder el tiempo.