Inicio / Gestos cotidianos

Trampas de escritura: archivos, ediciones paralelas y entregables perdidos

Un informe de éxito escrito por un subagente no prueba nada sobre el estado real de los archivos, ya que arranca en un contexto aislado sin acceso a lo que el agente principal ya leyó o escribió, y la única prueba fiable sigue siendo un diff verificado después, no el texto del informe.

Un subagente arranca con un contexto aislado y nuevo en cada llamada, salvo para un fork, que por el contrario hereda toda la conversación en curso. No ve ni el historial de la conversación principal, ni las skills ya invocadas, ni los archivos que el agente principal ya leyó. Este aislamiento no le impide consultar él mismo el disco: dispone de las mismas herramientas de lectura y ejecución que la conversación principal, y perfectamente puede lanzar un git diff o releer un archivo para verificar su propio trabajo. Lo que falta es una mirada externa: un informe de éxito sigue siendo un texto producido por el mismo agente que acaba de actuar, nunca una verificación independiente, y nada garantiza que corresponda a una escritura real en el disco mientras nadie más lo haya controlado.

El informe de texto no es la prueba

La buena práctica documentada consiste en pedir un diff verificable en lugar de confiar en el texto del informe. Un diff muestra las líneas realmente cambiadas en un archivo real, un informe de éxito no es más que una frase generada por el mismo agente que afirma haber tenido éxito.

mkdir -p /tmp/demo-diff
echo "versión inicial" > /tmp/demo-diff/avant.txt
echo "versión modificada" > /tmp/demo-diff/apres.txt
diff /tmp/demo-diff/avant.txt /tmp/demo-diff/apres.txt
# resultado: la línea modificada aparece, la prueba está en el diff, no en una frase

Un informe en texto que afirme que apres.txt fue actualizado no aporta nada más que ese diff, y sin él, nada distingue una escritura real de una frase inventada. Un script en una sola línea que contiene comillas invertidas se topa con una trampa vecina: el shell que lo ejecuta puede interpretarlas antes de que el comando llegue a su destino, y lo que se muestra después parece un éxito cuando el comando realmente lanzado estaba truncado. Releer el comando tal como fue recibido por el shell, no solo tal como fue tecleado, responde a la misma necesidad de prueba que el diff.

Dos escrituras sobre el mismo archivo nunca son independientes

Dos modificaciones enviadas juntas sobre el mismo archivo, ya sea por dos subagentes o por dos llamadas de la herramienta de edición en el mismo turno, se aplican una tras otra sobre el contenido que la herramienta encuentra en el momento en que actúa, nunca sobre dos copias separadas fusionadas después. La segunda modificación puede entonces fallar al buscar el texto que buscaba, porque la primera ya lo cambió. Enviar las dos modificaciones en secuencia, releyendo el archivo entre ambas, reduce ese riesgo y hace que cada paso sea verificable por sí mismo.

El mismo principio de prueba verificable se aplica a un entregable largo: un contenido de varios párrafos que solo existe en la respuesta mostrada desaparece con ella en cuanto la conversación continúa. Escribirlo en un archivo real antes de mostrarlo, como en una salida estructurada en modo headless, garantiza que siga siendo consultable independientemente del hilo de conversación, exactamente como un diff sigue siendo legible independientemente del informe que lo acompaña.