Kiro: una guía 101 para desarrollar con agentes sin perder el control
Kiro no es solo “otro asistente de IA en tu editor”. La idea central es integrar agentes en el flujo de desarrollo con estructura, repetibilidad y alineamiento con tus estándares. Es decir: pasar de prompts sueltos a una forma de trabajo que puede escalar.
A diferencia de otros IDEs agénticos centrados principalmente en generar código rápido, Kiro pone el foco en estructurar la intención dentro del propio repositorio, no solo en la conversación.
Este artículo es una guía 101 para entender cómo encajan todas las piezas de Kiro cuando el proyecto no es trivial. No es un tutorial paso a paso, sino un mapa mental para saber cuándo usar cada concepto y por qué importa.
Veremos:
- Qué es Kiro y qué problema intenta resolver.
- Los dos modos principales: Vibe sessions y Spec sessions.
- Cómo Steering y Hooks te ayudan a codificar arquitectura y proceso.
- Dónde encaja Kiro CLI.
- Qué aportan MCP, Skills y Powers, especialmente para proyectos en AWS.
1. Mi experiencia con Kiro
Lo llevo usando desde que salió en preview.
He pasado por fases:
- Momentos en los que pensé “esto cambia la forma de trabajar”.
- Momentos en los que dudé bastante.
- Y semanas en las que casi lo abandono.
Pero ha ido mejorando mucho. Y a día de hoy, sigue siendo mi IDE principal.
He construido varias tools completas con Kiro. Desde utilidades internas hasta herramientas algo más estructuradas. Y sí, he gastado… demasiados créditos.
Eso también te enseña algo importante: dónde realmente aporta valor y dónde todavía tiene límites.
2. Qué es Kiro
Kiro es un IDE agéntico que trabaja directamente sobre tu repositorio, respetando tus convenciones y utilizando tus herramientas.
Te permite:
- Dar al agente contexto persistente sobre tu arquitectura, convenciones y estándares (Steering).
- Usar flujos estructurados cuando necesitas más control y trazabilidad (Specs).
- Conectar el agente con herramientas y sistemas externos mediante el Model Context Protocol (MCP).
- Reutilizar conocimiento en paquetes compartibles: Skills y Powers.
Modelo mental:
Kiro es como un pair programmer que entiende tu repo, respeta tus reglas y puede usar herramientas externas cuando lo necesita.
La conversación importa, pero lo que realmente escala es lo que queda versionado: especificaciones, reglas y automatizaciones.
Documentación oficial útil:
3. Dos formas de trabajar: Vibe y Specs
Kiro ofrece dos modos que encajan con situaciones distintas del día a día: Vibe sessions y Spec sessions.
3.1. Vibe (Vibe Coding)
Vibe es el modo más natural y rápido. Te quedas dentro del editor y hablas con Kiro como lo harías con alguien del equipo:
- “Crea un nuevo handler de Lambda para este caso de uso.”
- “Refactoriza esta función para mejorar legibilidad.”
- “Explícame este stack de CDK y sus componentes.”
- “Añade tests unitarios para este servicio.”
En Vibe, Kiro:
- Lee tus archivos y el contexto actual.
- Propone cambios.
- Aplica ediciones en tu proyecto cuando las aceptas.
Es ideal para:
- Refactors locales e incrementales.
- Escribir o actualizar tests.
- Generar boilerplate de componentes o funciones.
- Preguntas sobre código existente.
3.2. Specs (Spec Mode)
Specs es más estructurado. En vez de saltar directamente a hacer cambios en el código, primero defines una especificación de lo que quieres conseguir.
En Kiro, una spec suele tener esta estructura (generada en la carpeta .kiro/specs/<nombre>/):
requirements.md(obugfix.md): historias de usuario + criterios de aceptación, o análisis de bug.design.md: arquitectura técnica, decisiones y (si aplica) diagramas.tasks.md: plan de implementación en tareas discretas y trackeables.
Kiro trabaja las specs en un flujo de 3 fases:
- Requirements o Bug Analysis
- Design
- Tasks
Cuando el proyecto tiene infraestructura, permisos, arquitectura distribuida o requisitos no funcionales reales, improvisar ya no es buena idea.
Ahí Specs empieza a tener sentido.
Más detalles (docs oficiales):
3.3. Cuándo usar cada modo (regla práctica)
La clave no es elegir un modo y descartar el otro, sino combinarlos estratégicamente según el impacto del cambio.
- Usa Vibe cuando prima velocidad y exploración.
- Usa Specs cuando quieres control, trazabilidad y alineamiento con requisitos no funcionales (seguridad, fiabilidad, coste).
4. Steering: formalizar estándares y arquitectura
Uno de los conceptos más interesantes de Kiro es Steering: reglas persistentes versionadas en el repositorio. Evita repetir contexto en cada conversación.
Un archivo de steering suele describir:
- Cómo está organizado el proyecto.
- Qué tecnologías usas.
- Qué patrones quieres seguir.
- Qué prácticas quieres evitar.
Ha surgido además el estándar AGENTS.md, que varios IDEs reconocen. Kiro puede convivir con ese enfoque sin problema.
Lo importante no es el nombre del archivo.
Lo importante es que las reglas estén en el repo.
Ejemplo (AWS serverless backend):
1
2
3
4
5
6
7
8
# Steering - Backend Lambda Microservices (Node.js)
- Usar Node.js 18 o 20 en todas las Lambdas.
- Agrupar funciones por dominio: `backend/services/<dominio>`.
- Handlers finos: parsean evento, llaman a servicios de dominio y construyen respuesta.
- La lógica de negocio vive en servicios testeables en aislamiento.
- Preferir pocas funciones por dominio (por ejemplo, lecturas y escrituras separadas) en vez de un handler monolítico.
- DynamoDB: una tabla por dominio cuando tenga sentido; justificar cada índice secundario por patrón de acceso y coste.
Consejos prácticos sobre Steering
- No conviertas Steering en documentación para humanos. Son instrucciones para la IA. Sé conciso y específico.
- Cuanto más largo el steering, más contexto consume. Optimízalo.
- Invierte tiempo aquí. Es donde más retorno vas a obtener a medio plazo.
- Si tu proyecto crece, separa steering por dominio.
Docs oficiales:
5. Hooks: integrar Kiro en el flujo de trabajo
Si steering define el “cómo”, los Agent Hooks definen el “cuándo”. Esto permite transformar recomendaciones en automatizaciones reales dentro del flujo de trabajo.
En Kiro, los hooks son triggers que ejecutan acciones predefinidas cuando ocurren eventos en tu IDE (por ejemplo, guardar un fichero, crear/borrar archivos, antes o después de ejecutar tools, antes o después de ejecutar tasks de una spec, etc.).
Importante: un hook puede ejecutar:
- Un agent prompt (“Ask Kiro”)
- Un shell command
Docs oficiales:
Ejemplos útiles para AWS:
- Cuando cambian archivos en
infra/cdk/**:- Revisión automática de riesgos de seguridad o coste.
- Cuando se añade una nueva Lambda:
- Validar que cumple steering.
- Proponer al menos un test unitario.
- Antes de un despliegue:
- Resumen de cambios y posible impacto arquitectónico.
Consejos prácticos sobre Hooks
- Empieza simple. Mi hook base en casi todos los proyectos es:
- Ejecutar lint
- Ejecutar tests unitarios
- Ejecutar e2e
- Corregir todo lo que falle
- Lo ejecuto manualmente.
- Las ejecuciones automáticas al guardar pueden disparar consumo innecesario de tokens.
- Automatiza solo cuando el patrón ya esté claro.
6. Kiro CLI: traer el agente a la terminal
Kiro no se limita a la UI. También existe Kiro CLI, pensado para interactuar con el agente desde terminal e integrarlo en automatizaciones.
La CLI resulta especialmente interesante en entornos donde el desarrollo asistido debe integrarse en pipelines o automatizaciones existentes.
Casos típicos:
- Ejecutar un cambio guiado por spec desde un script.
- Aplicar un set de refactors ya validados.
- Generar o actualizar documentación.
- Integrarlo en CI o pre-commit para checks concretos.
Referencia de comandos (docs oficial):
6. MCP, Skills y Powers (la parte “extensible”)
Además de lo anterior, hay tres piezas que completan el puzle: MCP, Skills y Powers.
7.1. MCP (Model Context Protocol)
MCP extiende Kiro conectándolo a servidores que aportan herramientas y contexto adicional. Con MCP puedes:
- Acceder a documentación y knowledge bases especializadas.
- Integrarte con servicios y APIs externas.
- Usar tools del servidor.
- Usar plantillas de prompts y resource templates desde el chat (por ejemplo, con el sistema de menciones
#...). - Responder a “elicitation” cuando una tool necesita input adicional durante su ejecución.
Docs oficiales:
7.2. Skills
Las Skills son paquetes de instrucciones portables que siguen el estándar abierto Agent Skills. Pueden incluir instrucciones, scripts y plantillas, y Kiro puede activarlas cuando son relevantes para tu tarea.
Docs oficiales:
Ejemplos de Skills que encajan muy bien en equipos AWS:
- Checklist de PR (seguridad, observabilidad, coste).
- Plantilla de Spec para cambios de infra “sensibles” (IAM/VPC).
- Guía repetible para crear un nuevo microservicio Lambda (estructura, tests, métricas, logs).
7.3. Powers
Las Powers son paquetes instalables que agrupan MCP tools, steering y hooks en un único artefacto. El objetivo es encapsular conocimiento especializado y herramientas en unidades reutilizables y activables bajo demanda.
Docs oficiales:
Ejemplo mental:
- Si una conversación empieza a hablar de “database”, una Power con keywords relacionadas puede activarse y cargar automáticamente herramientas y documentación específicas.
Consejos prácticos sobre Powers
- No crees Powers demasiado genéricas.
- Úsalas para dominios claros: database, observabilidad, seguridad, etc.
- Piensa en ellas como “expertise activable bajo demanda”.
8. Cómo empezar en 10 minutos
Una ruta rápida (sin meternos aún en Powers complejas):
- Instala Kiro y abre un repositorio de ejemplo (o uno real no sensible).
- En el panel de Kiro, usa Generate Steering Docs para crear el primer set de steering en
.kiro/steering/. Docs: Getting started - Haz 2 pruebas rápidas en Vibe:
- “Explícame el módulo X y dónde vive la lógica principal.”
- “Propón un refactor pequeño y añade tests”.
- Crea una Spec para un cambio real pero acotado (por ejemplo, añadir un endpoint o refactor en CDK):
- Requirements (criterios de aceptación),
- Design (decisiones),
- Tasks (pasos). Docs: Specs
- Añade 1 hook simple (IDE) para automatizar una rutina (por ejemplo, al tocar
infra/**pedir revisión de seguridad/coste). Docs: Hooks
Conclusión
Kiro no pretende sustituir el criterio técnico ni convertir el desarrollo en una conversación infinita con un modelo. Su propuesta es distinta: integrar agentes dentro de un marco estructurado donde la intención, las reglas y las decisiones quedan versionadas.
En proyectos AWS, donde los cambios pueden afectar a seguridad, red, identidad o coste, disponer de especificaciones trazables, estándares formales y automatizaciones coherentes marca una diferencia real.
El valor no está en usar Specs en cada tarea, sino en saber cuándo introducir estructura. Cuando el impacto arquitectónico aumenta, formalizar la intención deja de ser una opción y pasa a ser una necesidad.
Kiro no es solo un asistente. Es una forma de poner disciplina en el desarrollo con agentes.