Esta mañana lanzaste cuatro agentes. Uno refactorizó el módulo de autenticación, otro escribió tests, otro persiguió un job de CI inestable y otro sigue pensando. Por la tarde tienes una vaga sensación de que pasaron cosas, un montón de pestañas de terminal, tres worktrees que apenas recuerdas haber creado y dos pull requests que no has leído. El trabajo se hizo. Pero no puedes ver en qué consistió.
Hacer seguimiento del trabajo completado por agentes de código con IA es el problema de convertir ese desorden en un registro: qué cambió cada agente, si eso se sostiene y dónde acabó. Es un problema real porque los agentes terminan más rápido de lo que tardas en inspeccionarlos, y la evidencia de lo que hicieron vive en lugares diseñados para una sola persona trabajando en solitario. Esta guía repasa primero la configuración manual, señala dónde se rompe y después muestra el flujo de trabajo que usa Sharkly para mantener cada resultado ligado a la tarea que lo pidió.
La versión corta: puedes hacer seguimiento de un par de agentes a mano con git y tu terminal. Más allá de eso, necesitas un lugar compartido donde los resultados vuelvan por sí solos, porque el cuello de botella deja de ser la escritura de código y pasa a ser tu capacidad para revisarlo.
En resumen
Hacer seguimiento del trabajo completado por agentes significa responder tres preguntas en cada ejecución: qué cambió, si es correcto y dónde acabó. El historial de git y las pull requests responden a la primera para uno o dos agentes. Cuando varios agentes trabajan en paralelo, el registro se fragmenta entre worktrees, terminales y colas de PR, y pierdes el vínculo entre la tarea y su resultado. Un tablero de tareas soluciona esto haciendo que la ejecución, los bloqueos, los resultados y la revisión humana vuelvan a una misma tarea, de modo que el trabajo completado sea inspeccionable en lugar de tener que reconstruirlo.
Qué significa hacer seguimiento del trabajo completado
El seguimiento no es un registro de actividad. Es la capacidad de responder tres preguntas sobre una ejecución terminada sin tener que hacer ingeniería inversa.
- Qué cambió. El diff, los archivos tocados y el motivo de cada uno.
- Si es correcto. La comprobación de tipos, los tests, la compilación y un resumen de lo que verificó el agente.
- Dónde acabó. La rama, la PR, la tarea a la que pertenece y quién la acepta.
Un agente que termina en silencio ha completado trabajo, técnicamente, pero no puedes actuar sobre él. El estado de completado que te importa es el que una persona puede inspeccionar y aceptar. Por eso «los tests pasaron» no es lo mismo que «el trabajo está registrado».
El modelo human-in-the-loop para agentes de código marca la frontera: los agentes investigan, ejecutan, prueban e informan; las personas marcan la dirección y aceptan el resultado. El seguimiento es la maquinaria que permite que ocurra esa segunda mitad.
La configuración por tu cuenta, paso a paso, y dónde falla cada paso
Para un agente en una rama, las herramientas integradas bastan. Aquí va la versión honesta, con el modo de fallo identificado en cada paso.
Paso 1: Ver qué cambió. Después de una ejecución, lees el diff.
git log --oneline -10
git diff main...HEAD --stat
Falla cuando: dos agentes comparten rama, o un agente no hace ningún commit y deja cambios en el árbol de trabajo de un worktree que olvidaste. El diff que lees no es el diff que se entregó.
Paso 2: Aislar el trabajo de cada agente. Le das a cada agente su propio git worktree para que no choquen entre ellos.
git worktree add ../auth-refactor -b auth-refactor
git worktree list
Falla cuando: la lista crece más allá de lo que puedes retener en la cabeza. git worktree list te dice las rutas, no qué agente está en cada una, a qué tarea sirve ni si ha terminado. Consulta la documentación oficial de git-worktree para los detalles mecánicos; se queda en la contabilidad.
Paso 3: Comprobar que los resultados llegaron a una PR. Te apoyas en GitHub.
gh pr list --author "@me" --state open
gh pr view 214 --json title,statusCheckRollup
Falla cuando: la PR existe pero nadie escribió el porqué, o las comprobaciones están en verde mientras el cambio es incorrecto, o la PR no enlaza de vuelta con la petición que la originó. La referencia de gh pr list te muestra las PR abiertas, no la intención.
Paso 4: Recordar qué pediste. Este paso no tiene comando. El requisito original vive en un mensaje de Slack, en una nota o en tu memoria. Cuando revisas la PR tres días después, estás adivinando los criterios de aceptación.
Cada paso funciona. El problema son las costuras entre ellos. El diff, el aislamiento, la PR y la intención viven en cuatro sistemas que no se conocen entre sí, y tú eres lo único que los conecta.
Dónde deja de escalar la configuración manual
La ruptura no es un momento puntual. Es una pendiente, y puedes identificar en qué punto estás.
| Agentes en paralelo | Qué cuesta el seguimiento | Qué se rompe primero |
|---|---|---|
| 1 | Leer un diff, una PR | Nada |
| 2 a 3 | Cambiar de contexto entre worktrees | Pierdes qué agente hizo qué |
| 4 a 6 | Reconstruir la intención en cada PR | Los resultados superan tu capacidad de revisión |
| 7+ | Coordinación a tiempo completo | El trabajo completado se queda sin revisar durante días |
El coste real se mide en capacidad de revisión, no en la velocidad del agente. Los agentes producen trabajo completado más rápido de lo que una persona puede inspeccionarlo, así que a partir de un puñado de ejecuciones tu rendimiento queda limitado por la rapidez con la que puedes responder a las tres preguntas, no por la rapidez con la que programan los agentes. Añadir más agentes empeora el problema del seguimiento, no mejora el de la entrega.
Qué aporta un tablero de tareas
La solución es dejar de tratar una ejecución completada como un diff y empezar a tratarla como algo que vuelve a una tarea.
En Sharkly, la tarea es el registro compartido. Asignas una tarea a un agente o a un Crew, y la ejecución ocurre en un worktree aislado, de modo que los agentes en paralelo nunca tocan los mismos archivos. Cuando termina, la ejecución, los bloqueos, los resultados y el seguimiento vuelven a la línea de tiempo de la tarea. El resumen de cambios, los resultados de la verificación y los límites conocidos se adjuntan a la propia tarea, no a una terminal que tienes que seguir teniendo abierta.
Esa es la diferencia entre un log y un registro. Un log te dice que pasó algo. Un registro te dice qué cambió, si es correcto y dónde acabó, todo en un mismo sitio y vinculado a la petición que lo inició. Revisas el trabajo completado desde la tarea, lo aceptas o lo devuelves, y la decisión lleva tu nombre.
Aquí es donde se cierran las costuras del trabajo por tu cuenta. La intención, el diff, las comprobaciones y la aceptación viven en un mismo objeto. Conservas las herramientas que ya usan tus agentes; Claude Code y Codex siguen encargándose de la ejecución, y Sharkly añade la capa de tarea, contexto y revisión a su alrededor. Asignar trabajo a un agente de IA pasa entonces a leerse como asignárselo a un compañero de equipo, y el resultado vuelve a un lugar donde puedes encontrarlo.
Puedes descargar Sharkly y conectar un Computer para probar esto con una única tarea real antes de escalarlo.
Cuando no necesitas nada de esto
Sé honesto con respecto al umbral. Si ejecutas un solo agente de código, en un solo repositorio, y lees cada diff antes de que se fusione, git y tu terminal ya hacen el seguimiento de tu trabajo completado. Un tablero de tareas solo añadiría ceremonia innecesaria. La vista de proyecto integrada en Claude Code cubre una cantidad sorprendente de casos para un flujo de trabajo con un único agente.
La ecuación cambia cuando se acumulan tres cosas: más de un par de agentes a la vez, trabajo que no puedes revisar el mismo día en que termina y resultados que deben llegar a alguien que no eres tú. Ahí es cuando un registro de tareas compartido deja de ser una sobrecarga y se convierte en la única forma de que el trabajo completado sea visible desde la petición hasta la entrega.
Una lista de comprobación que puedes aplicar hoy
Antes de añadir otro agente, confirma que puedes responder afirmativamente a cada uno de estos puntos para los que ya están en marcha:
- [ ] Para cualquier ejecución terminada, ¿puedes encontrar el diff en menos de un minuto sin abrir una terminal?
- [ ] ¿Cada ejecución completada incluye un resumen de lo que verificó el agente, y no solo comprobaciones en verde?
- [ ] ¿Puedes rastrear una PR hasta el requisito que la originó?
- [ ] ¿Existe un único lugar que muestre qué agente está en qué, qué ha terminado y qué necesita revisión?
- [ ] ¿Aceptar el trabajo completado lleva el nombre de una persona asociado?
- [ ] Cuando un agente termina, ¿el resultado llega a ti, o tienes que ir a buscarlo?
Cualquier «no» es una costura que se ensanchará a medida que añadas agentes. Arreglarla pronto sale más barato que reconstruir una semana de ejecuciones sin registrar más adelante.
Preguntas frecuentes
¿Cómo hago seguimiento de lo que cambió un agente de código con IA? Lee el diff, no el resumen que hace el agente de él. Para un agente, git diff y la PR bastan. Para varios, mantén cada ejecución en su propio worktree y haz que el diff más un resumen de verificación vuelvan a una tarea compartida, para no tener que reconstruirlo a partir del historial de la terminal.
¿Puedo hacer seguimiento del trabajo de agentes de IA solo con GitHub? Para uno o dos agentes, sí. GitHub te muestra las PR abiertas y el estado de las comprobaciones. No te dirá qué agente produjo una PR, a qué tarea sirve ni si el cambio coincide con la intención original, así que se queda corto enseguida cuando varios agentes trabajan en paralelo.
¿Cuántos agentes puedo ejecutar antes de necesitar un tablero de tareas? La mayoría de la gente empieza a notar las costuras en torno a tres o cuatro agentes en paralelo, cuando reconstruir la intención de cada PR empieza a consumir más tiempo que la propia revisión. El detonante es la capacidad de revisión, no un número fijo. Consulta nuestra nota sobre gestionar agentes de código en paralelo.
¿Un tablero de tareas ralentiza a los agentes que van rápido? No. Los agentes siguen ejecutándose en worktrees aislados a plena velocidad. El tablero añade una vía de retorno para que su trabajo completado aterrice en un lugar donde puedas revisarlo, lo que elimina el paso de reconstrucción manual en lugar de añadir uno.
