Iterar sobre lo que salió (y probar antes de compartir)

Una vendedora pide una propuesta de renovación para un cliente de hace seis años. El borrador tiene la estructura correcta y los precios bien, pero ocupa cuatro páginas, arranca con la historia de la empresa y saluda con “Estimado señor o señora”. El cliente prefiere una página y el trato es informal.

La tentación es abrir un chat nuevo y pegar el pedido otra vez, o escribir “no está bien, mejoralo”. Las dos opciones tiran lo que ya salió bien.

Iterar en la misma conversación

Iterar (iterate) es corregir sobre lo que ya hay. Si la salida está cerca, conviene seguir en la misma conversación, donde Claude tiene el pedido, el material y el borrador, y darle indicaciones concretas (specific feedback):

• Qué conservar: “Mantené la estructura y los precios tal cual.”
• Qué cambiar: “Llevalo a una página, tono informal, sacá la historia de la empresa, saludá por el nombre.”
• Por qué, si no es obvio: “Es un cliente de hace seis años, nos tuteamos.”

“Mejoralo” no dice en qué dirección. “Más corto” sin decir qué sacar puede cortar justo lo que servía. Cuanto más precisa la indicación, menos vueltas.

Refinar de a poco

Refinar (refine) suele llevar dos o tres vueltas. Algunas costumbres ayudan:

• Corregí primero lo grande (enfoque, estructura, largo) y después lo chico (palabras, tono de una frase).
• Si una parte ya quedó bien, decilo: “el segundo párrafo queda así”.
• Si después de varias vueltas sigue sin salir, el problema suele estar en el pedido original. Reescribilo con lo que aprendiste (para quién, para qué, cómo) en lugar de seguir parchando.

Empezar de cero tiene sentido en casos puntuales: cuando el enfoque entero estaba equivocado, o cuando la conversación ya es tan larga y desordenada que Claude empieza a perder indicaciones del principio (eso se trata en el dominio de selección de producto y modelo).

Probar un prompt antes de compartirlo

Otra forma de iterar es sobre un prompt que vas a reusar. Una asistente legal arma un prompt que resume contratos de alquiler en una tabla fija. Lo prueba con un contrato estándar reciente y sale perfecto. Ahora lo quiere pasar a ocho colegas que manejan desde licencias de dos páginas hasta contratos de ochenta con anexos, algunos escaneados y con numeración rara.

Un caso que salió bien no dice cómo se va a portar con los demás. Antes de compartir:

1. Juntá casos de prueba (test cases) variados: cortos, largos, con anexos, escaneados.
2. Incluí los casos límite (edge cases): los raros, los incompletos, los que rompen el formato habitual.
3. Corré el prompt sobre todos y anotá dónde falla.
4. Ajustalo donde falla y volvé a probar con el mismo grupo, para ver que lo que andaba siga andando.

Ese grupo de casos queda como referencia: cada vez que alguien cambie el prompt, se prueba de nuevo contra él. (Cómo cambiar una cosa por vez cuando algo deja de andar está en el dominio de diagnóstico.)

Las trampas típicas

Opción que aparece	Por qué está mal
Abrir un chat nuevo con el mismo pedido	Pierde lo que ya estaba bien y probablemente repite el problema
“No está bien, mejoralo”	No dice qué conservar ni qué cambiar
Descartar todo y hacerlo a mano	Tira un borrador que estaba cerca
Compartir el prompt porque anduvo una vez	Un caso no representa a los demás
Agregar “tené cuidado con los casos raros”	No reemplaza probarlos
Pedirle a Claude que confirme que el prompt sirve para todo	Es una opinión, no una prueba

En el examen

Si el escenario dice que la salida “tiene la estructura correcta” o “los números bien” pero falla en largo, tono o enfoque, la respuesta es iterar en la misma conversación con lo que se conserva y lo que cambia. Si el escenario habla de compartir o estandarizar un prompt que se probó con un solo caso, buscá la opción que lo prueba con un conjunto variado (incluidos los casos raros) y lo ajusta antes de distribuirlo.