El chat no es un ordenador: cuatro almacenes que tu agente de codigo confunde

Cinco ideas equivocadas que se repiten cuando alguien trabaja con un agente de código sobre una máquina remota. La advertencia central cabe en una frase: el chat no es un ordenador, y lo que el modelo dice del disco no es lo que el disco contiene. El texto se presenta como una acción de difusión de MonkeyCode, que ofrece acceso gratuito a modelos y un servidor gratuito, y su autor lo declara sin disimulo.

Cuatro almacenes, no un cerebro

La propuesta es separar desde el principio cuatro sitios distintos donde vive la información: el contexto del chat (los tokens de esta conversación), el entorno del proceso (un shell, un PID, y se acabó), el disco de la caja (los archivos del directorio de trabajo) y los objetos de Git (los blobs que sobrevivieron a un git add). Sin ese mapa, cada mito gana.

El primero es creer que un chat nuevo arranca con el disco limpio. Pulsar nuevo genera tokens nuevos, no un sistema de archivos nuevo. Un pwd, un ls -la y un git status --short lo aclaran en un segundo.

El segundo es usar export para guardar configuración. La variable muere con el proceso: un shell hijo la verá como no definida. Si hace falta persistir algo, se escribe un archivo; y los secretos no van en una caja compartida.

El tercero es dar por existente un archivo porque el modelo lo citó. Una cita no es prueba de bytes. Antes de celebrar, un test -f y luego la consulta a Git. El autor lo resume así: el modelo es un loro con cinturón de herramientas; los loros citan, los discos guardan y Git versiona.

El cuarto es creer que borrar en el chat borra en disco. Solo rm desenlaza. Después de cada afirmación destructiva conviene mirar con ls, rg y git grep. De pasada menciona un quinto sitio donde le pueden engañar, el búfer del editor sin guardar, y avisa de que no lo cubre.

El quinto mito es el más pegajoso: que el modelo gratuito y el servidor gratuito comparten memoria. No es así. Inferencia y sistema de archivos son cosas separadas aunque estén al lado, y se tocan únicamente a través de las llamadas a herramientas que de verdad se ejecutan. Si ninguna corrió, ningún hecho del disco cambió. Una negación fluida sigue siendo solo contexto de chat.

Hay un extra: el directorio de trabajo no es $HOME. Un agente hace cd y después describe archivos de memoria, así que las rutas relativas mienten cuando el directorio cambió. Comparar pwd, $HOME y readlink -f . antes de discutir si algo existe.

Como artefacto propone un script de bash, persist_audit.sh, que crea un archivo canario con marca de tiempo y recorre las cuatro capas: recuerda preguntar al modelo por el canario, comprueba el entorno del proceso con un shell hijo, mira el disco con pwd, ls -la y test -f, y consulta Git. El autor insiste en que es un flujo local propuesto y no un benchmark, y el original llega cortado a mitad del script.

Por qué importa

Para quien opera agentes de código en cajas efímeras, el valor está en no confundir una respuesta con un cambio de estado. Los comandos que cita son de andar por casa y se pueden meter en cualquier guion de comprobación. Queda por ver si las plataformas que ofrecen estos entornos añaden ellas mismas un registro de llamadas a herramientas junto al estado del disco; hoy esa trazabilidad la tiene que montar el usuario.