--- title: Mega-prompts vs micro-prompts: cuándo conviene ir a lo grande o a lo pequeño description: ¿Deberías escribir mega-prompts detallados o mantenerlo breve? Aprende cuándo funciona cada enfoque y cómo elegir la longitud de prompt adecuada para tu tarea. date: February 5, 2026 author: Robert Soares category: prompt-engineering --- La semana pasada me pasé tres horas escribiendo el prompt perfecto. Cada caso límite cubierto. Cada regla de formato especificada. Doce párrafos de instrucciones detalladas para una plantilla de correo sencilla. El resultado fue peor que un prompt de dos frases que había improvisado el día anterior. Esto pasa más a menudo de lo que la gente admite. Damos por hecho que más detalle significa mejor resultado, que los prompts más largos demuestran más pericia, que la minuciosidad siempre gana. A veces sí. Pero a veces todo ese cuidado solo confunde al modelo o infla tu factura de la API sin ningún beneficio. La verdadera pregunta no es qué enfoque es el "correcto". Es saber cuándo cada uno ayuda de verdad. ## La paradoja de la longitud Esto es lo que la investigación sigue encontrando: la longitud del prompt y la calidad del resultado tienen una relación complicada. Un [debate de Hacker News sobre ingeniería de prompts](https://news.ycombinator.com/item?id=37473992) captó bien esta tensión. Investigadores que intentaban entender la conexión entre longitud y rendimiento encontraron algo contraintuitivo: "Prompt length would play a big factor in the performance of this approach. In practice, though, we discovered that it's actually not as big a factor as we predicted." En sus pruebas, un prompt de 410 tokens y uno de 57 tokens funcionaron razonablemente bien. Uno de 88 tokens rindió peor. La longitud por sí sola no explicó casi nada. ¿Qué importó de verdad? La precisión. Esos mismos investigadores concluyeron que "the relationship between performance of the estimation and the prompt structure is less about length, and more about 'ambiguity.'" Las formulaciones abiertas empeoraron los resultados independientemente del número de palabras. Esto coincide con lo que los profesionales siguen descubriendo. [Según el análisis de Ruben Hassid](https://ruben.substack.com/p/long), "Prompts exceeding 500 words generally show diminishing returns in terms of output quality." Y empeora cuanto más te alargas: "For every 100 words added beyond the 500-word threshold, the model's comprehension can drop by 12%." Esas cifras varían según el modelo y la tarea. Pero el principio se mantiene. ## Cómo son de verdad los prompts largos Andrew Ng y su equipo en DeepLearning.AI llaman "mega-prompts" a los prompts detallados. Según su [investigación sobre sofisticación de prompts](https://staging.deeplearning.ai/the-batch/from-prompts-to-mega-prompts/), son instrucciones que pueden ocupar "1 to 2 pages long" con una guía explícita que cubre cada aspecto de la tarea. Ng sostiene que la mayoría de equipos no aprietan lo suficiente: "I still see teams not going far enough in terms of writing detailed instructions." Un mega-prompt bien construido podría incluir: - Definición específica del rol y la experiencia - Contexto de fondo sobre la situación - Varios ejemplos del resultado deseado - Reglas de formato explícitas - Restricciones y cosas que evitar - Criterios de calidad para la respuesta Así se ve uno en la práctica: ``` Eres un redactor publicitario B2B senior especializado en software empresarial. Tu lector objetivo es un VP de Marketing de una empresa mediana que ya ha sufrido a proveedores de IA que prometían de más. Escribe texto de producto para DataSync, una plataforma de integración de datos. Diferenciador clave: somos honestos sobre las limitaciones. Nuestra herramienta resuelve el 80% de las integraciones a la perfección, y somos claros con el 20% que requiere trabajo a medida. Requisitos: - Titular de menos de 12 palabras, centrado en el beneficio - Subtítulo que reconozca el escepticismo de nuestra audiencia - Tres viñetas sobre capacidades - Una viñeta sobre limitaciones conocidas (esto genera confianza) - CTA centrado en verlo funcionar, no en comprar Tono: seguro, pero nunca exagerado. Sin "revolucionar" ni "transformar". ``` Ese prompt deja poco al azar. La IA sabe exactamente lo que se espera. ## Cómo son de verdad los prompts cortos En el otro extremo está el micro-prompt. Breve. Enfocado. Una tarea a la vez. ``` Escribe un titular para una plataforma de integración de datos honesta. Máx. 10 palabras. ``` Misma tarea general. Una fracción de las palabras. La IA rellena todo lo demás con valores razonables por defecto. Un desarrollador en [Hacker News describió su evolución hacia la brevedad](https://news.ycombinator.com/item?id=38657029): "I've stopped writing well-formed requests/questions and now I just state things like: 'sed to replace line in a text file?'" A pesar de la entrada tan escueta, el modelo siguió dando respuestas útiles. No todas las tareas necesitan un andamiaje elaborado. ## La dimensión oculta del coste Hay algo de lo que casi nadie habla cuando debate la longitud del prompt: cada token cuesta dinero. Con la [tarificación actual de la API de OpenAI](https://pricepertoken.com/pricing-page/provider/openai), GPT-4o cobra $2.50 por millón de tokens de entrada y $10.00 por millón de tokens de salida. Puede parecer trivial para una petición. Pero escala eso. Un prompt de 500 palabras son aproximadamente 650 tokens. Uno de 50 palabras son aproximadamente 65 tokens. Si haces 10.000 llamadas a la API al día, la diferencia entre mega y micro se acumula rápido: - Prompts de 650 tokens: 6.5 million tokens = $16.25/día en costes de entrada - Prompts de 65 tokens: 650.000 tokens = $1.63/día en costes de entrada Eso son casi $5.300 al año de ahorro solo en tokens de entrada. Y eso sin contar la salida más larga que a menudo desencadenan los prompts detallados. La latencia también se acumula. Los prompts largos tardan más en procesarse. Si tu aplicación necesita respuestas ágiles, ese prompt de sistema de 500 palabras mete un retraso perceptible en cada petición. Para procesamiento por lotes o prompts de un solo uso, el coste importa menos. Para sistemas en producción que manejan miles de peticiones, importa muchísimo. ## Cuando el detalle perjudica La suposición de que "más es mejor" se rompe de formas concretas y predecibles. Primero, está el problema de perderse en el medio. El [análisis de Ruben Hassid sobre la longitud del prompt](https://ruben.substack.com/p/long) lo dice sin rodeos: "The single greatest threat to output quality is prompt bloat." Cuando los prompts se hacen largos, la información del medio tiende a pasarse por alto. Requisitos críticos enterrados en el párrafo ocho podrían no existir. Segundo, se cuelan contradicciones. Si escribes suficientes instrucciones, tarde o temprano dirás "sé conciso pero minucioso" o "sé creativo pero sigue este formato exacto". El modelo no puede cumplir ambas. Elige una e ignora la otra, o produce un resultado confuso intentando partir la diferencia. Tercero, está la carga cognitiva. Un profesional en un [hilo de Hacker News sobre guías de prompts](https://news.ycombinator.com/item?id=44182188) contó su experiencia: "Sometimes I get the feeling that making super long and intricate prompts reduces the cognitive performance of the model." ¿Su solución? "My usage has converged to making very simple and minimalistic prompts and doing minor adjustments after a few iterations." El modelo no es un colega humano que agradece el contexto. Es un detector de patrones. Demasiados patrones que encajar significa peor encaje en general. ## Cuando el detalle sí ayuda Nada de esto significa que los mega-prompts estén mal. Resuelven problemas reales. Cuando el resultado va directo a clientes sin revisión, necesitas control. Un prompt flojo que de vez en cuando produce texto fuera de marca está bien para borradores. Es un desastre para campañas de correo automatizadas. Cuando vas a reutilizar el prompt cientos de veces, la inversión compensa. Pasar dos horas perfeccionando un prompt que vas a ejecutar 5.000 veces es una buena cuenta. Pasar dos horas en una petición de una sola vez no lo es. Cuando varias partes necesitan coherencia, un solo prompt gana a varios. Una página de aterrizaje necesita titular, subtítulo, cuerpo y CTA que funcionen juntos. Micro-prompts separados pueden ser buenos por separado pero chocar al juntarlos. Otro desarrollador en el [mismo hilo de Hacker News](https://news.ycombinator.com/item?id=38657029) compartió su enfoque: "Some of my best system prompts are >20 lines of text, and _all_ of them are necessary." Su método para construir esos prompts era revelador: "every time the model does something undesired, even minor I add an explicit rule in the system prompt to handle it." La longitud venía de necesidades reales, no de una minuciosidad teórica. Esa es la distinción clave. Los prompts largos que crecen orgánicamente a partir de fallos reales funcionan. Los prompts largos escritos para cubrir casos límite hipotéticos a menudo solo añaden ruido. ## La alternativa en cadena Hay un camino intermedio que evita la trampa del mega-prompt y, al mismo tiempo, mantiene el control que necesitas. [Paul Shirer argumenta en su análisis de estrategias de prompts](https://www.linkedin.com/pulse/mega-prompts-hype-chain-better-paul-shirer-hqbmc) que los prompts en cadena superan a los mega-prompts en la mayoría de tareas. Su razonamiento: "You aren't stuck with the result of a mega prompt that might have gone astray due to an overlooked detail." Con cadenas, cada paso es una instrucción corta y enfocada: 1. "Genera cinco ideas de titular para este producto." 2. "Toma el concepto #3 y escribe tres variaciones." 3. "Ahora escribe texto de apoyo para la mejor variación." 4. "Añade un CTA que encaje con el tono del titular." Cada salida informa la siguiente. Si el paso dos sale mal, lo corriges antes del paso tres, no después de que haya corrido todo el mega-prompt. Como dice Shirer, las cadenas funcionan como "inching closer with each shot, adjusting your aim according to where the last arrow landed." La contrapartida es la velocidad. Las cadenas requieren varias idas y vueltas. Para uso interactivo, está bien. Para procesar por lotes miles de elementos, el sobrecoste se acumula. ## Leer las señales ¿Cómo sabes si tu prompt es demasiado largo o demasiado corto? Demasiado largo: - La salida ignora instrucciones que incluías a propósito - Repites el mismo punto con palabras distintas - Te pillas contradiciendo secciones anteriores - La mayoría de frases son "por si acaso" en vez de esenciales - La IA parece confundida sobre lo que quieres en realidad Demasiado corto: - La salida es genérica cuando necesitabas algo específico - Las mismas correcciones de seguimiento cada vez - Suposiciones equivocadas sobre audiencia, tono o formato - Sigues añadiendo "también incluye..." como un añadido de última hora El patrón para la mayoría de tareas: empieza corto, añade solo lo necesario en función de fallos reales, para cuando el resultado sea lo bastante bueno. ## Un marco que funciona Olvida el debate de mega vs micro. Hazte estas preguntas. ¿Qué tan importante es este resultado? Los resultados críticos que salen directos justifican prompts más detallados. Los borradores y la exploración no los necesitan. ¿Qué tan reutilizable es este prompt? Veinte usos justifican treinta minutos de trabajo. Un uso justifica dos minutos. ¿Puedes iterar? Si puedes volver a ejecutar fácilmente con ajustes, empieza corto. Si es un trabajo por lotes que tiene que salir bien a la primera, adelanta el detalle. ¿Cuál es el contexto de coste? Un uso alto de la API significa que cada token cuenta. Una sola petición significa que la diferencia es insignificante. ¿Sabes exactamente qué quieres? La certeza favorece prompts detallados. La exploración favorece prompts cortos con iteración rápida. ## La prueba de relevancia Esta es la regla más simple posible: mira cada frase de tu prompt y pregúntate si quitarla cambiaría el resultado. Si sí, déjala. El contexto relevante mejora los resultados. Si no, córtala. El relleno irrelevante solo diluye la atención. Un profesional en una [discusión sobre ingeniería de prompts](https://news.ycombinator.com/item?id=44182188) lo resumió perfectamente: "Irrelevant context is worse than no context, but it doesn't mean a long prompt of *relevant* context is bad." Esa distinción importa más que cualquier guía de recuento de palabras. Un prompt de 50 palabras lleno de relleno rinde peor que un prompt de 300 palabras en el que cada palabra se gana su sitio. Un prompt de 300 palabras lleno de relleno rinde peor que un prompt enfocado de 50 palabras. Mide por relevancia, no por longitud. ## Lo que realmente cambia el comportamiento Los prompts más efectivos comparten una cualidad que no tiene nada que ver con la longitud. Reducen la ambigüedad. "Escribe algo bueno" es corto pero inútil. "Escribe una descripción de producto de 100 palabras para una botella de agua de acero inoxidable, dirigida a aficionados al aire libre, enfatizando la durabilidad" es más largo, pero cada palabra cumple una función. La investigación lo respalda. Volviendo a aquel [análisis de Hacker News](https://news.ycombinator.com/item?id=37473992), la idea central era que el prompt engineering va de precisión lingüística: "say what you mean in the most linguistically precise way possible." No más palabras. No menos palabras. Las palabras correctas. Algunas tareas necesitan muchas palabras correctas. Otras necesitan pocas. La habilidad no es elegir bando en el debate mega-vs-micro. Es aprender a escribir exactamente lo suficiente para cada situación, y reconocer en qué situación estás de verdad. Empieza con lo que la tarea necesita. Añade lo que tus fallos te enseñan. Detente cuando el resultado sea lo bastante bueno. La longitud de prompt que salga es la longitud que era la correcta.