Los trucos de prompting que aprendiste en 2023 hoy te están estorbando. "Actúa como un experto en...", "piensa paso a paso", "respira profundo", las plantillas de cinco secciones con ROLE y CONTEXT en mayúsculas. Todo eso existía porque los modelos de entonces necesitaban que los empujaras.
Los de ahora no. Piensan solos, planean solos y siguen instrucciones de forma mucho más literal. Eso invierte la regla: un prompt sobre-especificado —lleno de pasos, prohibiciones y andamios— ahora baja la calidad de la respuesta, porque el modelo se pega a tu guion en lugar de resolver el problema.
El oficio se está moviendo de escribir instrucciones a describir resultados. De ingeniería de prompts a ingeniería de intención. Esta guía es cómo se hace, y trae al final un prompt convertidor que te reescribe cualquier prompt viejo.
Qué cambió, en una frase
Antes tu trabajo era decirle al modelo cómo hacer la tarea. Ahora tu trabajo es decirle qué tiene que ser cierto cuando termine.
Es un cambio de rol. Dejas de ser el que dicta el método y pasas a ser el que define el criterio de aceptación. Es exactamente lo que haces cuando le encargas algo a alguien bueno: no le explicas cómo hacer su trabajo, le explicas para qué es, para quién, y cómo vas a saber si quedó bien.
La diferencia en un ejemplo
Un caso real de operación: analizar el pipeline de un equipo comercial.
Como se escribía antes —instrucciones:
Actúa como un analista de ventas senior con 15 años de experiencia.
Piensa paso a paso.
PASO 1: Lee el CSV.
PASO 2: Calcula el total por etapa.
PASO 3: Identifica los deals estancados.
PASO 4: Haz una tabla.
PASO 5: Escribe 3 recomendaciones.
IMPORTANTE: NO inventes datos. NO uses lenguaje florido.
CRÍTICO: DEBES incluir porcentajes.Como se escribe ahora —intención:
Adjunto el export del pipeline. Necesito saber, antes del lunes,
en qué parte del embudo se nos está atorando el dinero y qué
tenemos que hacer esta semana al respecto.
Lo lee el director comercial, que conoce el negocio y no necesita
que le expliquen qué es un pipeline. Va a tomar decisiones de
asignación de gente con esto, así que cualquier cifra tiene que
salir del archivo y ser rastreable.
Está bien si el hallazgo es incómodo. Lo que no sirve es un
resumen que no cambie ninguna decisión.El segundo es más corto, no tiene ni un solo paso numerado, y produce un análisis mejor. Porque el modelo ya sabe cómo se analiza un pipeline. Lo que no sabía era para quién es, cuándo se necesita, qué decisión depende de eso, y qué cuenta como respuesta inútil.
Los cuatro componentes de una intención
1. El resultado, no la tarea
"Escribe un correo" es una tarea. "Necesito que este cliente conteste con una fecha para la junta" es un resultado. La segunda forma le deja al modelo elegir el tono, el largo y el ángulo, que es precisamente donde es bueno.
La prueba: si tu frase describe algo que el modelo va a producir, es tarea. Si describe algo que va a pasar, es resultado.
2. El lector y lo que va a hacer con esto
Un mismo análisis se escribe distinto para un inversionista, para tu jefe y para el equipo que lo va a ejecutar. Decir quién lo lee y qué decisión va a tomar reemplaza a diez instrucciones de formato y tono.
La prueba: si borraras la mitad de tus reglas de estilo y agregaras una línea sobre el lector, ¿se perdería algo? Casi nunca.
3. Las restricciones reales, con su porqué
Las restricciones que importan son las que tienen consecuencia: presupuesto, plazo, marco legal, cifras que no se pueden inventar, cosas que la empresa no puede prometer. Las que no importan son las preferencias de estilo disfrazadas de reglas. Y siempre di el porqué: una restricción con motivo se aplica con criterio, una sin motivo se aplica al pie de la letra en casos donde no tiene sentido.
La prueba: ¿qué pasa si el modelo rompe esta regla? Si la respuesta es "nada grave", bórrala.
4. Cómo sabrás que quedó bien
Este es el que casi nadie escribe y el que más cambia el resultado. Un criterio de aceptación explícito —"tiene que traer una columna numérica de precio por SKU", "cada afirmación tiene que apuntar a una fuente del archivo"— le da al modelo con qué verificarse a sí mismo antes de entregarte.
La prueba: si tú no puedes decir en una frase cómo distinguirías un buen entregable de uno malo, el modelo tampoco.
El paso que todo mundo se salta: decir qué no es el trabajo. Los modelos actuales tienden a ampliar el alcance —te arreglan cosas que no pediste, agregan secciones que no van, refactorizan de más. Una línea del tipo "no toques el resto del documento" o "si crees que el enfoque está mal, dilo en una frase y sigue con lo que pedí" ahorra más idas y vueltas que cualquier otra cosa que escribas.
El prompt convertidor
No tienes que reescribir tu biblioteca de prompts a mano. Pégale este a Claude o a ChatGPT junto con cualquier prompt viejo y te lo convierte. Lo uso cada vez que rescato algo de mis notas de hace dos años.
Eres un editor de prompts. Te voy a pegar un prompt que escribí
para un modelo más viejo. Conviértelo de instrucciones a intención.
Tu criterio para reescribirlo:
1. BORRA el andamiaje muerto. Fuera "actúa como", "piensa paso a
paso", "respira profundo", "eres un experto en X con N años de
experiencia", los pasos numerados de tareas que son de juicio y
no de secuencia obligada, y los énfasis en mayúsculas.
2. CONSERVA todo lo que solo yo puedo saber: quién lee esto, para
qué se va a usar, restricciones de negocio, límites legales,
datos que no se pueden inventar, formato cuando de verdad es
rígido, y contexto de mi empresa o mi producto.
3. CONVIERTE cada prohibición en una descripción de lo que sí
quiero, salvo que la prohibición proteja contra un error real.
Si una restricción se queda, ponle el porqué en la misma frase.
4. AGREGA lo que falte, y márcalo como pregunta si no lo puedes
deducir del original:
- el resultado (qué tiene que pasar, no qué tienes que producir)
- el lector y la decisión que va a tomar con esto
- el criterio de aceptación: cómo sabré que quedó bien
- qué queda fuera de alcance
5. CONSERVA los pasos numerados SOLO cuando el orden sea
obligatorio de verdad (procesos destructivos, secuencias de
autenticación, cumplimiento). Ahí la precisión sigue ganando.
Devuélveme tres cosas, en este orden:
A) El prompt reescrito, listo para copiar.
B) Una lista de qué borraste y por qué, en una línea cada uno.
C) Las preguntas que necesito contestarte para que quede completo.
No suavices el diagnóstico. Si el prompt original estaba pidiendo
algo mal definido, dímelo.
Aquí va el prompt original:
---
[PEGA AQUÍ TU PROMPT]Dónde sí sigue valiendo la ingeniería de prompts
Esto no es "escribe menos y ya". Hay tres lugares donde la especificación detallada sigue ganando, y confundirlos es el error más caro:
- Operaciones frágiles. Comandos destructivos, flujos de autenticación, pasos de cumplimiento. Donde solo existe una secuencia segura, escribe la secuencia exacta.
- Descripciones de herramientas. Si le das herramientas a un agente, el detalle sobra por el lado contrario: la mayoría de las descripciones son demasiado escuetas. Di qué hace, cuándo llamarla, qué significa cada parámetro y qué no devuelve.
- Formatos rígidos de verdad. Si la salida alimenta a otro sistema, no la describas: usa salidas estructuradas y define el esquema.
La prueba de si lo estás haciendo bien
Toma tu prompt reescrito y quítale la última frase de criterio de aceptación. ¿Cambia el resultado? Si no cambia, el criterio estaba de adorno y no era un criterio. Si cambia mucho, escribiste el prompt correcto y acabas de encontrar la parte que carga el peso.
Lo que veo en las empresas donde esto funciona no es que escriban prompts más elegantes. Es que la persona que escribe el prompt tiene claro qué decisión depende del resultado. Cuando eso no está claro, ningún formato de prompt lo arregla —solo produce un documento bonito que nadie usa.