Retomar el control
Las señales de fracaso, y por qué tirar sale más barato que remendar.
Reconocer los límites y retomar el control
Llevas cuarenta minutos en la sesión. El primer intento no compilaba, el segundo compilaba pero rompía dos tests, el tercero arregló esos dos tests y rompió un tercero, y el cuarto acaba de reintroducir el error del primer intento. Aun así vuelves a lanzar, porque «ya casi está» y porque cuarenta minutos son demasiados para tirarlos todos. Una hora después, el archivo ya no se parece a nada, no sabes qué parte del código es la original y terminas con un git checkout rabioso que lo deshace todo, incluidas las dos modificaciones que estaban bien.
Este escenario no es una anécdota, sino el modo de fallo dominante cuando se trabaja con un agente, y se debe a un sesgo perfectamente documentado: el coste hundido. Cada iteración aumenta tu inversión afectiva y tu reticencia a abandonar, mientras que la probabilidad de éxito disminuye. Un agente que ha fallado tres veces en la misma tarea no está aprendiendo: da vueltas en un contexto contaminado por sus propios intentos fallidos, que lo empujan hacia los mismos callejones sin salida. La competencia que hay que adquirir es, por tanto, contraintuitiva: hay que saber decidir parar, pronto, a partir de señales objetivas y no por intuición.
Comentarios
Los comentarios funcionan con GitHub Discussions
Inicia sesión con GitHub para participar en la discusión