Cómo saber qué está haciendo tu agente de IA mientras programa

Para saber qué está haciendo un agente de IA mientras programa tienes tres sitios donde mirar, y yo los usaría juntos. El propio agente, porque Claude Code y Codex traen un modo plan, unos permisos que deciden qué hace sin preguntarte y un visor de cambios. Git, que no depende del agente, con una rama aparte, git diff y los tests. Y si quieres verlo en vivo con varias sesiones a la vez, una herramienta de observabilidad local como agenttrail, que lee la actividad de los agentes y la pinta en el navegador.

Antes de que toque nada: modo plan y permisos en Claude Code

La forma más barata de saber qué va a hacer un agente es pedirle que lo cuente antes de hacerlo. En Claude Code eso es el modo plan. Según su documentación, en ese modo Claude lee ficheros, lanza comandos para explorar y escribe un plan, pero no edita tu código hasta que lo apruebas. Entras con Mayús+Tab, poniendo /plan delante de una petición o arrancando con claude --permission-mode plan. Cuando el plan está listo te pregunta si sigues en automático, si apruebas cada edición a mano o si sigues planificando.

El modo plan es una posición más del selector que recorres con Mayús+Tab:

Modo	Qué hace sin preguntarte
Manual (default)	Solo leer
acceptEdits	Leer, editar ficheros y comandos de ficheros habituales como mkdir, mv o cp
plan	Leer, y los comandos que apruebe el clasificador cuando el modo automático está disponible
auto	Todo, con un segundo modelo revisando las acciones en segundo plano
bypassPermissions	Todo, y la documentación lo deja para contenedores y máquinas virtuales aisladas

Según la documentación, desde la versión 2.1.283 las sesiones de terminal y de VS Code arrancan en automático, con ese segundo modelo revisando las acciones en lugar de preguntarte a ti. Si quieres ver cada paso, arranca con claude --permission-mode default o fija permissions.defaultMode en tu ~/.claude/settings.json. Yo para un repositorio que no conozco empezaría en manual o en plan, y solo pasaría al automático cuando tenga claro por dónde se mueve.

Mientras trabaja: la transcripción, /diff y /rewind

Con Ctrl+O abres el visor de la transcripción, que según la referencia del modo interactivo enseña el detalle de cada herramienta que usa el agente, con la hora y el modelo de cada mensaje. Es lo más parecido a mirar por encima del hombro. Y Esc lo interrumpe a mitad de turno sin perder lo que ya hizo, por si ves que se va por donde no es.

El comando /diff te enseña los cambios del árbol de trabajo sin salir de Claude Code, con los ficheros tocados y las líneas añadidas y quitadas. Las vistas por turno salen de las ediciones que Claude hace con sus propias herramientas, así que un cambio hecho con un comando de shell solo aparece en la vista del árbol de trabajo completo.

Con /rewind, o pulsando Esc dos veces con la entrada vacía, vuelves a un punto anterior de la sesión. La propia página de checkpoints avisa de que no registra lo que se cambia con comandos de shell (un rm o un mv no se deshacen así) ni las ediciones de otras sesiones, y dice textualmente que no sustituye al control de versiones. Por eso git sigue haciendo falta aunque tengas /rewind.

Lo equivalente en Codex

Codex separa dos cosas en su página de aprobaciones y seguridad: el sandbox, que fija dónde puede escribir y si tiene red, y la política de aprobación, que fija cuándo te pregunta. En la CLI y en la extensión del editor, por defecto no tiene red y solo escribe dentro de la carpeta de trabajo. Cuando la carpeta está bajo control de versiones recomienda el preajuste Auto (--sandbox workspace-write --ask-for-approval on-request), y si no lo está, solo lectura. La carpeta .git queda protegida como solo lectura incluso dentro de las rutas en las que puede escribir.

Durante la sesión, su lista de comandos trae /permissions para pasar de Auto a solo lectura y al revés, /plan para que proponga un plan antes de ponerse, /diff para ver el diff de git incluidos los ficheros que git todavía no sigue, /review para que revise el árbol de trabajo y /status para ver el modelo, la política de aprobación y las carpetas en las que puede escribir.

Git, la red que no depende del agente

Todo lo anterior te lo cuenta el propio agente. Git te lo cuenta el disco. Yo trabajaría con una rama por encargo, para que lo que haga el agente quede separado de lo bueno y descartarlo sea borrar una rama:

git switch -c agente/nombre-del-encargo
# ... el agente trabaja ...
git status
git diff --stat
git diff
git diff --staged
git log -p

git switch -c crea la rama y se cambia a ella. git status enseña también los ficheros nuevos, que es donde aparecen los que el agente creó sin avisar. git diff --stat resume qué ficheros cambian y cuántas líneas. Si esperabas dos ficheros y salen catorce, ya sabes por dónde empezar. Luego git diff enseña el detalle de lo que no está preparado para el commit y git diff --staged lo que sí. Si el agente hace commits por su cuenta, git log -p los enseña uno a uno con su parche. Lo tienes en la documentación de git diff, git log y git switch.

Y los tests, lanzados por ti. Que el agente diga que los ha pasado es lo que él cuenta. Que los pases tú en tu máquina, sobre esa rama, es la comprobación.

Agenttrail: verlo en vivo en el navegador

Agenttrail se presenta como observabilidad local para agentes de programación. Lee la actividad que dejan en tu máquina y la pinta en el navegador. Su README insiste en que no lanza los agentes, no aprueba acciones y no decide cuándo algo está terminado. Tiene dos vistas que se instalan por separado.

Agenttrail Map enseña la estructura del proyecto, qué componentes están cambiando y las sesiones. Se arranca con npx agenttrail dentro del repositorio. Para el mapa completo de componentes necesita un PLAN.md con su propia convención, y npx agenttrail init lo prepara. Ese paso sí escribe en tu repositorio, porque toca CLAUDE.md y AGENTS.md, crea el plan, ofrece hooks de Claude Code y añade .agenttrail/ al .gitignore. En modo no interactivo da todo por bueno.

Agenttrail Kitchen es la vista experimental en 3D. Cada responsabilidad del proyecto es un cocinero, cada tarea que el agente se apunta es un plato y una tarea dada por terminada sale por la cinta. Se arranca con npx agenttrail-kitchen ., pide Node.js 20 o superior y un navegador con WebGL, y se abre en localhost:4780. Seis cocineros no son seis agentes, y un plato entregado solo quiere decir que el agente marcó la tarea como hecha, no que algo esté publicado.

Esto es lo que dice el README de cada agente en Kitchen:

Herramienta	Cómo se conecta	Estado según el README
Codex (CLI y escritorio en local)	Lee los registros de sesión locales	Probado con sesiones reales
Claude Code	Lee los registros locales y admite hooks opcionales	Probado con sesiones reales
Cursor	Hooks que instalas desde «Connect agents»	Pasan los tests del adaptador, falta validarlo en vivo
VS Code	Se lanza en su terminal integrada, sin extensión	Acompañante en el navegador
Otras	Solo cambios de ficheros	Solo observación de ficheros

Por defecto busca los registros en ~/.codex/sessions y ~/.claude/projects. Las sesiones en la nube cuyos registros no están en tu máquina no aparecen. Los dos servicios escuchan solo en 127.0.0.1, sin cuenta, telemetría ni llamadas a modelos. Map puede enseñar trozos de comandos y guarda actividad en ~/.agenttrail, así que mira qué sale antes de compartir una captura.

Es una alfa y no lo esconde. Kitchen va por la 0.1.0-alpha.3 en npm. Windows no está validado, Map todavía no entiende las listas de tareas nuevas de Claude (TaskCreate y TaskUpdate) y la página de cómo observa reconoce dos fallos cuando Map y Kitchen corren a la vez, por lo que recomienda usar Kitchen por separado si vas a fiarte de su lista de tareas. Me parece honesto que lo diga. La licencia es MIT, así que puedes usarlo, modificarlo y meterlo en un proyecto comercial conservando el aviso de copyright.

No lo he instalado, así que me baso en su documentación. Si lo pruebas, yo empezaría por npx agenttrail-kitchen . --example, un ejemplo guionizado que no necesita ningún agente, y dejaría init para cuando sepas qué ficheros te va a escribir.

Cómo lo combinaría yo

Para un encargo pequeño me bastaría con el modo plan, una rama y git diff --stat antes de aceptar nada. Para sesiones largas, o con dos agentes trabajando en el mismo repositorio, una vista como la de agenttrail tiene sentido porque te ahorra ir saltando entre terminales para saber quién toca qué. Lo que no haría es fiarme solo de la vista bonita ni solo de lo que el agente cuenta de sí mismo. El diff y los tests son lo que dice la última palabra.

Si lo que te frena es entender un repositorio ajeno antes de soltarle un agente encima, te puede servir la guía de Code Wiki de Google, que genera documentación de repositorios públicos. Y tienes más repositorios de IA de código abierto con su licencia en otra entrada.