Cómo escribirle a un agente de programación para que no se equivoque
Los agentes fallan más por instrucciones incompletas que por falta de capacidad. Cuatro partes que casi siempre faltan, y cómo se ven cuando están.
Cuando un agente de programación entrega algo que no era, la primera reacción es
culpar al modelo. A veces es cierto. Pero en la mayoría de los casos el problema
está antes: la instrucción no decía lo suficiente, y el agente completó los
huecos con suposiciones razonables que no eran las tuyas.
Lo que casi siempre falta
Una instrucción que funciona tiene cuatro partes. Rara vez están las cuatro.
El objetivo, en una línea y en imperativo. No «el orden no se guarda» sino
«corregir la persistencia del orden al reordenar arrastrando». La primera
describe un síntoma; la segunda dice qué hacer.
El contexto suficiente para reproducirlo. Dónde ocurre, con qué pasos, qué
esperabas y qué pasó. Un agente que no puede reproducir el problema tiene que
adivinar dónde está.
Las restricciones. Esto es lo que más se omite y lo que más caro sale. «No
toques el diseño», «no agregues dependencias», «mantén la API pública igual».
Sin decirlas, el agente hace lo que le parece mejor — y refactorizar medio
archivo le parece mejor bastante seguido.
Los criterios de aceptación. Cómo sabrás que quedó. «Que al cerrar y abrir la
app el orden se mantenga» es verificable. «Que funcione bien» no.
El problema del medio
Acá está la trampa: tú ya sabes las cuatro cosas. Están en tu cabeza mientras
miras el bug. Lo que cuesta no es saberlas, es escribirlas — y escribir cuesta
tiempo justo cuando quieres avanzar rápido.
Por eso la salida fácil es mandar una línea suelta, ver qué sale, y corregir
sobre la marcha. Funciona, pero tres o cuatro idas y vueltas después has gastado
más tiempo del que habrías gastado escribiendo bien la primera vez.
Hablar cuesta menos que escribir
Dictando dices las cuatro cosas sin darte cuenta, porque hablando es natural
explicar el contexto. Sale desordenado, con muletillas y rodeos — pero está
todo.
Eso es exactamente lo que hace Hakara: tomas ese dictado desordenado y lo
conviertes en la estructura de arriba, con objetivo, contexto, restricciones y
criterios. El trabajo de ordenar lo hace la plantilla; el de saber qué decir
sigue siendo tuyo, como debe ser.
Y antes de que llegue a tu editor lo ves en pantalla, porque una instrucción mal
convertida es peor que no convertir nada.