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 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. Para un script pasado de un shell a otro, mira la lección sobre comandos de shell.

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.

Una carpeta temporal por agente

Los agentes lanzados en paralelo que comparten una carpeta temporal se pisan sus scripts y sus resultados. Un agente no ve ni los archivos temporales de los demás ni las correcciones hechas fuera de su encargo: puede validar algo obsoleto. El encargo nombra, pues, una carpeta propia del agente para sus scripts y resultados, y tras cada pasada sobre un archivo que el padre corrigió, vuelve a lanzar el grep de las formulaciones retiradas.

Lo que rechazan las herramientas de escritura

Desde octubre de 2026, Edit y NotebookEdit rechazan un archivo en una codificación antigua como Windows-1252 o Shift-JIS; Write puede reemplazar un archivo así, pero guarda el contenido nuevo en UTF-8 y se pierde la codificación original: conviértelo antes, el rechazo de Edit es una señal y no una avería. Read ya no lee como texto los archivos binarios como .xlsm, .parquet, .epub o .heic.