Kiro Workflows funciona, descubrir cómo, no fue tan fácil
Probé los nuevos Workflows de Kiro para entender qué aportan frente a Specs, subagentes y una conversación tradicional. La idea me parece potente, pero llegar a entender cómo utilizarlos correctamente todavía requiere más esfuerzo del que esperaba.
Probé los nuevos Workflows de Kiro para entender qué aportan frente a Specs, subagentes y una conversación tradicional. La idea me parece potente, pero llegar a entender cómo utilizarlos correctamente todavía requiere más esfuerzo del que esperaba.
Cuando vi que Kiro había incorporado Multi-agent Workflows, lo primero que llamó mi atención no fue simplemente la posibilidad de ejecutar varios agentes. Ese tipo de capacidad empieza a aparecer cada vez más en las herramientas de desarrollo asistido por IA. Lo que me pareció realmente interesante fue la posibilidad de convertir un proceso de ingeniería en algo explícito, reproducible y ejecutable.
Una feature rara vez consiste únicamente en escribir código. Antes hay que entender el problema, recopilar requisitos, diseñar una solución, implementar, revisar, probar y finalmente validar que el resultado realmente cumple con lo esperado. La propuesta de Workflows apunta precisamente a representar ese tipo de procesos mediante pasos que pueden ser ejecutados por agentes especializados, cada uno en su propia sesión y con mecanismos para transferir resultados, ejecutar tareas en paralelo, repetir etapas o detenerse cuando una validación falla; sobre el papel, la idea me gustó bastante, así que decidí probarla con proyectos reales.
Antes de probarlo tuve que entender qué era realmente una recipe
Esta fue una de las primeras cosas que me generó confusión. En la interfaz aparecen Workflows, pero dentro de esa sección también aparecen las llamadas Recipes, y la relación entre ambos conceptos no fue evidente para mí desde el comienzo.
Después de probarlo entendí que un workflow es el proceso que Kiro ejecuta, mientras que una recipe es la definición reutilizable de ese proceso. Dicho de otra manera, la recipe describe cómo debe funcionar el workflow: qué información recibe, qué agentes participan, qué pasos existen, cómo se conectan y qué debe hacer cada uno. Cuando una recipe se ejecuta, Kiro crea un Workflow Run.
La idea es sencilla una vez se entiende, pero curiosamente terminé construyendo ese modelo mental cuando intenté crear una recipe desde el propio IDE. Allí aparece la posibilidad de crearla con alcance de Workspace o de manera global, y entonces Kiro genera un archivo
.workflow.json. Fue justo en ese momento cuando terminé de entender que no estaba simplemente configurando una tarea, sino definiendo un proceso que luego podía volver a ejecutar.
Esto también explica por qué las recipes empiezan a tener sentido cuando existe una forma de trabajar que queremos repetir. Si solamente necesito cambiar un texto o modificar una condición pequeña, probablemente no tenga mucho sentido crear un workflow. Pero si tengo un proceso que quiero ejecutar siempre de la misma manera(por ejemplo investigar antes de modificar, implementar una feature con revisión independiente o publicar una Pull Request siguiendo determinados controles ) entonces tener esa definición guardada empieza a ser mucho más interesante.
Mi primera prueba fue investigar un repositorio
Para comenzar utilicé uno de los patrones incluidos por Kiro, Investigate and explain. El objetivo era que un agente analizara la arquitectura de deployment de un repositorio sin modificarlo y generara un reporte con los principales hallazgos.
Utilicé Kaddo como proyecto de prueba porque tiene suficiente superficie técnica para que la investigación no fuera trivial. El repositorio contiene distintos paquetes, una CLI, un servidor MCP, una interfaz administrativa, integraciones y varios elementos asociados al proceso de build y publicación.
El workflow empezó a ejecutarse dentro de Workflow Runs, abrió una sesión independiente y comenzó a explorar el proyecto.
El resultado fue bastante bueno. El agente consiguió identificar correctamente los componentes principales del proyecto, revisar dependencias, analizar el proceso de publicación y detectar algunos riesgos relacionados con build, versiones y cobertura de pruebas.
Sin embargo, mi primera reacción fue un poco extraña, visualmente aquello se sentía casi como una tarea normal ejecutándose en otra sección del IDE.
Después entendí que eso tenía sentido.
Investigate es deliberadamente un workflow simple, compuesto básicamente por una etapa de investigación que genera un reporte y devuelve un resumen. No pretende demostrar toda la capacidad multiagente de Workflows; simplemente encapsula una investigación en una sesión separada y evita contaminar el contexto de la conversación principal.
Eso me permitió entender algo importante, un workflow no necesita tener muchos agentes para ser un workflow. Su valor también puede estar en aislar una tarea, hacerla observable y poder reutilizar la misma forma de ejecutarla posteriormente.
El problema apareció cuando intenté implementar una feature
Después de validar el caso sencillo quise probar algo mucho más cercano a una tarea de desarrollo. Tomé el proyecto de Dotear y le pedí implementar una característica concreta, agregar en el dashboard del negocio un indicador del uso del plan que mostrara cuántos clientes estaban registrados frente al límite permitido y generara una alerta al llegar al 80 %.
Kiro interpretó correctamente que era una nueva feature y comenzó utilizando el flujo de Specs que ya conocía. Refinó los requisitos, utilizó subagentes para analizarlos y posteriormente generó
requirements.md, design.md y tasks.md.
Hasta ese momento el resultado era razonable. El problema era que yo no estaba intentando evaluar Specs, sino Workflows.
Así que le pedí explícitamente que ejecutara los pasos mediante un workflow y que continuara el proceso en segundo plano. Sin embargo, la ejecución siguió ocurriendo dentro del flujo normal, utilizando Specs y subagentes, mientras Workflow Runs permanecía vacío.
Ahí empezó la parte realmente frustrante de la prueba. Specs, subagentes y Workflows estaban suficientemente cerca en comportamiento como para que yo empezara a preguntarme constantemente qué mecanismo estaba utilizando realmente. Durante un buen rato pensé que estaba utilizando mal la funcionalidad, y, en parte, era cierto.
Workflows estaba visible, pero todavía faltaba habilitarlo correctamente
Después de seguir investigando descubrí que Workflows requiere tener habilitado el setting:
kiroAgent.workflows.enabledAl verificar la configuración, Kiro confirmó que estaba activo a nivel de usuario.
Este detalle cambió bastante mi lectura de la experiencia. El problema ya no era simplemente que Workflows “no funcionara”. La funcionalidad estaba disponible, pero el camino desde verla en la interfaz hasta entender cómo debía utilizarla correctamente no había sido suficientemente evidente para mí.
Y ese es precisamente uno de los principales puntos que me quedaron después de la prueba, si una capacidad ya aparece en la interfaz, el usuario tiende a asumir que simplemente puede utilizarla desde allí. Tener que descubrir después cómo se activa, dónde vive la configuración y cómo debe invocarse añade una capa de fricción que termina haciendo pensar que el problema está en uno.
Entonces decidí eliminar la ambigüedad y crear mi propia recipe
En vez de seguir intentando que Kiro decidiera automáticamente cuándo debía ejecutar un workflow, opté por definir uno de manera explícita.
Creé una recipe sencilla llamada
add-feature:1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
{
"name": "add-feature",
"description": "Implementa una característica pequeña en Dotear siguiendo el contexto y convenciones del proyecto.",
"inputs": {
"task": "prompt"
},
"steps": [
{
"type": "step",
"id": "main",
"agent": "wf-coder",
"prompt": "Implementa la siguiente tarea en Dotear respetando la arquitectura, convenciones y comportamiento existente del proyecto. No hagas cambios fuera del alcance solicitado. Tarea: {{task}}"
}
]
}
La definición es intencionalmente simple. Recibe una tarea, crea un único step llamado
main y utiliza wf-coder para ejecutarla. No hay loops, ramas ni múltiples agentes revisándose entre sí.Eso fue útil porque me permitió entender primero el mecanismo básico sin agregar complejidad innecesaria. La ejecución fue igualmente sencilla:
1
/workflow run add-feature --task "Agregar en el dashboard del negocio un indicador de uso del plan que muestre clientes registrados vs límite del plan actual y alertar al llegar al 80%."Y esta vez sí ocurrió exactamente lo que esperaba. La ejecución apareció en Workflow Runs, se creó el step
main y el agente comenzó a trabajar de forma independiente.
Lo más interesante fue que, una vez encontré el camino correcto, la experiencia cambió bastante. La tarea se ejecutó rápido y el consumo de créditos también fue razonable. Esto me obligó a revisar parte de mi percepción inicial, porque durante los intentos anteriores había consumido bastantes créditos entre Specs, refinamiento de requisitos, subagentes y pruebas que realmente no estaban utilizando el mecanismo que quería evaluar. Por eso no sería justo concluir que Workflows es necesariamente costoso basándome en aquellas primeras ejecuciones.
Cuando finalmente ejecuté una recipe sencilla de manera explícita, el comportamiento fue mucho más eficiente.
Entonces entendí dónde está realmente el valor de las recipes
Después de esta última prueba, la idea empezó a hacer mucho más sentido. Una recipe no es simplemente una forma sofisticada de guardar un prompt. Lo interesante es que permite capturar cómo queremos ejecutar un determinado tipo de trabajo.
Por ejemplo, podríamos tener una recipe para investigar un problema antes de tocar código. Otra podría definir cómo desarrollar una feature, pasando primero por requisitos y diseño, luego implementación y finalmente una revisión independiente. También podríamos modelar procesos de troubleshooting donde un agente diagnostique, otro proponga una corrección y el workflow vuelva a comenzar si los tests siguen fallando.
Incluso procesos alrededor de Pull Requests empiezan a encajar naturalmente: publicar cambios, esperar feedback, analizar comentarios, aplicar correcciones y validar nuevamente.
Lo importante no es solamente automatizar esos pasos, sino poder hacer explícita una forma de trabajar que normalmente vive en nuestra cabeza o en documentación que nadie consulta, ahí es donde Workflows empieza a convertirse en algo más interesante que simplemente “varios agentes trabajando juntos”.
Mi workflow todavía tenía un solo agente, y eso estaba bien
La recipe que construí utiliza solamente
wf-coder. Técnicamente no estoy explotando todavía la parte realmente atractiva de los Multi-agent Workflows, pero me parece que empezar así fue la decisión correcta porque permitió validar primero la abstracción básica. El siguiente paso natural sería algo como:1
2
3
4
5
6
7
Planner
↓
Coder
↓
Review
↓
ValidateY después llevarlo más lejos:
1
2
3
4
5
┌── Security Reviewer
Planner → Coder ────┤
└── Quality Reviewer
↓
Validate
Aquí es donde el concepto puede empezar a cambiar realmente nuestra forma de desarrollar. El agente que escribe código no necesita ser el mismo que lo revisa. Una revisión de seguridad puede ejecutarse en paralelo con una revisión funcional. Si la validación falla, el workflow podría regresar a implementación. También podríamos utilizar modelos diferentes dependiendo de la complejidad de cada etapa. El objetivo deja de ser simplemente tener “más agentes” y empieza a ser diseñar cómo colaboran.
Specs, subagentes y Workflows siguen estando demasiado cerca
Aunque finalmente conseguí utilizar Workflows correctamente, esta sigue siendo mi principal crítica a la experiencia actual. Kiro tiene varias abstracciones potentes, pero cuando las usamos por primera vez sus fronteras pueden sentirse bastante difusas. Después de todo este ejercicio, yo las entiendo de esta manera:
Specs estructuran lo que queremos construir, nos ayudan a convertir una intención en requisitos, diseño y tareas.
Subagentes permiten delegar una tarea específica a otro agente con su propio contexto.
Workflows definen cómo debe ejecutarse un proceso completo y permiten coordinar agentes, pasos, handoffs, paralelismo, loops y validaciones.
Visto así parece bastante sencillo, pero me tomó varios intentos llegar a esa conclusión y precisamente porque Workflows intenta abstraer la orquestación, creo que el producto podría hacer mucho más visible este modelo mental desde la propia interfaz.
Lo que me gustaría ver
No creo que mi principal necesidad después de probar Workflows sea tener más tipos de agentes, más nodos o más opciones, quisiera ver mejor el proceso, si escribo algo como:
Construye esta feature pasando por requisitos, diseño, implementación, dos revisiones independientes y validación.
me gustaría que Kiro pudiera mostrar inmediatamente algo parecido a:
1
2
3
4
5
6
7
8
Feature Delivery
Requirements ✓
Design ✓
Implementation ●
Quality Review ○
Security Review ○
Validation ○Desde ahí debería poder entender qué agente ejecuta cada etapa, cuál fue su resultado, cuánto tiempo lleva, cuánto está consumiendo y en qué momento necesita realmente mi intervención.
Eso haría mucho más tangible la diferencia entre estar chateando con una IA y estar supervisando un proceso ejecutado por agentes.
Mi percepción cambió bastante después de encontrar el camino correcto
Durante la prueba pasé por tres momentos bastante distintos, primero pensé que Workflows simplemente no estaba funcionando, después asumí que probablemente yo estaba haciendo algo mal y finalmente entendí que la funcionalidad sí funciona, pero que descubrir cómo utilizarla correctamente todavía requiere conocer demasiado sobre cómo están organizadas las distintas capacidades de Kiro.
Una vez creé mi propia recipe y ejecuté explícitamente
/workflow run, todo fue bastante más claro. El proceso apareció donde esperaba, el agente ejecutó la tarea de forma independiente, la implementación fue rápida y el consumo resultó razonable, eso hizo que mi impresión final fuera bastante diferente de la inicial. La tecnología me parece prometedora, la experiencia para descubrirla todavía no tanto yjustamente por eso creo que vale la pena probarla ahora.Estamos empezando a pasar de utilizar agentes solamente como asistentes dentro de una conversación a diseñar procesos donde distintos agentes colaboran siguiendo una estructura explícita. Cuando hacemos ese cambio, la pregunta deja de ser únicamente cómo escribir un mejor prompt, empiezan a aparecer preguntas mucho más interesantes, qué tareas vale la pena delegar, qué contexto necesita cada agente, cuándo conviene utilizar un reviewer independiente, cuáles pasos pueden ejecutarse en paralelo y qué evidencia necesitamos antes de considerar un trabajo terminado, en ese punto ya no estamos pensando solamente en cómo construir software, estamos empezando a diseñar también cómo trabajan los agentes que nos ayudan a construirlo y creo que ahí está lo realmente interesante de Kiro Workflows.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article