Dos personas pueden pegar el mismo fragmento de código en un chat y recibir respuestas radicalmente distintas. No porque una haya encontrado una frase mágica, ni porque la otra haya elegido mal una “persona experta”. La diferencia suele estar en algo menos espectacular: una presentó evidencia suficiente para que otra persona pudiera reconstruir el problema; la otra pidió que alguien adivinara.
Ese matiz importa para quien está aprendiendo. Cuando el objetivo es solo obtener una corrección, cualquier respuesta que parezca funcionar puede sonar útil. Cuando el objetivo es entender por qué el programa se comportó así, el prompt debe dejar visibles las mismas piezas que usaría un compañero para investigar: síntoma, contexto mínimo, comportamiento esperado y el tipo de ayuda que necesitas.
Por eso un buen prompt para código no es una receta ni un párrafo largo. Es un contrato de evidencia. Le dice a la IA qué puede comprobar, qué no debe asumir y dónde debe detenerse antes de reescribir tu proyecto entero.
El mismo error, dos consultas, dos diagnósticos
Imagina que una función devuelve NaN cuando calcula un descuento. La primera consulta dice: “Mi cálculo no funciona, arréglalo”. La segunda dice: “En JavaScript, precioFinal(120, '10') devuelve NaN. Espero recibir 108 porque el segundo argumento representa un porcentaje. No sé si el problema está en el tipo recibido o en la fórmula. Explícame primero qué expresión produce el valor y propón el cambio más pequeño”.
| Consulta que exige adivinar | Consulta que permite investigar |
|---|---|
| “No funciona; corrígelo”. | Describe una entrada concreta y el resultado observable. |
| No muestra qué debería pasar. | Declara una expectativa, aunque sea provisional. |
| Invita a reemplazar código a ciegas. | Pide una operación limitada: explicar, localizar, comparar o probar. |
| Oculta restricciones de versión, entorno o archivos. | Aporta solo el contexto que cambia la hipótesis. |
La segunda consulta no es “mejor escrita” por tener más palabras. Es mejor porque reduce el espacio de interpretaciones. La guía de contexto en chat de VS Code distingue archivos, carpetas, símbolos, salida de terminal y cambios de control de versiones como contexto explícito. Esos elementos no adornan la pregunta: cambian qué afirmaciones puede verificar quien responde.
No empieces por el prompt: empieza por el síntoma
Un síntoma es algo que podrías observar sin llamar a una IA: una pantalla queda vacía, una prueba falla, un botón no cambia de estado, un archivo no aparece o un comando muestra una excepción. Es distinto de una teoría sobre la causa. “Mi API está mal configurada” ya presupone una explicación; “la petición devuelve 401 solo después de reiniciar el servidor” describe un hecho que todavía puede investigarse.
Antes de abrir el chat, intenta completar esta frase: “Cuando hago X con Y, observo Z; en cambio esperaba W”. Si no puedes completar una parte, eso también es información útil. Puedes pedir que la herramienta te ayude a definir qué observar, en lugar de pedir una solución inventada.
Acción: envío el formulario con un correo válido.
Observado: el botón queda deshabilitado y no aparece ninguna petición en Network.
Esperado: debería enviarse POST /api/suscripciones.
Restricción: no quiero cambiar la librería de formularios; primero quiero localizar
qué condición deja el botón deshabilitado.Este formato obliga a separar lo que sabes de lo que sospechas. También te prepara para depurar sin asistencia: la guía sobre herramientas del navegador es más fácil de aplicar cuando tienes un evento y un resultado observables, no una sensación general de que “la página está rota”.
El contexto útil es una frontera, no una biografía
“Estoy aprendiendo JavaScript y mi proyecto es una tienda” rara vez basta para diagnosticar un bug. Pero pegar todos los archivos tampoco ayuda necesariamente. El contexto debe responder a una pregunta más dura: ¿qué detalle, si faltara, haría que una explicación razonable pudiera ser falsa?
Para un error de tipos, quizá basta con la firma de la función, la llamada y el valor recibido. Para un comportamiento que solo aparece en producción, puede importar la versión, una variable de entorno o la respuesta real del servidor. Para una sugerencia de estructura, quizá sea más valioso compartir dos módulos y el límite que no quieres cruzar que enviar mil líneas de componentes sin relación.
La recomendación de VS Code es específica: puedes añadir archivos, carpetas, símbolos, herramientas y salida de terminal al contexto; hacerlo de forma explícita sirve cuando necesitas que el asistente considere una parte concreta del proyecto. Eso sugiere una regla práctica: entrega el fragmento mínimo que cambia la respuesta, no el mayor bloque que puedas copiar.
¿Debo describir toda mi aplicación?
No. Describe el borde que toca al síntoma. Si un error ocurre al convertir una fecha, el formato de entrada, la zona horaria esperada y la función de conversión son más valiosos que la lista completa de pantallas. Si más tarde aparece una dependencia entre módulos, amplía el contexto en una segunda conversación. Añadir contexto por capas es más fácil de revisar que lanzar una solicitud enorme y aceptar una refactorización que no entiendes.
La pieza que suele faltar: el comportamiento esperado
Muchos prompts contienen código y error, pero no declaran qué debería conservarse. Sin esa expectativa, una respuesta puede “arreglar” el síntoma eliminando una validación necesaria, convirtiendo todo a texto o envolviendo una excepción que debías ver. El código compila; el contrato se pierde.
No necesitas saber la implementación correcta para declarar una expectativa. Puedes describir una relación, un ejemplo o una restricción:
- “Los nombres repetidos deben rechazarse, pero los correos pueden actualizarse”.
- “La función debe devolver una lista nueva y no cambiar la que recibió”.
- “Cuando falta una clave, prefiero un mensaje explicativo a un valor por defecto silencioso”.
La documentación de buenas prácticas de IA en VS Code recomienda describir entradas, salidas, restricciones y resultados esperados. Además, aconseja incluir casos de prueba o criterios de aceptación para que la propia salida pueda verificarse. Para un principiante, esta es una mejora importante: el prompt deja de ser una forma de pedir código y se convierte en una forma de escribir una prueba antes de tocar el código.
¿Qué hago si no sé cuál es el resultado correcto?
No inventes una respuesta solo para completar el prompt. Declara la duda y pide una comparación de alternativas: “No sé si un campo vacío debe ser error o valor opcional. Muéstrame qué cambia en cada decisión y qué prueba escribirías para distinguirlas”. La IA puede ayudarte a exponer una decisión de producto o de dominio, pero no debería ocultar que esa decisión existe.
Pide una operación, no una solución total
“Reescribe todo” es una petición cómoda cuando estás bloqueado, pero suele producir el tipo de respuesta que más cuesta aprender a revisar: cambia nombres, estructura, estilos y lógica a la vez. Si algo sigue fallando, ya no sabes qué modificación mirar primero.
En cambio, puedes pedir una operación concreta. Las siguientes no son plantillas para copiar; son límites que cambian el tipo de colaboración:
| Cuando necesitas… | Delimita la ayuda así |
|---|---|
| Entender una excepción | “Explica cada frame y dime qué valor inspeccionar antes de proponer un cambio”. |
| Elegir entre dos cambios | “Compara estas alternativas con un caso que una maneje mal”. |
| Corregir un fallo pequeño | “Propón el diff mínimo y el test que demostraría la corrección”. |
| Revisar una hipótesis | “No asumas que mi causa es correcta; señala qué dato la confirmaría o refutaría”. |
Esta manera de pedir ayuda evita una dependencia que ya analizamos en el artículo sobre aprender programación con IA: recibir una respuesta terminada puede eliminar justo la fricción que te permitiría comprobar si entendiste. El límite no reduce la utilidad de la herramienta; reduce el número de decisiones invisibles que aceptas de una vez.
Un informe que otra persona podría reproducir
Supón que este código debería filtrar productos disponibles:
const disponibles = productos.filter(producto => producto.stock);
console.log(disponibles);La consulta “filter no funciona” deja demasiadas preguntas abiertas. ¿stock es número, texto, null? ¿Cero debe ocultar un producto? ¿El problema está en el resultado o en cómo se renderiza? Un informe mejor no necesita anticipar la solución:
Estoy filtrando productos disponibles. `stock` es un número y 0 significa “sin unidades”.
Con [{ nombre: 'A', stock: 0 }, { nombre: 'B', stock: 3 }] obtengo solo B,
lo cual parece correcto. Pero necesito decidir qué ocurrirá si la API devuelve
`stock: null`. ¿Debo normalizar el dato antes de filtrar o tratarlo como error?
Compara ambas opciones y escribe una prueba para cada contrato.Ahora hay evidencia, una decisión explícita y un criterio de verificación. La respuesta puede discutir datos ausentes, coerción y tests sin inventar cuál es tu modelo de negocio. También deja una huella que podrías llevar a un compañero humano o convertir en issue.
Cuando la IA debe preguntar antes de arreglar
Una buena respuesta no siempre empieza con código. Si el comportamiento esperado no está definido, si falta el mensaje completo de error o si dos archivos parecen responsables, el siguiente paso puede ser una pregunta de aclaración. Incluir esa instrucción en tu solicitud es útil: “Si falta información para proponer un cambio seguro, enumera primero las tres preguntas que cambiarían tu recomendación”.
Esta petición combate un hábito costoso: aceptar una explicación fluida como si fuera evidencia. La guía de ingeniería de prompts de OpenAI insiste en separar instrucción y contexto, y en especificar resultado y formato. En código, esa separación permite detectar qué parte de una respuesta procede de tu proyecto y cuál procede de una suposición del modelo.
¿Conviene pegar el traceback completo?
Sí, cuando el traceback forma parte del síntoma; recorta secretos, tokens, correos reales, rutas sensibles y datos de clientes antes de compartirlo. Si el error es largo, conserva el tipo final, los frames de tu código y las líneas que cambian la hipótesis. La guía para leer tracebacks de Python puede ayudarte a distinguir qué partes aportan contexto y cuáles pertenecen a dependencias que todavía no necesitas analizar.
Antes de enviar, deja cuatro pistas verificables
Un prompt de programación gana precisión cuando otra persona podría responder cuatro preguntas sin leer tu mente: ¿qué hiciste?, ¿qué observaste?, ¿qué esperabas? y ¿qué tipo de ayuda aceptas ahora? Si una de esas respuestas falta, no rellenes el hueco con una frase más persuasiva. Busca una ejecución, un valor, una prueba, un archivo o una decisión que puedas mostrar.
La habilidad no consiste en escribir mensajes cada vez más largos. Consiste en convertir una sensación de bloqueo en evidencia que pueda discutirse. Esa misma disciplina mejora tus conversaciones con IA, tus reportes de bugs, tus revisiones de código y, sobre todo, tu capacidad de investigar cuando no hay nadie disponible para responder.
Martin Rojas escribe sobre tecnología, programación y desarrollo web. En Skydutz Academy comparte explicaciones prácticas sobre herramientas digitales, conceptos de programación y recursos para aprender de forma progresiva. Su objetivo es hacer que los temas técnicos sean más claros, útiles y accesibles para lectores de distintos niveles.