El prompting efectivo para modelos de lenguaje no es un arte místico ni una colección de trucos de YouTube: según el framework publicado por Mira en mayo de 2026, se reduce a cuatro pilares concretos que cualquier desarrollador o profesional puede aplicar hoy con ChatGPT, Claude o Gemini.
En 30 segundos
- Talking to Transformers es un framework de 4 pilares publicado en 2026 para mejorar las técnicas de prompt engineering para LLMs en cualquier modelo.
- Pilar 1: articulá tu intención con lenguaje específico del dominio antes de abrir el chat.
- Pilar 2: guiá (railroadé) al modelo hacia donde querés con ejemplos y constraints claros.
- Pilar 3: usá el modelo como traductor entre dominios, formatos y lenguajes de programación.
- Pilar 4: leé lo que genera el modelo. Suena obvio. No lo es.
Qué es Talking to Transformers: los 4 pilares del prompting efectivo
Talking to Transformers es un framework de prompting publicado en mayo de 2026 por el blog de Mira que organiza las técnicas de prompt engineering para LLMs en cuatro principios operativos. No es una guía de “trucos secretos”, sino una metodología que trata al modelo como lo que es: un sistema probabilístico que necesita que vos acotés el espacio de posibilidades.
La premisa central es directa: estos modelos interpretan cada palabra que escribís y generan tokens siguiendo distribuciones de probabilidad. Si tu input es ambiguo, el output va a ser ambiguo. Si tu input es preciso, el modelo tiene más chances de ir a donde necesitás. No siempre llega, pero las probabilidades mejoran.
El framework aplica igual a ChatGPT, Claude, Gemini y cualquier LLM con el que trabajes. Los cuatro pilares son:
- Articular la intención con lenguaje específico del dominio
- Guiar (railroadear) al modelo en la dirección que querés
- Aprovechar el modelo como traductor universal de conceptos y código
- Leer y validar los outputs
Pilar 1: articulá tu intención con lenguaje específico del dominio
Ponele que le pedís a un modelo que te ayude con un bug. Si escribís “hay un error en mi código, arreglalo”, el modelo va a adivinar el contexto, el lenguaje, el tipo de error y la solución esperada. El cono de probabilidades se abre enorme. Si en cambio escribís “hay un bug en segment_summary.py: a veces resume un documento viejo en vez del nuevo. El error es intermitente”, el modelo tiene mucho menos espacio para improvisar.
El consejo de Mira es planificar la conversación antes de empezarla. Dos preguntas concretas antes de tipear: ¿cuál es exactamente mi intención/tarea/pregunta? ¿Qué información adicional necesito para acotar la respuesta que espero? No es burocracia, es la diferencia entre un back-and-forth de diez mensajes y uno de tres.
Eso sí: el framework hace una advertencia fuerte sobre el contexto largo. Y acá viene lo que le choca a mucha gente. Para más contexto, mirá nuestro artículo sobre seguridad en implementaciones corporativas.
El anti-patrón: por qué más contexto no siempre es mejor
Hay una creencia muy difundida de que cuanto más contexto le das al modelo al principio de la conversación, mejor va a responder. Según el framework de Mira, eso es incorrecto. El modelo se fija en cada palabra que escribís y la interpreta. Más palabras = más probabilidad de que el modelo agarre un hilo equivocado y lo siga durante toda la conversación.
La analogía que usa Mira es la del millonario excéntrico dictando una carta a un pasante no remunerado: breve, directo, con exactamente la información necesaria. “Hay un bug en segment_summary.py donde a veces resume un documento viejo. El error es intermitente. ¿Qué puede estar causando esto?” Eso es todo. Sin el historial del proyecto, sin los diez commits anteriores, sin la descripción del equipo.
¿Por qué funciona así? Porque los transformers aprenden patrones de asociación. Un input largo tiene más “anzuelos” para que el modelo se enganche en algo irrelevante. El overfitting no es solo un problema de entrenamiento de modelos: también es un riesgo al momento de escribir prompts.
Pilar 2: guiá al modelo (railroading) hacia donde querés ir
Un modelo de lenguaje genera la respuesta más probable dado tu input. Si no le das pistas sobre el formato o dirección que esperás, va a elegir la ruta estadísticamente más común para ese tipo de pregunta. A veces eso es exactamente lo que necesitás. Otras veces no.
El railroading es el conjunto de técnicas para apretar ese “probability cone” y orientar la respuesta:
- Few-shot examples: mostrar uno o dos ejemplos del formato o estilo de respuesta que esperás. “Quiero que la respuesta tenga este formato: [ejemplo]” es más efectivo que describir el formato en abstracto.
- Constraints explícitos: “respondé en menos de 200 palabras”, “solo código Python sin explicaciones”, “listá exactamente 5 opciones con sus trade-offs”.
- Rol + contexto mínimo: “Sos un DBA revisando una query lenta. Dame tres hipótesis sobre por qué tarda más de 10 segundos.” El rol acota el vocabulario y la perspectiva sin necesitar parrafadas de contexto.
La diferencia entre un prompt con railroading y uno sin él es enorme. Sin constraints, el modelo puede darte una respuesta de 800 palabras cuando necesitabas 50, o código en JavaScript cuando necesitabas Python, o una explicación teórica cuando necesitabas una solución práctica. Para más detalles técnicos, consultá nuestro artículo sobre prompts en ChatGPT.
Pilar 3: el modelo como traductor universal de conceptos y código
Este pilar es el más subestimado. Los transformers fueron entrenados con texto de dominios completamente distintos: código, papers científicos, foros de soporte, documentación técnica, literatura. Eso los hace buenos para mapear conceptos entre mundos que normalmente no se hablan.
Algunos usos concretos donde esto brilla:
- Traducir código entre lenguajes: “Convertí esta función de Python a Go, respetando el manejo de errores idiomático de cada lenguaje.”
- Traducir entre niveles de abstracción: “Explicame este algoritmo como si fuera una receta de cocina” y luego “ahora explicámelo como lo haría un paper de sistemas distribuidos.”
- Mapear conceptos entre dominios: “¿Cuál sería el equivalente de dependency injection en el contexto de arquitectura de datos?”
- Reformatear datos: pegar JSON desordenado y pedir que lo convierta a CSV, Markdown table o SQL INSERT.
La clave es reconocer que el modelo tiene acceso a muchos “idiomas” simultáneamente (lenguajes de programación, jergas técnicas, formatos de datos) y puede actuar de puente entre ellos si se lo pedís de forma explícita.
Pilar 4: leé los outputs (no es opcional)
El framework de Mira termina con algo que parece una obviedad y claramente no lo es, porque lo menciona con énfasis: leé lo que generó el modelo. El texto lo dice con toda la ironía del caso.
Leer el output no es solo revisar si “suena bien”. Implica:
- Ejecutar o al menos revisar línea por línea el código generado antes de pegarlo en producción
- Verificar que las afirmaciones del modelo tienen sentido en tu contexto específico
- Detectar si el modelo reinterpretó tu pregunta y respondió algo distinto a lo que pediste
- Identificar alucinaciones: funciones que no existen, APIs desactualizadas, fechas incorrectas
Subís el código generado por el modelo directamente a producción, todo anda bien en staging, y en producción falla porque el modelo usó una versión de librería que tenés localmente pero no en el servidor, con un método deprecado que en tu entorno todavía funciona pero en el CI ya no, y nadie revisó la salida más allá del “parece correcto”.
El error acá no es del modelo. Es del workflow.
Tabla comparativa: prompt sin técnicas vs prompt con framework
| Dimensión | Prompt sin técnicas | Prompt con Talking to Transformers |
|---|---|---|
| Intención | Vaga o implícita | Explícita con lenguaje del dominio |
| Contexto | Largo, sin filtrar | Mínimo y relevante |
| Formato esperado | No especificado | Definido con ejemplos o constraints |
| Iteraciones necesarias | 5-10 por tarea típica | 1-3 por tarea típica |
| Validación del output | Rara o ausente | Parte del workflow |
| Riesgo de alucinación no detectada | Alto | Bajo (por revisión explícita) |
Errores comunes al hacer prompts y cómo evitarlos
Dar demasiado contexto al inicio
El error más frecuente. Pegar el archivo completo, el historial del proyecto y los tres tickets relacionados antes de hacer la pregunta. El modelo lo procesa todo, se engancha en algo irrelevante y la respuesta se va por las ramas. La corrección: empezá con el mínimo viable de información y agregá contexto solo si el modelo lo pide o si la primera respuesta se va lejos.
No especificar el formato de respuesta
Si necesitás código, pedí código. Si necesitás una lista, pedí una lista. Si necesitás un análisis de 3 puntos, pedí exactamente eso. Los modelos tienen un sesgo hacia respuestas conversacionales largas porque eso es lo que predomina en los datos de entrenamiento. Si no especificás, el default suele ser más texto del que necesitás. Mirá nuestro artículo sobre cómo funcionan los modelos de lenguaje para profundizar en esto.
Cambiar el tema sin avisar
En conversaciones largas, si cambiás de tarea sin decirlo explícitamente, el modelo mantiene el contexto anterior y puede mezclar las dos cosas. “Ahora olvidate de lo anterior y vamos a hablar de X” es una instrucción válida y útil. O mejor: empezá un chat nuevo para tareas no relacionadas.
Asumir que el modelo validó su respuesta
Los modelos no comprueban sus outputs contra realidad externa. Si genera una función de Python que llama a un método que no existe en la versión que vos usás, lo hace con la misma confianza que si fuera correcto. ¿Alguien verificó eso de forma independiente? El modelo, nunca. Vos tenés que ser ese filtro.
Usar prompts genéricos de internet sin adaptarlos
Los “mega-prompts” que circulan en redes suelen estar diseñados para casos genéricos o para impresionar en demos. Rara vez se ajustan bien a un caso de uso específico. Tomá los principios (rol, constraints, ejemplos) y construí tu prompt desde cero con el lenguaje de tu dominio.
Cómo aplicar Talking to Transformers en práctica real
Para debugging de código el workflow es: describir el síntoma concreto + el contexto mínimo (archivo, lenguaje, comportamiento esperado vs observado) + pedir hipótesis ordenadas por probabilidad. No pegar el stack trace completo de entrada.
Para análisis de datos: describir el dataset con sus columnas relevantes, el objetivo del análisis y el formato de output que necesitás (código, tabla, resumen ejecutivo). Un ejemplo del input y output esperado acorta mucho el camino.
Para escritura técnica: dar el contexto del lector objetivo, el nivel de detalle esperado y un ejemplo de tono si tenés uno. “Escribí para un desarrollador senior que ya conoce Docker pero nunca usó Kubernetes” es mucho más útil que “explicá Kubernetes”. Para profundizar en esto, mirá nuestro artículo sobre herramientas IA de Google.
En todos los casos, el workflow es el mismo: intent claro, contexto mínimo, constraints explícitos, y revisión del output antes de usarlo. Cuatro pasos que se internalizan rápido y cambian mucho la calidad de lo que recibís.
Preguntas Frecuentes
¿Qué son las técnicas de prompt engineering para LLMs?
Son métodos para formular instrucciones a modelos de lenguaje (ChatGPT, Claude, Gemini) de forma que las respuestas sean más precisas y útiles. Incluyen especificar el rol del modelo, definir el formato de respuesta, usar ejemplos (few-shot), acotar el contexto y revisar los outputs generados.
¿Por qué mis prompts largos no generan buenos resultados?
Porque los modelos interpretan cada palabra del input y pueden engancharse en información irrelevante dentro de un bloque de contexto largo. Según el framework Talking to Transformers de 2026, el enfoque correcto es empezar con el mínimo de información necesaria y agregar contexto solo cuando el modelo lo requiera.
¿Cómo validar que el modelo entendió correctamente mi solicitud?
La forma más directa es revisar el output con criterio propio antes de usarlo. Si el modelo generó código, revisá la lógica línea por línea. Si generó texto, verificá que las afirmaciones sean correctas. También podés pedirle que reformule tu pregunta para confirmar que la entendió bien antes de responderla.
¿Cuáles son los errores más comunes al hacer prompts?
Los principales son: dar demasiado contexto al inicio, no especificar el formato de respuesta, cambiar de tema sin avisar al modelo, y no revisar los outputs antes de usarlos. Usar prompts genéricos copiados de internet sin adaptarlos al dominio propio también genera resultados pobres.
¿El framework Talking to Transformers aplica a todos los modelos?
Sí. Los cuatro pilares (intención clara, railroading, traducción entre dominios y validación de outputs) aplican a cualquier LLM moderno: ChatGPT, Claude, Gemini, Llama o cualquier modelo desplegado vía API. Los principios son sobre cómo funcionan los transformers en general, no sobre características específicas de un modelo.
Conclusión
Talking to Transformers no inventa nada radicalmente nuevo, pero organiza bien algo que mucha gente hace de forma intuitiva e inconsistente. Los cuatro pilares son aplicables desde hoy, en cualquier modelo, sin herramientas adicionales. El más ignorado sigue siendo el cuarto: leer lo que genera el modelo. No como cortesía, sino como parte del workflow.
Si aplicás solo una cosa de este framework, que sea el primero y el último pilar juntos: pensá qué querés exactamente antes de escribir el prompt, y verificá que lo que recibís es realmente eso. El resto viene solo.