--- title: "Mi flujo diario de trabajo con agentes" description: "Un flujo diario práctico para ejecutar agentes de código con objetivos explícitos, terminales aislados, revisión basada en evidencias, merges controlados y registros de continuidad." date: "2026-09-25T00:00:00.000Z" author: "Carlos Garavito" tags: ["AI agents", "engineering workflow", "code review"] canonical_url: "https://cgaravito.dev/es/blog/my-daily-agent-workflow" last_updated: "2026-09-25T00:00:00.000Z" locale: "es" --- En un día normal tengo varios agentes de código ejecutándose a la vez. La mayor parte de lo que he construido alrededor de ellos mantiene las decisiones conmigo, y cada trabajo que doy por terminado viene acompañado de evidencias que puedo abrir y comprobar. Este es el bucle que uso, con diagramas que dibujé para explicárselo a mi equipo en una retransmisión en directo. ## Elige el bucle según la tarea Antes de ejecutar nada, clasifico el trabajo según lo que aún no sabemos y su tamaño. La investigación o una auditoría pasan primero a un flujo de investigación separado. Un único cambio localizado es un dart. Un conjunto de PRs relacionadas pasa por el grilling y se convierte en un plan de wave que confirmo. Que pilot ejecute esa wave hasta el final o que la fusione slice a slice manualmente depende únicamente de si tengo merges autorizados. Flash review queda fuera de estos bucles, así que puedo dirigirlo a cualquier diff local para obtener una segunda revisión rápida. Incluso un diff pequeño puede necesitar investigación previa cuando depende del comportamiento de un sistema externo y no tengo claro cómo funciona. [[asset:which-loop-color]] ## Resuelve todas las dudas durante el grilling Grilling es el nombre que doy a la entrevista en la que se resuelve cada duda, una pregunta cada vez. Cada pregunta incluye la respuesta que recomendaría y el coste de esa decisión. Los hechos se consultan en lugar de preguntarlos, y las decisiones corresponden a la persona, que normalmente soy yo. Esto importa porque los workers ejecutan sus objetivos sin detenerse para preguntar nada. Una pregunta abierta aquí vuelve más tarde como una suposición dentro de una PR. Mantengo cada pregunta lo bastante acotada como para que la respuesta cambie el plan. Una vez decidida, la misma respuesta entra en el objetivo del worker y en los criterios de revisión. ## Planifica la wave como filas de PR El plan divide el conjunto en filas de PR. Cada fila tiene un entregable, sus dependencias y un ejecutor. La estructura es paralela cuando las filas son independientes, una cadena cuando una fila cambia la base de la siguiente, o fases cuando varios grupos de filas pueden avanzar juntos. Confirmo esa estructura antes de que empiece cualquier agente. Escribo las dependencias de forma explícita porque un plan que parece paralelo puede convertirse en una cadena cuando una PR cambia una interfaz que consume otra. El archivo de estado registra por separado el objetivo, la PR, el worktree, la revisión y el merge de cada fila. Lo reconcilio con GitHub, porque el plan no demuestra que haya ocurrido nada. Un plan recortado tiene este aspecto. ```text shape: phases status: kickoff | id | title | depends on | worker | goal | pr | review | landed | | -- | ----- | ---------- | ------ | ---- | -- | ------ | ------ | | P1 | Persist draft state | - | executor A | emitted | - | - | - | | P2 | Expose preview | P1 | executor B | blocked | - | - | - | ``` ## Escribe objetivos como contratos de finalización Cada fila recibe un objetivo que funciona como contrato de finalización. Incluye el resultado, el contexto, los límites y las restricciones, los comandos exactos de verificación y una regla para saber cuándo iterar, cuándo terminar y cuándo detenerse, todo en menos de 4000 caracteres. Copio la lista de verificación de la CI del repositorio en lugar de inventar una versión local más sencilla. Especifico el comportamiento que debe demostrar el worker, porque un comando en verde puede ocultar una funcionalidad ausente. Cualquier autorización para hacer commit o abrir una PR aparece entre comillas y de forma literal. Sin ella, el worker deja su trabajo sin commit. Terminar significa aportar evidencias que pueda inspeccionar. Si un worker no puede llegar hasta ahí, informa del bloqueo y deja su estado para que lo inspeccione. El objetivo de este post tenía aproximadamente este aspecto. ```text Outcome: both locales preview with every declared asset. Context: the post is withdrawn, test it in isolated local state. Boundaries: the post brief and the authoring pipeline only. Constraints: never publish or change remote state. Verify: the format, type, test and build gates from CI, then read both local previews. Iterate/done/stop: regenerate from the brief until both previews pass, stop on missing evidence or credentials. ``` El formato procede de [Goalcraft](https://github.com/grp06/goalcraft), que describe un objetivo como un contrato compacto con un resultado, una superficie de verificación, restricciones, límites, una política de iteración y una condición de parada por bloqueo, con un límite de 4000 caracteres. ## Ejecuta la wave slice a slice Cuando tengo merges autorizados, pilot ejecuta la wave por su cuenta, un slice cada vez. Para cada slice reconcilia las PRs abiertas con GitHub y los worktrees, escribe un objetivo para cada fila lista, inicia cada worker en su propia terminal y espera a que se abra una PR o a que el proceso se quede bloqueado. Una terminal inactiva nunca cuenta como trabajo terminado. Lo que cuenta es una PR abierta y, después, un veredicto de revisión. A continuación vienen la revisión, las correcciones de los bloqueos verificados, el merge y el siguiente slice. Sin autorización para hacer merge, el bucle se detiene en la revisión y las PRs esperan a que intervenga yo. [[asset:pilot-slice-color]] ## Revisa, corrige y vuelve a medir La revisión tiene dos capas. Un revisor de gating analiza el cambio, normalmente con mutation probes, e informa de los bloqueos con archivo y línea. Revisores ciegos de solo lectura de otros laboratorios añaden sus hallazgos sin ver los de los demás. El fixer solo toca bloqueos verificados. Compruebo cada bloqueo comunicado contra el diff antes de que nadie edite nada, de modo que un hallazgo que no puedo reproducir nunca se convierte en una instrucción de corrección. Después de dos rondas de correcciones, lo que queda se escala como un problema de diseño en lugar de entrar en una tercera ronda. Cada veredicto registra el SHA base sobre el que se ha medido. Si la base cambia, vuelvo a medir, porque el mismo head puede comportarse de otra forma cuando aterriza otra PR. Los workers nunca ven la autorización de merge ni fusionan sus propias PRs. El soporte de imágenes locales del que depende este post pasó exactamente por este proceso. La PR #272 de este sitio tuvo dos rondas de revisión independientes, un fixer cerró cinco nits en ocho commits entre ambas y la segunda ronda, medida sobre el head 91a5943, eliminó 16 de 16 mutantes. Para revisiones más profundas he publicado [el swarm de revisión de solo lectura que uso](https://github.com/cgaravitoq/my-opencode), con lentes de revisión separadas y un veredicto vinculado al commit inspeccionado. ## Da a cada agente una terminal y un worktree Cada worker, revisor y fixer se ejecuta en su propia terminal y en su propio git worktree. Puedo leer lo que está haciendo, detener ese proceso e inspeccionar lo que ha dejado atrás después de un kill, ya sea una mutación que un revisor no revirtió o un diff parcial de un fixer. Un subagente que se ejecuta dentro del conductor no me da ningún control para leerlo o detenerlo. Cuando muere, no dice nada sobre lo que ha dejado en el árbol. ## Cierra la wave con continuidad Cerrar una wave escribe la continuidad para el día siguiente, incluidas las filas exactas que no se fusionaron y la siguiente decisión que necesita cada una. Cualquier cosa que haya salido mal y pueda volver a ocurrir pasa a un archivo de aprendizajes compartidos que todas las waves posteriores leen al arrancar. Escribo el mecanismo del fallo y qué cambió, para que la siguiente wave compruebe ese límite en lugar de redescubrirlo. La mañana siguiente empieza con ese registro. Es mucho más barato que volver atrás por el historial de la terminal. ## Investigación y auditoría en un flujo separado Para una investigación o una auditoría escribo un brief autocontenido con la pregunta, las fuentes que hay que consultar y el formato de salida que quiero recibir. El flujo de investigación es una sesión desechable que solo ve ese brief, nunca mi conversación ni mis conclusiones. Devuelve hallazgos con una URL y una cita exacta. Aun así comparo cada cita con la página, porque una URL puede ser real mientras la cita está parafraseada o no guarda relación. Para los planes importantes pido una segunda opinión al otro harness. Hace una crítica una vez, respondo con una réplica y cualquier discrepancia que quede llega a mí, en lugar de convertirse en una conversación interminable. [[asset:research-audit-color]] ## Usa un dart para un cambio localizado Un dart sirve para un único cambio localizado que debería llevar minutos. Si es un bug sin repro, primero lo diagnostico con una reproducción y una hipótesis que pueda falsar. Eso indica al worker qué comportamiento debe cambiar y da a la revisión algo concreto que comprobar. Después acoto el resultado, los archivos y el comando de verificación, y se lo asigno a un worker, o a varios cuando sus archivos no se solapan. Los workers implementan, pero no hacen commit. Leo el diff, vuelvo a ejecutar la verificación y solo entonces hago commit, push y abro una PR en borrador. Nunca hago merge desde el propio dart. Si la revisión descubre una pregunta del tamaño de un problema de diseño, deja de ser un dart y se convierte en una wave. [[asset:dart-loop-color]] ## Haz flash review del diff actual Flash review es el bucle más barato que tengo. Introduzco el diff local completo y sus SHA base y head en el prompt de un único modelo barato de solo lectura que se ejecuta en su propia terminal. Responde con approve o reject y hallazgos con archivo y línea, y un solo bloqueo significa reject. Creo que un modelo pequeño con una tarea concreta suele bastar para esta primera pasada. Los modelos grandes tienden a divagar y a sobrediseñar una revisión. Aun así abro cada línea citada antes de darla por válida, y un veredicto sin ubicaciones no es algo a partir de lo cual corregiría nada. Nunca comenta una PR. El veredicto me llega a mí, y cualquier cambio que merezca algo más pasa al swarm de revisión multi-laboratorio. [[asset:flash-review-color]] ## Por qué lo mantengo así Creo que este es un buen flujo de trabajo, sobre todo porque cada decisión tiene un responsable y cada cosa que doy por terminada tiene evidencias que puedo abrir. Encaja con lo que pienso de los agentes en general. El valor está en el harness que rodea al agente, la validación, la revisión y el flujo de trabajo. El código de un agente que llega a producción sin revisión humana es un fallo, por muy bueno que sea el modelo. Por eso construyo estas herramientas alrededor de mi propio flujo de trabajo, en lugar de adoptar tal cual el harness de otra persona. Al final del día consulto el registro de la wave, qué filas se fusionaron, cuáles quedan pendientes y qué tengo que decidir mañana.