Hacer que las pruebas verifiquen el trabajo

El agente anuncia que el bug está corregido y añade una prueba. La prueba pasa. Cierra el ticket. Dos semanas después, el mismo incidente vuelve a producirse en producción, idéntico. Al revisar el diff, comprueba que la prueba añadida no pasaba por la ruta de código afectada: verificaba que una función vecina devolvía correctamente un diccionario. Habría pasado antes de la corrección exactamente igual que después. Nunca tuvo una prueba de que algo se hubiera reparado, solo un indicador verde generado al mismo tiempo que una modificación.

Este es el punto peor entendido del uso de un agente. Una prueba escrita después de una corrección, por quien acaba de hacer la corrección, no prueba el bug: prueba el código tal como acaba de escribirse. El razonamiento del agente es circular, y lo es sin intención de engañar: observa el comportamiento actual de su propio código y lo registra como esperado. Una prueba cuyo fallo nunca se ha visto no demuestra nada. La disciplina que resuelve este problema es antigua y cabe en una frase: rojo antes que verde. Con un agente cambia de estatus: de buena práctica opcional pasa a ser el único medio de saber si la corrección tiene algo que ver con el problema.