Empecé con Kiro hace unos meses, en octubre de 2025, durante un hackathon llamado Kiroween. Fue básicamente mi punto de partida para empezar a probar Kiro como IDE y entender qué estaba intentando hacer AWS con esta propuesta. Mi objetivo era probar Kiro y ver en qué se diferenciaba de otras herramientas que ya estaba usando.
En aquel entonces tampoco había demasiadas guías sobre Kiro. Así que casi todo lo que hice fue exploratorio: abrir proyectos, probar el vibecoding, entender eso del spec-driven development y ver cómo respondía el IDE.
Con el paso de los meses y metiéndome más en la comunidad de Kiro, empecé a descubrir todo lo que realmente hay detrás del IDE. No es solamente un editor con IA. Hay todo un sistema alrededor de cómo gestionar el contexto de la IA, cómo configurar el comportamiento del IDE y cómo gobernar lo que hace.
Ahí es donde empiezan a aparecer conceptos como:
- steerings
- hooks
- MCPs
- powers
- agentes
- prompts
- skills
Si ya estás usando Kiro, o estás pensando en usarlo, y aun no sabes como encajan todas estas piezas, este artículo es para ti.
TLDR: instalar Kiro
Si todavía no tienes Kiro instalado, aquí tienes los enlaces:
Con eso deberías poder tener el IDE funcionando en unos minutos.
A partir de aquí es donde empieza lo interesante.
Steerings
Los Steerings son simplemente archivos Markdown donde defines instrucciones, reglas o contexto que quieres que Kiro tenga en cuenta cuando trabaja en tu proyecto.
No solamente sirven para dar instrucciones. También pueden contener información estructural sobre tu proyecto.
Por ejemplo:
- La estructura y organizacion del repositorio
- Convenciones de código y nomenclatura
- Arquitectura del proyecto
- Como generar la documentación
Uno de los casos más comunes es pedirle a Kiro que genere los Foundational Steerings.
Cuando haces esto, Kiro escanea tu proyecto y genera varios archivos dentro del directorio de configuración de Kiro. Normalmente incluyen:
- producto
- estructura
- tech
Todo esto se genera usando el contexto que Kiro detecta en el repositorio. Es un buen punto de partida porque te da una base de documentación que la IA puede usar cuando trabaja en el código.
Steerings que recomiendo usar
Además de los foundational steerings, hay varios tipos que son bastante útiles añadir en proyectos reales.
Por ejemplo:
Reglas de trabajo en el proyecto
Cómo trabaja el equipo en ese repositorio. Esto puede incluir cosas como:
- Convenciones de nomenclaturas
- Estructura de carpetas
- Vision y Mision del projecto
Esto ayuda mucho a que Kiro no empiece a generar cosas que se salgan del estilo del proyecto.
Estilo de documentación
Puedes definir cómo se documenta el código, qué secciones deben aparecer, o cómo se escriben los READMEs.
Convenciones de arquitectura
Si tu proyecto sigue un patrón concreto, hexagonal, event driven, clean architecture, etc., tener eso definido en un steering ayuda bastante a mantener consistencia.
Cuanto más claro le dejes a Kiro cómo funciona tu proyecto, mejores resultados vas a obtener.
Hooks
Los Hooks son otra pieza bastante potente dentro de Kiro. Básicamente son prompts que se ejecutan automáticamente cuando ocurre un evento.
Unos ejemplos de esos eventos son:
- Cuando se crea, modifica o elimina un fichero
- Al empezar o terminar una tarea
- Manualmente
Un ejemplo bastante simple:
Si estás modificando archivos Markdown, puedes tener un hook que:
- Ejecute un lint
- Formatee el Markdown
- Revise enlaces rotos
Otro ejemplo:
Si estás modificando código, podrías tener un hook que genere automáticamente documentación sobre los cambios que se han hecho.
Esto abre la puerta a automatizar bastantes cosas dentro del flujo de desarrollo.
Cómo empezar con hooks
Los hooks tienen distinta maneras de dispararse: hook triggers
Mi recomendación es empezar siempre con hooks manuales.
Primero pruebas qué hacen, verificas que el resultado es el esperado y te aseguras de que no están haciendo nada raro.
Cuando ya estás contento con el resultado entonces sí puedes empezar a automatizarlos.
Recuerda que los hooks lanzan una tarea en Kiro, si tienes muchos hooks automatizados eso puede acarrear un coste elevado de creditos. Esa fue una de las primeras lecciones que aprendi con los hooks.
MCPs
Los MCPs son otra de las piezas importantes dentro de Kiro y de la IA en general.
Para explicarlo de una manera muy sencilla, un MCP es básicamente como una API para que la IA lo use. Los MCPs permiten conectar la IA con servicios externos. Le da acceso a información o herramientas que normalmente no estarían dentro del contexto del proyecto.
Algunos ejemplos bastante comunes:
- Cocumentación de AWS
- Context7 para documentación técnica
- Integración con Atlassian, como Jira o Confluence
Puedes conectar Kiro con documentación, herramientas externas o sistemas internos del equipo y hacer que la IA pueda trabajar con todo eso.
Powers
La parte no tan buena de los MCPs es que añade contexto dentro de la sesión de IA. Y cuantos mas MCPs tengas activados mas contexto va a consumir, causando que te cueste mas las tareas.
Muchas veces no necesitas tener todos los MCPs activos todo el tiempo. Y aquí es donde entran los Kiro Powers.
Los powers permiten encapsular tareas o dominios que se repiten mucho. Includas tareas que usen MCPs.
Imaginate que tienes un MCP de la base de datos Supabase. Pero para esta tarea sabes que no vas a necesitar la base de datos. Si lo encapsulas con un Power, Kiro lo invocaria solo cuando necesites la base de datos, liberandote el contexto que usaria ese MCP cuando no lo uses.
Hace tiempo escribir un articulo sobre la creacion de mi primer Power (esta en Ingles, sorry): Construyendo mi primer Kiro Power - Posthog Observability.
Agentes customizables
A principios de este año, Kiro anuncio los agentes customizables o sub-agentes. Los agentes ya existian dentro de Kiro, esto lo habréis visto si ya habéis hecho el spec-driven development en el IDE o el modo plan con el CLI. Ambos usan agentes que ya están definidos dentro de Kiro, para ejecutar una tipo especifico de tarea.
Los agents tienen una structura y un prompt propio que lo hace comportarse de la manera especificada.
Lo que hacen es que tienen una estructura y un prompt interno en el cual solamente aparece el agente. Tiene ciertas herramientas en las cuales están habilitadas o no. Y pueden tener selecionado un modelo.
Por ejemplo, el agente del plan se comporta como un guia para planificar una tarea dada, te hace preguntas acerca de la tarea y te hace un plan detallado. Este agente tiene la herramienta de escribir ficheros deshabilitada, ya que solamente es un plan el que vas a hacer, no vas a hacer la implementación.
El plan es un agente que ya estaba pre-definido por Kiro. Ahora tú puedes hacer los tuyos propios, lo que significa que puedes llevar esto al siguiente nivel. O cuatro niveles mas alla. Y por que cuatro? porque con los sub-agentes puedes tener cuatro agentes corriendo en paralelo.
Cómo uso yo los agentes customizables
Los agentes que siempre uso son agentes que estén relacionados con lo que estás haciendo en el proyecto como tal.
Por ejemplo, tengo un proyecto que es de TypeScript, pues tengo un agente que es experto en TypeScript. Tiene un prompt especifico de como trabajar como un experto de TypeScript. Y le doy a habilitar tools de write y read.
Consejo de LLMs para planificación y arquitectura
Otro ejemplo que tengo es para tareas de planificación, arquitectura y toma de decisiones.
Normalmente, si le preguntas al mejor modelo que tengas, te puede dar una opción que sea bastante buena, pero lo ideal es que tengas varias opciones, ya que la IA es no-deterministica y puede alucinar.
A la hora de hacer planificación, arquitectura, toma de decisiones, asuntos en los cuales sea más crear un plan o un diseño, y no una implementación, en la vida real te juntas con un equipo, haces una lluvia de ideas y tienes diferentes opiniones por parte del equipo.
¿Cómo llevariamos esto dentro de Kiro? Tienes agentes customizables que tienen un prompt específico, por ejemplo en planificar. Como en los agentes customizables tú puedes decir qué modelo está usando, le puedes dar un modelo distinto para el mismo tipo de agente. Por ejemplo: Opus, Sonnet, Haiku y Auto, cuatro modelos.
A la hora de hacer un plan, le pido a Kiro que use mi Consejo de Agentes en paralelo. Kiro lanza estos cuatro modelos corriendo en paralelo haciéndome un plan independiente cada uno. Una vez terminan, el agente por defecto me compila esos cuatro planes, cogiendo lo mejor de cada uno.
Esto es algo que cambia el modelo de hacer una planificación completamente. Haces un brainstorming de varios modelos y te aseguras de tener siempre lo mejor de lo mejor. A lo mejor un modelo puede alucinar, pero que cuatro alucinen a la vez es más difícil.
Spec-driven development
La parte que me llamó más la atención de Kiro es el spec-driven development que ya estaba incluido dentro del IDE.
Para los desarolladores este no es un concepto del todo nuevo, es parecido a definir un ticket, darle unos requerimientos, sacar el diseño y luego implementar el ticket basado en distintas sub-tareas.
El spec-mode de Kiro te crea unos requerimientos, un diseño y genera una lista de tareas, todo en ficheros markdown, en los cuales tú los puedes revisar y tener contexto de tu aplicación o tu repositorio.
Si os interesa que escriba un articulo mas centrado en Spec-Driven Development, dejadme un comentario con vuestro interes.
Conclusión
En este artículo hemos visto lo que son los Steerings, Hooks, MCPs, Powers y los agentes customizables, y hemos visto por encima el spec-driven development.
Todas estas funcionalidades dentro de Kiro se define como el contexto de la IA. Si habeis escuchado hablar del Context-Driven Development, es este contexto al que se refieren.
Este articulo es el resultado de un aprendizaje que he hecho a lo largo de los meses. Y el aprendizaje es continuo, me sigo encontrando nuevas funcionalidades, como por ejemplo los skills, que no los he mencionado, pero es algo que también está incluido dentro de Kiro y es se han hecho muy famosos recientemente.
Si no estás usando Kiro, te recomendaría que lo pruebes, tanto el IDE como por la línea de comandos, el CLI, y que pruebes el spec-driven development.
Y si te interesa saber mas sobre Kiro, el Context-Driven Development y de Spec-Driven Development, o quieres comentar tu experiencia con Kiro, no dudes en contáctarme o escríbelo en los comentarios.
Top comments (0)