Refinar de a poco: ejemplos, tests y entrevista

La primera versión casi nunca es la definitiva. Lo que distingue a quien trabaja bien con Claude Code es cómo da el feedback: qué técnica elige según el tipo de problema. El examen plantea cuatro situaciones y cada una tiene su herramienta.

Cuál técnica para cuál problema

Situación	Técnica
Sabés exactamente qué transformación querés, pero la prosa se interpreta distinto cada vez	2 o 3 ejemplos de entrada y salida (input/output examples)
Cada arreglo rompe un caso que andaba	Iteración guiada por tests (test-driven iteration)
No conocés el dominio y no sabés qué preguntar	Patrón de entrevista (interview pattern)
Hay varios problemas para corregir	Agrupar los que interactúan, separar los independientes

Ejemplos concretos

Si describiste en prosa cómo reformatear un registro y Claude lo hace distinto en cada corrida, más prosa no arregla nada. Mostrale el antes y el después con 2 o 3 ejemplos: el modelo generaliza mejor desde ejemplos que desde descripciones. Si después maneja bien los casos estándar y falla con los nulos, sumá un ejemplo que muestre justo ese caso; no vuelvas a explicarlo en prosa.

Tests primero

Cuando cada cambio a un parser de tarifas de envío rompe otro tramo que antes andaba, el problema es que no hay con qué verificar todos los casos a la vez. La iteración guiada por tests es:

1. escribir primero la suite a partir de los requisitos: comportamiento esperado, casos borde (edge cases) como archivos vacíos o montos en blanco, y requisitos de rendimiento (un archivo de tamaño real que tiene que procesarse en menos de 5 minutos);
2. implementar;
3. en cada vuelta, pasarle a Claude los fallos concretos: qué test falló, qué esperaba y qué obtuvo.

“Algunos tests fallan” no le dice nada. Y los tests tienen que salir de los requisitos: escritos después mirando el código, verifican lo que el código hace, bug incluido.

La entrevista

Si nunca diseñaste una capa de caché, no vas a poder dar ejemplos útiles ni escribir tests de invalidación, porque no sabés qué puede salir mal. En el patrón de entrevista le pedís a Claude que te haga preguntas antes de implementar: estrategia de invalidación, tiempo de vida, consistencia, qué pasa cuando muchos pedidos llegan juntos. Sirve para descubrir consideraciones que un experto plantearía y vos no.

La regla para elegir: dominio desconocido, entrevista; transformación conocida con interpretación inconsistente, ejemplos.

Varios problemas a la vez

Si dos problemas interactúan (interacting issues), como un campo errorCode de la respuesta que cambia el formato del log, van juntos en un mensaje detallado para que el arreglo sea coherente. Corregirlos por separado hace que el segundo arreglo choque con el primero. Un problema independiente (un nombre de variable) va aparte. El orden por sencillez no importa.

Las trampas típicas

• Responder a la inconsistencia con una descripción más larga.
• Usar la entrevista cuando ya sabés lo que querés.
• Tomar la primera salida como valor esperado de los tests: congela sus errores.
• Tests atados a detalles internos, que se rompen con cada refactor.
• Cambiar los tests para que pasen.
• Reescribir todo cuando fallan 3 de 24 tests.

En el examen

Preguntate qué falta: ¿claridad sobre el resultado (ejemplos), una red que detecte regresiones (tests) o conocimiento del dominio (entrevista)? Y si hay varios problemas, ¿se afectan entre sí?