Cómo escribir mejores prompts para IA: el contexto que falta y hace que las sugerencias de IA sean realmente útiles

Los mejores prompts para IA no necesariamente son más largos. Contienen el contexto que un asistente necesita para tomar la decisión correcta, en lugar de limitarse a producir un cambio plausible. Para el trabajo de ingeniería, eso suele significar indicar el alcance, el supuesto, el resultado deseado, las restricciones y el motivo por el que el cambio importa.

Esa es la diferencia entre una respuesta que compila y un cambio que ayuda al producto.

Un asistente puede escribir código válido a partir de una instrucción breve, pero una instrucción breve suele ocultar la decisión de producto. “Quita la barra lateral en dispositivos móviles” le dice al asistente qué cambiar. No le dice si el comportamiento de escritorio debe mantenerse intacto, por qué el comportamiento actual perjudica a las personas ni cómo evaluar el éxito.

Cuando falta ese contexto, el asistente tiene que adivinar. Puede hacer un cambio técnicamente ordenado que elimine un flujo de trabajo útil en escritorio, cambie un diseño no relacionado o resuelva un síntoma en vez del problema.

Usa un prompt como un resumen conciso de ingeniería, no como una orden.

Empieza con estas seis piezas de información:

1. Alcance: ¿Qué pantalla, archivos, flujo o comportamiento abarca?
2. Problema: ¿Qué es difícil, está roto, es lento o confuso para quien usa el producto?
3. Supuesto: ¿Qué crees que está causando el problema?
4. Resultado deseado: ¿Qué debería ser cierto cuando el trabajo esté terminado?
5. Restricciones: ¿Qué debe permanecer sin cambios y qué enfoques no están permitidos?
6. Solicitud de evidencia: Pídele al asistente que cuestione el supuesto y explique qué verificaría primero.

No necesitas todos los elementos para una pregunta de una línea. Sí los necesitas cuando el asistente podría tomar una decisión de producto o arquitectura por ti.

Este es un prompt débil:

Haz que la navegación móvil sea más coherente y elimina la barra lateral.

Ofrece una acción, pero no delimita la decisión. El asistente podría eliminar la barra lateral en todas partes porque no sabe que los usuarios de escritorio dependen de ella.

Este es un prompt mejor:

Problema: La barra lateral de escritorio es difícil de usar en dispositivos
móviles porque ocupa demasiado espacio horizontal y compite con el contenido
de las lecciones.

Supuesto: Un patrón de navegación específico para móviles facilitaría cambiar
de lección sin modificar el flujo de trabajo de escritorio.

Resultado: En pantallas pequeñas, los estudiantes pueden cambiar de lección y
volver al ejercicio actual sin perder el contexto. Los usuarios de escritorio
conservan la barra lateral y el flujo de trabajo con teclado actuales.

Restricciones: No elimines la barra lateral de escritorio. Conserva el
comportamiento actual de las rutas, las etiquetas de accesibilidad y el estado
del progreso. Evita añadir una segunda fuente de verdad para la lección
seleccionada.

Antes de implementar, inspecciona quién controla actualmente la navegación y
cuestiona el supuesto si un cambio de diseño más pequeño resolviera el problema.

El mejor prompt le da al asistente margen para investigar, pero deja claros los límites importantes: el alcance son los dispositivos móviles, el comportamiento de escritorio está protegido y un único propietario del estado no es negociable.

Una solicitud de ubicación puede tener el mismo problema:

Mueve el botón de temas a la barra lateral y haz que encaje.

Esa instrucción trata el diseño existente como decoración. No explica por qué el cambio de tema debe estar en otro lugar ni cómo deberían encontrarlo las personas después del traslado.

Prueba esto en su lugar:

Problema: El selector de temas en la barra de navegación compite con la
navegación global, pero las personas lo usan al comparar lecciones dentro del
curso actual.

Resultado deseado: Coloca el cambio de tema junto a la navegación del curso
para que su propósito sea claro y siga siendo fácil de alcanzar mientras se
explora una lección.

Restricciones: Mantén sin cambios las acciones globales de la barra de
navegación, conserva el tema seleccionado entre navegaciones y no conviertas
la barra lateral en la única forma de cambiar de tema en pantallas estrechas.

Primero inspecciona el modelo actual de rutas y estado. Explica si la barra
lateral es el destino correcto antes de cambiar el diseño.

El cambio central no es “más detalle”. Es una mejor definición del éxito.

La IA es más útil cuando puede señalar una premisa equivocada antes de escribir un parche. Añade una pregunta directa:

¿Qué evidencia refutaría este supuesto y qué cambio más pequeño deberíamos
considerar primero?

Para un error, pide pasos de reproducción e hipótesis alternativas. Para una refactorización, pregunta qué comportamiento podría sufrir una regresión. Para un cambio de arquitectura, pregunta qué propietario, límite o contrato existente se duplicaría.

Eso desplaza el trabajo de “producir código ahora” a “tomar una decisión defendible y luego implementar”.

Usa esta plantilla cuando una tarea necesite contexto de producto y técnico:

Tarea: [Describe el cambio en una oración.]

Problema: [¿A quién afecta y qué está saliendo mal?]
Alcance: [Archivos, pantallas, flujo de trabajo o subsistema incluidos.]
Supuesto: [Qué crees que causa el problema o qué solución podría ayudar.]
Resultado deseado: [Resultado observable para la persona usuaria y el sistema.]
Restricciones: [Comportamiento que se debe conservar, compatibilidad,
rendimiento, accesibilidad, seguridad, despliegue y objetivos fuera de alcance.]
Contexto relevante: [Arquitectura, flujo de datos, cambios recientes, registros o ejemplos.]
Criterios de aceptación: [Cómo sabremos que el trabajo está terminado.]
Validación: [Pruebas, comprobaciones manuales o mediciones que se deben ejecutar.]

Antes de cambiar código, inspecciona el área relevante. Cuestiona el supuesto
si la evidencia indica una solución más segura o más pequeña.

La plantilla también facilita la revisión: un compañero puede ver el resultado previsto y decidir si la implementación propuesta lo satisface.

El contexto relevante es selectivo. Incluye una prueba que falla, un mensaje de error, el límite actual del componente, la carga útil de una solicitud o un breve recorrido de usuario. No pegues miles de líneas no relacionadas con la esperanza de que el asistente encuentre la parte importante.

Para un flujo de trabajo de programación enfocado, consulta cómo formular prompts a ChatGPT para programar. Para patrones reutilizables de trabajo de implementación, depuración y revisión, lee ingeniería de prompts para desarrolladores.

Usa una guía específica de la herramienta cuando el contexto del repositorio cambie el prompt: prompts para Cursor AI, prácticas recomendadas para prompts de GitHub Copilot o cómo obtener mejores resultados de Claude Code.

Usa una guía específica de la tarea cuando necesites una redacción lista para adaptar: ejemplos de ingeniería de prompts para ingenieros de software, plantillas de prompts para refactorizar código o plantillas de prompts para depurar problemas de producción.

Usa una guía de decisiones cuando el riesgo sea de proceso en lugar de sintaxis: errores de los asistentes de programación con IA y cómo evitarlos y cómo usan la IA los desarrolladores sénior de otra manera.

Los mismos hábitos que hacen útiles los prompts para IA vuelven más claros los tickets, los pull requests y las notas de incidentes: explica el problema, define el resultado, conserva el comportamiento importante y valida el resultado.

Cuando una tarea implique un comando de shell o la salida de una terminal, concreta el comportamiento antes de pedirle a un asistente que lo cambie. Practica flujos de trabajo de línea de comandos en el navegador para poder reconocer la entrada, la salida y el modo de fallo que quieres que gestione la implementación.