Prompt engineering: deja de adivinar y empieza a usar la IA como se debe
La mayoría de la gente usa ChatGPT o Claude como si fuera Google. Hay una forma mejor. Te cuento cómo pienso los prompts cuando construyo automatizaciones reales.
Hay algo que me repite la gente cuando le muestro lo que se puede hacer con un modelo de lenguaje bien usado: “¿y cómo supiste escribirle eso?”
La respuesta honesta es: con práctica y con estructura. No con magia.
El prompt engineering no es una habilidad mística. Es aprender a comunicarte bien con un sistema que tiene capacidades enormes pero que literalmente no sabe leer entre líneas si no se lo dices.
El error más común: pedir sin contexto
La mayoría de la gente escribe: “Escríbeme un email para mi cliente.”
Y el modelo hace lo que puede. Genera algo genérico que puedes usar, pero que probablemente tendrás que reescribir.
El problema no es el modelo. Es que le faltó información.
Prueba esto en cambio: “Escríbeme un email para un cliente que no ha respondido en dos semanas. El tono debe ser profesional pero directo. El objetivo es conseguir una respuesta, no disculparse. Somos una agencia de desarrollo web y él nos debe el 40% del pago del proyecto.”
La diferencia en el resultado es enorme. No porque el modelo sea más inteligente, sino porque tú le diste lo que necesitaba para ser útil.
Los componentes que sí importan en un prompt
No te voy a dar una fórmula mágica porque no existe. Pero hay elementos que casi siempre mejoran el resultado:
Rol o contexto: Quién eres o qué perspectiva quieres que adopte el modelo. “Actúa como un abogado de contratos revisando este texto.” o “Eres un desarrollador backend senior con experiencia en Go.” Esto no es teatro, es calibrar el tipo de respuesta que esperas.
Tarea específica: Qué quieres exactamente. No “ayúdame con esto”, sino “revisa este fragmento de código, identifica posibles memory leaks y sugiere correcciones concretas.”
Formato de salida: ¿Lista? ¿Párrafos? ¿JSON? ¿Código con comentarios? Si no lo dices, el modelo elige por ti, y a veces elige mal.
Restricciones: Qué no quieres. “No uses jerga técnica. La respuesta debe tener menos de 100 palabras. No incluyas preguntas de vuelta.”
Iteración: así es como funciona en la práctica
Nadie escribe el prompt perfecto a la primera. Ni yo. El flujo real es:
- Escribes un prompt razonable
- Ves la respuesta
- Identificas qué falta o qué sobra
- Ajustas y repites
En proyectos donde integro IA para automatización, el 80% del tiempo no está en el código. Está en refinar los prompts hasta que el modelo produce outputs consistentes y predecibles. Eso es el trabajo real.
Cuándo el prompt engineering no es la solución
Si tu modelo responde bien a veces y mal otras para el mismo input, el problema puede no ser el prompt. Puede ser:
- Temperatura muy alta: El modelo tiene demasiada libertad creativa. Bájala si necesitas consistencia.
- Contexto insuficiente en la arquitectura: Para aplicaciones reales, a veces necesitas RAG (Retrieval-Augmented Generation) o darle acceso a documentos específicos.
- El modelo equivocado para la tarea: GPT-4o es bueno en muchas cosas, Claude 3.5 Sonnet también, pero hay tareas donde uno supera al otro. No es cuestión de lealtad a una marca, es probar y medir.
Lo que sí aprendí trabajando con esto todos los días
La IA no es un botón mágico. Es una herramienta que amplifica lo que ya sabes hacer. Si sabes qué quieres y puedes articularlo claramente, la IA lo ejecuta muy bien. Si no sabes qué quieres, la IA te va a generar texto bonito que no sirve para nada.
El prompt engineering, en esencia, es claridad de pensamiento. Eso no lo reemplaza ningún modelo.
Si estás construyendo algo con IA y los outputs no son consistentes, escríbeme. Probablemente hay una forma más limpia de estructurar lo que estás pidiendo.