De la idea al draft PR con Hermes Kanban
Estoy experimentando con una forma más estructurada de usar agentes de código con IA.
No como un asistente de una sola petición al que le digo “arregla este bug” y espero que el resultado sea bueno, sino como un flujo de entrega:
objetivo -> plan -> implementación -> revisión -> draft PR -> aprobación humana
La herramienta que estoy usando para esto es Hermes Kanban.
La idea es simple: cada feature o fix se convierte en una tarea duradera, con ownership claro, pasos de revisión y handoffs entre agentes. En vez de dejar todo dentro de un chat largo, Hermes Kanban le da un ciclo de vida al trabajo.
¿Por qué no pedirle simplemente a un agente que programe?
Los agentes de código con IA son potentes, pero todavía fallan de formas bastante predecibles:
- Saltan al código demasiado pronto
- Malinterpretan el objetivo real
- Hacen cambios plausibles pero incompletos
- Revisan su propio trabajo con demasiado optimismo
- Pierden contexto en conversaciones largas
Para tareas pequeñas, puede ser aceptable.
Para trabajo real de producto, quiero algo más fiable. Por eso estoy construyendo un flujo donde el agente no empieza editando archivos. Empieza entendiendo el objetivo.
El flujo de trabajo
El proceso empieza con una feature, un bug o un objetivo de producto.
A partir de ahí, el orquestador crea un plan:
- ¿Qué tiene que cambiar?
- ¿Cuál es el comportamiento esperado?
- ¿Qué partes del código están involucradas?
- ¿Qué significa “done”?
- ¿Qué debería probarse o revisarse?
Cuando el plan está claro, Hermes Kanban crea la tarea de implementación.
El agente implementador trabaja en el cambio, normalmente dentro de una rama o worktree dedicado. Cuando termina, no marca el trabajo como completado inmediatamente. En su lugar, entrega el resultado a uno o más agentes revisores.
Los revisores comprueban el diff, los tests y si el cambio realmente cumple el objetivo original.
Si algo está mal, la tarea vuelve al loop:
implementar -> revisar -> corregir -> revisar otra vez
Solo cuando la revisión pasa, el flujo produce un GitHub draft PR.
Ese draft PR es el punto de handoff para mí.
Los agentes pueden investigar, implementar, probar y revisar, pero yo sigo decidiendo si el cambio debe mergearse.
La aprobación humana sigue dentro del loop
Este límite es importante.
No quiero que los agentes mergeen código en silencio ni promocionen cambios a producción. El objetivo no es automatización completa sin control.
El objetivo es leverage.
Quiero que los agentes de IA se encarguen del trabajo de ingeniería repetitivo:
- Investigar issues
- Editar código
- Escribir o actualizar tests
- Revisar diffs
- Preparar PRs
- Resumir qué cambió
- Sacar a la luz bloqueos
Pero sigo queriendo aprobación humana para las decisiones que importan:
- Comportamiento de producto
- Tradeoffs de arquitectura
- Aprobación de merge
- Releases a producción
En este setup, los agentes mueven el trabajo desde la idea hasta un PR listo para revisar. Yo sigo siendo el gate final.
Por qué Hermes Kanban ayuda
Una sesión normal de chat es temporal. Puede ser útil, pero no es una gran estructura para una entrega en varios pasos.
Hermes Kanban le da a cada tarea un estado: ready, running, blocked o done. La revisión puede ser otra tarea explícita en vez de un comentario vago enterrado dentro de un chat.
Eso hace que los handoffs sean visibles. Un agente puede implementar, otro puede revisar, y una tarea posterior puede encargarse del despliegue o del trabajo de seguimiento.
Esto importa porque el trabajo real de ingeniería rara vez es solo “escribir código”. Incluye decisiones, revisión, feedback e iteración.
Kanban les da a los agentes un modelo operativo compartido.
El patrón al que quiero llegar
El flujo que quiero es:
1. Empezar con un objetivo
2. Cuestionar supuestos
3. Crear un plan
4. Definir criterios de éxito
5. Implementar de forma autónoma
6. Revisar de forma independiente
7. Producir un draft PR
8. Esperar aprobación humana
Ese es el cambio que me importa.
No “la IA escribe código”.
Más bien:
Los agentes de IA mueven una tarea a través de un pipeline de entrega de ingeniería, mientras el humano mantiene el control de las decisiones importantes.
Primeras lecciones
Algunas cosas ya están claras.
Primero, el plan importa más que el modelo. Un modelo fuerte con una tarea vaga sigue produciendo resultados vagos.
Segundo, la revisión tiene que ser explícita. Si el mismo agente que escribió el código es el único revisor, es más fácil que se escapen problemas.
Tercero, los agentes necesitan límites. En mi caso, el límite es el draft PR. Pueden preparar el trabajo, pero no mergean sin aprobación.
Por último, el feedback debería volver al flujo. Si pido cambios, ese feedback se convierte en nueva entrada para la siguiente iteración, no en un mensaje aleatorio de chat.
Reflexión final
Los agentes de código con IA ya son lo suficientemente buenos como para hacer trabajo de ingeniería real, pero el flujo que los rodea importa.
Para mí, Hermes Kanban es una forma de hacer ese flujo más fiable.
Convierte el trabajo de los agentes en algo más parecido a un sistema de entrega:
objetivo -> plan -> construir -> revisar -> draft PR -> aprobación humana
Esa estructura es lo que marca la diferencia entre una demo impresionante y algo que puedo usar de verdad para entregar features y fixes.
