⏱️ Tiempo de lectura estimado: 7 minutos

Prompt Engineering: deja de adivinar y empieza a diseñar

Hay un momento que casi todo dev ha vivido: abres ChatGPT, escribes algo como "explícame este código", obtienes una respuesta mediocre, y piensas "esto no sirve para nada serio". Y te vas. Fin.

El problema no era el modelo. Era el prompt.

Llevo un tiempo usando LLMs como parte real de mi flujo de trabajo —no para reemplazar pensar, sino para acelerar las partes que más tiempo consumen— y lo que me cambió el juego no fue cambiar de modelo, ni pagar por el tier premium. Fue empezar a tratar los prompts como lo que son: una interfaz de programación en lenguaje natural. Y como toda interfaz, tiene sus reglas.

Por qué un prompt vago produce resultados vagos (sin excepción)

Los LLMs son, en esencia, máquinas de predicción de texto muy sofisticadas. No tienen intención propia. No saben qué querés. Generan la continuación más probable dado lo que escribiste.

Si escribís "mejorar este código", el modelo no sabe si querés legibilidad, performance, seguridad o simplemente que compile. Así que adivina. Y cuando adivina, a veces acierta, pero muchas veces no.

En mi experiencia, el 80% de los resultados decepcionantes con LLMs vienen de prompts que asumen demasiado. El modelo no es un colega que conoce tu contexto, tu stack, tu estilo de código y tus prioridades. Eso tenés que dárselo vos.

Ahora bien, ¿cómo se hace eso sin escribir un ensayo cada vez que querés una respuesta?

El truco está en la estructura, no en la longitud

Un prompt efectivo no tiene que ser largo. Tiene que ser preciso. Hay una estructura que me funciona casi siempre y que adapto según el caso:

Rol + Tarea + Contexto + Formato de salida

Ejemplo práctico. En lugar de:

"refactoriza esta función"

Probá con:

"Actuá como un dev senior con experiencia en Python y clean code. Refactorizá la siguiente función para que sea más legible y mantenible, sin cambiar su comportamiento. El equipo usa Python 3.11, preferimos funciones pequeñas y nombres descriptivos. Devolvé solo el código refactorizado con comentarios breves donde el cambio no sea obvio."

La diferencia en la calidad de la respuesta es brutal. No porque el modelo sea más inteligente —es el mismo— sino porque le diste lo que necesitaba para predecir bien.

Las tres palancas que más impacto tienen en tus prompts

No te voy a listar 47 técnicas. Eso es ruido. Estas tres son las que realmente mueven la aguja:

1. El rol define el tono y el nivel de profundidad

Decirle al modelo que "actúe como" algo específico no es magia ni truco de marketing. Es una forma de activar patrones de respuesta diferentes dentro del mismo modelo.

"Actuá como un revisor de código estricto" produce una respuesta diferente a "actuá como un mentor que explica sin juzgar". Mismo código, mismo pedido, resultado radicalmente distinto. Usá esto a tu favor según lo que necesitás en cada momento.

2. Las restricciones son tus mejores aliadas

Paradójicamente, limitar el espacio de respuesta produce mejores resultados. "No uses librerías externas", "no expliques cosas que ya sé", "máximo 10 líneas", "sin ejemplos adicionales".

Sin restricciones, el modelo tiende a ser exhaustivo y genérico. Con restricciones, se ve forzado a ser específico y útil. Ojo que esto también aplica al formato: si necesitás JSON, pedí JSON. Si necesitás una tabla comparativa, pedila. El modelo no va a elegir el formato óptimo por vos.

3. El contexto que das es el contexto que recibirás

Este es el que más se subestima. Si estás trabajando en un proyecto con una arquitectura particular, decíselo. Si tu equipo tiene convenciones de naming, mencionálas. Si el código que pegás es legacy con deuda técnica, aclaralo.

Cuanto más contexto relevante das, menos "relleno genérico" recibirás a cambio. No tengas miedo de hacer prompts largos cuando el contexto lo justifica. La brevedad es una virtud solo cuando no sacrifica precisión.

Prompt engineering en la práctica: casos reales de un dev

Acá van tres situaciones concretas donde aplico esto todos los días:

Revisión de pull requests: Le paso el diff y le pido que lo revise como si fuera un senior de mi equipo, buscando problemas de lógica, edge cases ignorados o violaciones de patrones específicos que le describo. El resultado es un segundo par de ojos antes de pedir review real.

Documentación técnica: Pego una función o módulo y le pido que genere el docstring en el formato que usa el proyecto, con ejemplos de uso y descripción de excepciones posibles. Me ahorra 15 minutos por función.

Debug de errores crípticos: En lugar de pegar solo el stack trace, pego el stack trace + el contexto de qué estaba haciendo + qué ya intenté. La respuesta pasa de genérica a accionable.

El punto es que en ninguno de estos casos el modelo piensa por mí. Me ayuda a ejecutar más rápido las partes que no requieren mi criterio más profundo, liberando espacio mental para lo que sí lo requiere.

Lo que sigue: prompts como activos reutilizables

Algo que empecé a hacer hace unos meses y que recomiendo: guardar los prompts que funcionan. Tratarlos como snippets. Tengo un archivo Markdown con prompts organizados por caso de uso: refactoring, documentación, generación de tests, análisis de arquitectura.

No es perfecta ciencia. Algunos prompts que funcionaban bien con GPT-4 los tuve que ajustar con Claude. Cada modelo tiene sus quirks. Pero tener esa base me evita empezar de cero cada vez y me permite iterar sobre algo que ya funciona en lugar de adivinar.

Dicho esto, el prompt engineering no es una habilidad que se aprende de una vez. Es algo que vas refinando a medida que usás los modelos, entendés sus limitaciones y ajustás tus expectativas. No hay un prompt perfecto universal. Hay prompts que funcionan bien para tu contexto específico.

Antes de irte

Si sentís que los LLMs te dan respuestas mediocres y no entendés por qué, es frustrante. Especialmente cuando ves a otros devs hablando maravillas de las mismas herramientas que a vos no te convencen. No es que ellos tengan acceso a algo especial — probablemente solo aprendieron a comunicarse con el modelo de manera diferente.

Empezá con un solo caso de uso que ya tengas en tu flujo de trabajo y aplicá la estructura Rol + Tarea + Contexto + Formato. Un prompt bien diseñado vale más que diez intentos al azar.

📎 Temas relacionados donde podrías profundizar: