Tu primer prompt casi nunca funciona. El segundo tampoco. La cuestión no es si vas a iterar. La cuestión es si tus iteraciones de verdad te van a hacer avanzar o solo van a quemar créditos mientras te convences de que estás progresando.

La mayoría de las guías de ingeniería de prompts tratan la iteración como una virtud en sí misma, como si el hecho de retocar y probar garantizara mejoras. Pero habla con cualquiera que haya pasado horas reales afinando prompts para sistemas en producción y escucharás otra historia. A veces la iteración se acumula. A veces se descontrola. Saber distinguirlo es lo que separa un refinamiento estratégico de una frustración cara.

La mecánica de una iteración útil

Cada iteración de un prompt cambia algo. Las útiles cambian lo que importa.

Cuando obtienes una salida que no da en el blanco, tu instinto puede ser añadir más instrucciones, más ejemplos, más restricciones. Pero sumar capas es solo una herramienta del arsenal. Como describió un desarrollador en Hacker News su proceso: “every time the model does something undesired, even minor I add an explicit rule in the system prompt” (minimaxir, Hacker News). Este enfoque funciona, pero también señaló que las reglas acumuladas pueden “balloon quickly” a medida que aparecen problemas durante las pruebas.

El enfoque contrario también funciona. A veces, quitar instrucciones da mejores resultados que añadirlas. Un profesional observó: “Sometimes even giving them ‘drunken’ prompts with just a few keywords is enough… If you specify too much they tend to hyperfixate on things” (birracerveza, Hacker News). Las restricciones estrictas pueden hacer que el modelo estreche el foco hasta el punto de perder el objetivo real.

Entonces, ¿hacia qué lado tiras? Depende del modo de fallo.

Diagnosticar antes de cambiar

¿Salida demasiado genérica? Añade especificidad. ¿Salida demasiado literal? Quita restricciones. ¿Salida inconsistente? Añade estructura. ¿Salida repetitiva? Reduce ejemplos.

Relaciona el fallo con el arreglo. Los cambios al azar dan resultados al azar, y los resultados al azar no te enseñan nada sobre qué fue lo que realmente movió la aguja.

Quienes se vuelven buenos en esto tratan la iteración como prueba de hipótesis, no como ensayo y error. Cada cambio pone a prueba una suposición concreta sobre por qué falló la última salida. Ese marco mental importa porque te obliga a articular qué crees que salió mal antes de cambiar nada.

Cuándo iterar y cuándo empezar de cero

Iterar asume que tu prompt actual tiene una base que merece la pena. Esa suposición no siempre es cierta.

Hay un patrón típico: la gente refina un prompt mediocre durante quince iteraciones, añadiendo cláusulas, ejemplos y restricciones hasta que el prompt se convierte en un enredo de parches acumulados. Consiguen algo que funciona, más o menos, a veces. Pero habrían llegado antes si hubieran tirado el original y replanteado el problema desde cero.

La falacia del coste hundido pega fuerte en la ingeniería de prompts. Has pasado veinte minutos con este prompt. Casi funciona. Un ajuste más y listo. Pero si el encuadre estaba mal desde el principio, ningún refinamiento lo arregla.

Reinicia cuando:

• Tu prompt ya pasa de dos párrafos de instrucciones
• Estás añadiendo excepciones para manejar excepciones
• La descripción de la tarea principal ya no se parece a tu objetivo real
• Las salidas van a peor, no a mejor, pese a cambios lógicos

Un desarrollador en Hacker News lo dijo sin rodeos: “I realized the real problem was that I hadn’t figured out what I wanted in the first place” (Kiyo-Lynn, Hacker News). Antes de iterar, tienes que saber cómo se ve el éxito. Si no puedes describir con claridad la salida ideal, tu prompt tampoco puede.

El protocolo del reinicio

Cuando reinicies, no te limites a borrar y reescribir. Primero extrae lo que sí funcionó de tus intentos fallidos.

Quizá tu especificación de formato era buena aunque el encuadre de la tarea estuviera torcido. Quizá tus ejemplos demostraban lo equivocado, pero la instrucción de tono acertó. Rescata las piezas que pintaban bien. Tira el andamiaje que construiste alrededor de los errores.

Luego escribe tu prompt desde la salida hacia atrás. Empieza por exactamente lo que quieres ver. Describe esa salida en lenguaje llano. Construye instrucciones que producirían ese resultado específico. Esta inversión suele producir prompts más limpios que intentar especificar la transformación desde la entrada hasta la salida.

Llevar registro de lo que funciona (sin complicarlo de más)

Necesitas un sistema. No necesitas un sistema complejo.

La opción más simple: un documento vivo. Cada intento de prompt recibe un número, el texto del prompt, una muestra de salida y una evaluación en una línea. “Mejor estructura, pero perdió el tono conversacional.” “Formato perfecto, pero contenido demasiado superficial.” “Este sí funcionó.”

Como señaló un profesional con experiencia: “Practice. Keep notes on what works for you. Pay attention to what other people do and take the best ideas” (PaulHoule, Hacker News). El hábito de tomar notas importa más que el formato concreto.

Qué registrar

Para cada iteración, captura:

• Qué cambiaste respecto a la versión anterior
• Por qué pensabas que ese cambio ayudaría
• Qué cambió realmente en la salida
• Si el cambio te acercó o te alejó de tu objetivo

Ese último punto es crucial. A veces un cambio produce una salida distinta sin producir una salida mejor. Si no evalúas explícitamente la dirección, puedes iterar indefinidamente sin progreso: solo diferencia.

El problema de comparar

Aquí va la verdad incómoda: comparar salidas de prompts es más difícil de lo que parece. El mismo prompt puede producir salidas muy distintas en ejecuciones consecutivas, lo que significa que la mejora que crees ver podría ser solo variabilidad.

Un comentarista capturó esta frustración: “if you’re ‘tweaking’ the prompt what you’re really doing is just re-rolling the dice until you land in a neighborhood closer” to what you want (ianbicking, Hacker News). Sostiene que las técnicas solo constituyen progreso real cuando funcionan en múltiples casos de prueba, en lugar de producir un único resultado exitoso.

Para prompts en producción, esto importa muchísimo. Un prompt que funciona de maravilla una vez y falla tres es peor que un prompt que funciona de manera aceptable siempre. Probar con un solo ejemplo no te dice nada sobre consistencia. Probar con muchos ejemplos sí, pero lleva más tiempo.

El punto medio: prueba los cambios contra tus tres entradas más representativas. Si el cambio mejora las tres, probablemente has encontrado algo real. Si mejora una mientras empeora otra, seguramente solo estás redistribuyendo la variabilidad.

La trampa de los rendimientos decrecientes

Cada prompt tiene un techo. Si lo empujas más allá, estás optimizando para ruido.

Las primeras iteraciones suelen producir mejoras importantes. Los prompts flojos pasan a ser funcionales. Los funcionales pasan a ser fiables. Pero llega un punto en el que las ganancias se encogen hasta el punto de que no puedes distinguir de forma fiable la señal del azar.

Un usuario de Hacker News describió chocar contra esta pared mientras iteraba con agentes de IA: they “just spin and spin, burn 30 dollars for one prompt” (taosx, Hacker News). La automatización empeoró la trampa. Cuando iterar es gratis, iteras para siempre. Cuando cuesta dinero o tiempo, sientes los rendimientos decrecientes en la cartera o en la agenda.

Reconocer el techo

Has llegado a rendimientos decrecientes cuando:

• Los cambios producen salidas diferentes, pero no claramente mejores
• Repites el mismo tipo de cambio una y otra vez (más específico, luego más específico otra vez, luego aún más específico)
• La calidad oscila en lugar de subir
• Pasas más tiempo decidiendo si una salida es mejor que probando prompts

En este punto, tienes tres opciones. Aceptar la salida actual como suficientemente buena. Cambiar tu enfoque por completo. O reconocer que la tarea puede estar más allá de lo que el prompting, por sí solo, puede lograr.

Cuándo parar

La habilidad más difícil en la iteración de prompts es saber cuándo parar. No porque hayas alcanzado la perfección, sino porque seguir afinando ya no mejorará tus resultados de manera significativa.

Otro comentarista tuvo éxito al limitar explícitamente sus ambiciones: “Instead of over optimizing my prompt I just try to find the minimal amount of representation to get the llm to understand my problem” (someoneontenet, Hacker News). Lo mínimo suficiente suele ser mejor que lo teóricamente óptimo.

Lo suficientemente bueno tiene una ventaja de productividad. Cada hora que pasas optimizando un prompt que ya funciona es una hora que no dedicas a otra cosa. El prompt perfecto importa menos de lo que crees, sobre todo en tareas donde vas a revisar la salida de todas formas.

Meta-Prompting: hacer que la IA itere por ti

Hay un atajo que a veces funciona mejor que iterar a mano.

En lugar de refinar tu prompt directamente, describe tu objetivo a una IA y pídele que genere un prompt para ese objetivo. Luego usa ese prompt generado en una conversación nueva, sin contexto sobre cómo lo obtuviste.

Un profesional documentó este enfoque: “Ask Claude to come up with LLM prompt to solve problem” primero, y luego usar ese prompt generado en una conversación nueva. Vio una mejora de 148 a 428 palabras usando solo 27 palabras de meta-instrucción, en lugar de refinar el prompt original directamente (slt2021, Hacker News).

Esto funciona porque los modelos de IA suelen estructurar los prompts de manera diferente a como lo hacen los humanos. Pueden incluir encuadre o instrucciones que no se te ocurrirían. La conversación nueva importa porque elimina la contaminación de contexto que se acumula durante la iteración manual.

El meta-prompting no siempre es mejor. Pero cuando estás atascado, te ofrece otro ángulo de ataque.

La iteración como aprendizaje

Los prompts que escribas dentro de seis meses serán mejores que los que escribas hoy. No porque te hayas memorizado mejores plantillas, sino porque habrás interiorizado patrones a base de repetición.

Cada iteración te enseña algo sobre cómo los modelos de lenguaje interpretan las instrucciones, incluso cuando la iteración en sí no mejora tu salida. Con el tiempo, desarrollas intuiciones sobre elección de palabras, estructura, especificidad y ejemplos que hacen que tus primeros borradores sean mejores.

La mentalidad de iteración va más allá de prompts individuales. Cada proyecto que implica prompting te enseña algo transferible. Los patrones que funcionaron para generar textos de marketing pueden influir en cómo abordas prompts de revisión de código. Los modos de fallo que encontraste en un dominio reaparecen en otros.

Como observó un comentarista: “just practice. With different systems; sd, mj, chatgpt, gpt3, gptj etc.” (anonzzzies, Hacker News). La amplitud de experiencia importa tanto como la profundidad en un solo sistema, en parte porque distintos modelos revelan distintos aspectos de cómo funciona el prompting.

La ingeniería de prompts es una disciplina empírica disfrazada de lingüística. Aprendes haciendo y observando, no leyendo reglas y aplicándolas. Las iteraciones que se sienten como tiempo perdido a menudo alimentan intuiciones que usarás años después en problemas completamente distintos.

Así que itera. Lleva registro de lo que funciona. Nota cuándo estás dando vueltas. Reinicia cuando lo necesites.

Pero también recuerda que el objetivo no es un prompt perfecto. El objetivo es una salida que logre lo que necesitabas. A veces, lo suficientemente bueno de verdad es suficiente, y la mejor iteración es la que haces cuando decides parar.