21 prompts en esta categoría
La IA no conoce tu código. La diferencia entre una respuesta útil y una plausible está casi siempre en el contexto que le diste.
Programar con IA se ha vuelto normal, y con ello el problema típico: respuestas que compilan, parecen razonables y resuelven un caso distinto al tuyo. Casi siempre porque el prompt no llevaba el contexto que hacía falta — versión, stack, restricciones, el error literal.
Los prompts de programación de esta página están construidos alrededor de ese contexto. Cubren depuración sistemática, revisión de código con criterios, diseño de arquitectura y esquemas de base de datos, generación de tests, documentación técnica y preparación de entrevistas.
Están en español con la terminología técnica en inglés, que es como se trabaja de verdad: nadie llama "pruebas unitarias de humo" a un smoke test. Las explicaciones son en español, los identificadores y los términos del oficio se quedan como están.
La traza entera, el mensaje literal y el fragmento donde ocurre. Una descripción del error es tu interpretación del error, y si tu interpretación fuera correcta probablemente ya lo habrías arreglado.
Lenguaje, framework, librería, gestor de paquetes, sistema operativo. Sin versiones obtienes soluciones de hace tres versiones mayores, con APIs que ya no existen. Es la causa número uno de que el código sugerido no funcione.
Que explique primero qué cree que está pasando y qué alternativas descarta. Si el diagnóstico es incorrecto lo ves en dos líneas, en vez de descubrirlo después de integrar treinta líneas de código y probarlas.
Claves de API, tokens, cadenas de conexión, datos de clientes. Sustitúyelos por marcadores antes de pegar nada. Y si trabajas con código bajo acuerdo de confidencialidad, revisa la configuración de datos de la herramienta antes de empezar, no después.
Stack: {LENGUAJE Y VERSIÓN}, {FRAMEWORK Y VERSIÓN}, {SO}.
Qué debería pasar: {COMPORTAMIENTO ESPERADO}
Qué pasa: {COMPORTAMIENTO REAL}
Cuándo empezó: {QUÉ CAMBIÓ ANTES DE QUE FALLARA}
Qué he probado ya: {INTENTOS Y RESULTADO}
<error>
{TRAZA COMPLETA, LITERAL}
</error>
<codigo>
{FRAGMENTO RELEVANTE}
</codigo>
Antes de proponer código:
1. Dime las 3 causas más probables, ordenadas por probabilidad
2. Para cada una, cómo la confirmo o la descarto en menos de un minuto
Solo cuando te diga cuál era, dame la corrección y explícame por qué
fallaba. No me des las tres soluciones a la vez.El "qué he probado ya" evita la respuesta más frustrante de todas, que es que te sugiera lo que acabas de descartar. Y pedir causas ordenadas con su forma de comprobarlas convierte el intercambio en depuración de verdad, en vez de ir probando parches hasta que uno cuele.
Después de leerlo y entenderlo, como cualquier código que no hayas escrito tú. Los fallos típicos no son de sintaxis sino de casos límite, gestión de errores y seguridad de las entradas. Si no puedes explicar qué hace cada línea, no está listo para producción.
Porque completa con lo que resulta estadísticamente plausible, y una función que debería existir lo es. Se reduce mucho dando la versión exacta de la librería y pidiendo que marque cualquier API de la que no esté seguro. Verificar contra la documentación oficial sigue siendo obligatorio.
Claude tiene fama merecida en código, especialmente en refactorizaciones grandes y en trabajar sobre un proyecto entero con Claude Code. DeepSeek da un nivel muy alto siendo gratuito. GitHub Copilot gana cuando lo que quieres es asistencia dentro del editor y no una conversación.
Depende de tu política interna y del plan que uses. En los planes de empresa el contenido normalmente no se usa para entrenar; en los individuales suele haber un ajuste para desactivarlo. Independientemente de eso, quita siempre credenciales y datos de clientes antes de pegar nada.