Tu primer buen prompt

Un prompt no sustituye una decisión de producto: la hace visible para que otra persona o una inteligencia artificial (IA) pueda actuar sobre ella. La práctica recomendada por OpenAI y Google parte de instrucciones claras, contexto relevante, ejemplos cuando aportan un patrón y ciclos de revisión. Aquí aplicarás esa pauta a un formulario para crear tareas.

El caso será pequeño a propósito. El formulario necesita título, responsable, fecha límite y prioridad; debe rechazar datos incompletos y confirmar el guardado. Ese alcance permite observar si cada instrucción cambia un comportamiento concreto.

Convierte la idea en una tarea verificable

«Haz un gestor de tareas» describe un producto, pero no define el siguiente cambio. Una tarea verificable indica qué debe aparecer, qué puede hacer una persona y cómo sabrás que funciona. En nuestro caso, el primer objetivo será completar un formulario y guardar una tarea válida.

Formula el encargo con un verbo y un resultado observable. Por ejemplo: «Crea el formulario para registrar una tarea con título, responsable, fecha límite y prioridad; al enviarlo, añade la tarea a la lista». Esta frase aún necesita contexto y validación, pero ya evita que la IA invente un panel, un calendario o un sistema de permisos.

Si quieres aprender el ciclo completo que rodea esta petición, consulta qué es vibe coding. El prompt inicia una iteración; la revisión, las pruebas y la decisión de aceptar el cambio siguen siendo tuyas.

Aporta solo el contexto que cambia la solución

El contexto útil reduce decisiones ocultas. Nombra el framework si ya existe, los componentes que deben reutilizarse, el idioma de la interfaz y el lugar donde se guarda el estado. También indica qué archivos o áreas no deben cambiar.

Para el formulario de tareas, el contexto podría decir que la aplicación ya posee una lista y un componente de botón, que los textos deben estar en español y que el estado permanece en memoria. No hace falta explicar toda la historia del proyecto. Incluye la información que modificaría la implementación o la forma de comprobarla.

Cuando no conoces el stack, dilo de forma directa. Pide primero una propuesta breve con sus consecuencias y apruébala antes de autorizar cambios. Esa pausa evita que una elección técnica accidental se convierta en una dependencia difícil de retirar.

Describe el resultado antes de pedir código

La salida esperada incluye estructura y comportamiento. En el ejemplo, necesitas cuatro campos etiquetados, un botón de envío, errores junto al campo afectado y una confirmación tras guardar. También puedes pedir una lista de archivos modificados y las pruebas ejecutadas.

Un ejemplo concreto ayuda cuando la forma del resultado importa. Escribe una tarea válida, como «Preparar la demo, responsable Ana, fecha 20 de julio, prioridad alta», y una entrada inválida con el título vacío. El modelo dispone entonces de un patrón para el estado correcto y otro para el error.

No uses el ejemplo como sustituto de la regla. Si solo muestras una fecha válida, la IA puede aceptar cualquier texto parecido. Explica además que la fecha debe ser real y no anterior al día actual.

Fija criterios de aceptación observables

Los criterios de aceptación convierten «parece terminado» en una revisión repetible. Para este formulario, cada criterio debe poder comprobarse en la interfaz o mediante una prueba. Evita frases como «que sea intuitivo», porque no indican qué comportamiento debe cambiar.

Puedes definir los siguientes resultados. Cada uno corresponde a una prueba visible:

1. El título, el responsable y la fecha son obligatorios.
2. Una fecha pasada muestra un mensaje junto al campo y no guarda la tarea.
3. Un envío válido añade una sola tarea con todos sus valores.
4. El formulario se limpia solo después de guardar correctamente.
5. La navegación por teclado alcanza campos, opciones y botón en un orden lógico.

Estos criterios también limitan el alcance. Si la IA añade filtros, autenticación o sincronización remota, ha trabajado fuera de la tarea aunque el resultado se vea atractivo.

Mejora el resultado con feedback específico

La primera versión puede fallar aunque el prompt sea claro. Reproduce el problema y responde con tres datos: qué hiciste, qué ocurrió y qué esperabas. Para el formulario: «Elegí ayer como fecha, el envío se aceptó y esperaba un error junto al campo».

Añade una prueba que impida la regresión. Pide cubrir una fecha pasada y otra futura, ejecutar la suite existente y mostrar el resultado. Esta práctica convierte el feedback en evidencia y evita una corrección visual que deje intacta la lógica.

No mezcles varias correcciones sin relación. Si también quieres cambiar colores y añadir etiquetas, deja esas tareas para iteraciones separadas. Así puedes atribuir cada resultado a una instrucción y revertir solo lo necesario.

Reconoce los límites y los fallos del prompt

Un prompt detallado no garantiza una solución correcta. El modelo puede asumir una zona horaria, ignorar una convención del repositorio, inventar una API o escribir una prueba que solo confirme su propia implementación. Revisa el código y ejecuta el flujo real.

Los datos sensibles requieren otra capa de cuidado. No pegues credenciales, datos personales ni contenido privado para «dar contexto». Si el trabajo necesita acceso externo o acciones irreversibles, define permisos mínimos y aprobación humana; la guía de agentes de IA explica ese contrato.

La recomendación de dividir tareas y dar feedback concreto es una heurística práctica, no una ley universal. Una migración coordinada puede necesitar un plan amplio, mientras una corrección local cabe en una petición corta. Ajusta la profundidad al riesgo y conserva siempre una forma independiente de verificar el resultado.

Revisa el prompt antes de enviarlo

Usa esta lista como puerta de entrada a la tarea. Cada casilla debe corresponder a una frase o criterio visible en tu petición.

• El objetivo nombra un único cambio terminado.
• El contexto incluye solo datos, archivos y decisiones relevantes.
• El resultado esperado describe estados válidos y estados de error.
• Los criterios de aceptación se pueden comprobar sin interpretar intenciones.
• El alcance excluye cambios y acciones que no has autorizado.
• La tarea contiene una prueba o recorrido para validar el resultado.

Si no puedes marcar una casilla, corrige el prompt antes de ampliarlo. En el formulario de tareas, el objetivo final no es recibir mucho código: es poder crear una tarea válida, rechazar una inválida y demostrar ambos comportamientos.