¿Qué es Kiro? El IDE agéntico de AWS para Spec-Driven Development

La herramienta que mete la spec dentro del IDE no garantiza una buena spec. Garantiza un camino rápido hacia una spec mediocre si te saltas la parte de pensar. El método va primero.

Kiro es el IDE agéntico de AWS construido alrededor de spec-driven development. Le das un prompt y genera una especificación estructurada: tres archivos markdown con requisitos, diseño de arquitectura y tareas de implementación en secuencia. Después le pasa esos archivos a agentes en paralelo que escriben el código. Funciona como IDE descargable, como CLI y como interfaz en el navegador. Está construido sobre Code OSS (la base open source de VS Code) y corre los modelos Claude de Anthropic (hasta Opus 5.5 y Sonnet 5), la familia GPT-5.6 de OpenAI y varias alternativas open-weight. No necesitas una cuenta de AWS para empezar.

Practico spec-driven development todos los días con Claude Code y mi propio pi-sdd-kit. No he usado Kiro en producción a la escala de la fintech cripto que construí (13 apps, 70 días, solo), pero estudié su documentación a fondo, seguí la conversación en la comunidad y leí la evaluación práctica de Birgitta Böckeler en Thoughtworks. Lo que sigue es la lectura honesta de alguien que lo practica: qué es Kiro, cómo funciona realmente su workflow, dónde aporta valor real y dónde están los límites.

Qué es Kiro en realidad

Kiro es un IDE que convierte el spec-driven development en el workflow por defecto, en lugar de algo que armas tú mismo. Donde yo construyo archivos de contexto, documentos de steering y un gate .status con markdown plano y Claude Code, Kiro empaqueta las mismas ideas en un panel gráfico, archivos con nombre en una carpeta .kiro/ del workspace y una UI que te lleva paso a paso por requisitos, diseño y tareas antes de escribir cualquier código.

La idea central de SDD es la misma que uso a diario: la spec es la fuente de verdad y el código es el resultado. Lo que cambia es la superficie. Kiro es IDE primero, no agente más toolkit. Lo instalas, abres un proyecto, haces clic en el panel Specs y el workflow arranca. El trabajo estructural que a mí me lleva una hora montar en un proyecto nuevo ya está ahí.

El flujo de specs en tres archivos

Toda feature en Kiro empieza con un prompt. A partir de él, Kiro genera tres documentos markdown en secuencia, con un gate de aprobación humana entre cada uno. El workflow tiene dos variantes: Requirements-First (comportamiento primero, después diseño, después tareas) y Design-First (arquitectura técnica primero, después requisitos, después tareas). Requirements-First es el predeterminado para la mayor parte del trabajo guiado por producto. Design-First sirve para sistemas restringidos, donde la arquitectura es la restricción de partida. Los bugs tienen su propio tipo de spec: una bugfix spec cambia requirements.md por bugfix.md, que guarda el análisis del bug en lugar de user stories. Y, para features bien entendidas, Quick Spec genera los tres archivos sin los gates de aprobación.

El workflow Requirements-First de Kiro

Entrada

Un prompt que describe la feature o el comportamiento que quieres construir

↓

1. 01requirements.md

   Kiro genera requisitos en formato EARS: condiciones WHEN y comportamientos THE SYSTEM SHALL. Antes de pasar al diseño, puedes pedirle a Kiro que analice los requisitos en busca de contradicciones, ambigüedades y huecos. Gate humano antes de seguir.

   ↓
2. 02design.md

   Arquitectura, flujo de datos, modelos de datos, manejo de errores y estrategia de testing. Cada requisito del paso uno se traduce en una decisión de diseño. Gate humano antes de generar las tareas.

   ↓
3. 03tasks.md

   Una lista secuenciada de tareas de implementación, cada una vinculada a números de requisito concretos. El IDE tiene controles para ejecutar las tareas una por una y revisar los cambios de cada tarea.

   ↓
4. 04Implementación

   Agentes en paralelo ejecutan las tareas de tasks.md. En el IDE, tests basados en propiedades opcionales (aserciones de corrección al estilo fuzz) atrapan problemas que pasan los tests unitarios pero se rompen con entradas de edge case.

↓

Salida

Código que funciona, con una cadena trazable desde el prompt original hasta requisitos, diseño y tareas aprobados

La estructura de workspace que Kiro crea alrededor de este workflow:

Estructura del workspace de Kiro

• .kiro/
  • steering/memory bank
    • product.md// propósito del producto, usuarios objetivo, objetivos de negocio
    • tech.md// frameworks, librerías, restricciones, stack preferido
    • structure.md// organización de archivos, convenciones de nombres, arquitectura
  • hooks/automatización
    • lint-on-save.json// ejemplo: correr el linter después de cada archivo que guarda el agente
  • specs/trabajo de features
    • user-auth/
      • requirements.md// comportamientos en EARS y criterios de aceptación
      • design.md// arquitectura, modelos de datos, contratos de API
      • tasks.md// tareas en secuencia, trazables hasta los requisitos

La carpeta steering es el equivalente en Kiro de lo que yo llamo la capa steering/ en mi setup con Claude Code: contexto de producto estable que el agente carga en cada sesión, para que nunca tengas que volver a explicar las mismas decisiones. La carpeta hooks guarda los disparadores de automatización. La carpeta specs guarda el trabajo de features en curso.

Los requisitos usan notación EARS

Kiro escribe los requisitos en EARS, el Easy Approach to Requirements Syntax. El patrón es simple:

WHEN a user submits a form with invalid data
THE SYSTEM SHALL display validation errors next to the relevant fields

Esto no le deja al agente margen para interpretar. “Errores de validación” se convierte en un resultado concreto y testeable, no en una instrucción vaga. Kiro también puede correr un paso de análisis antes del diseño, revisando la lista completa de requisitos en busca de inconsistencias lógicas, ambigüedades y huecos. Detectar una contradicción en los requisitos cuesta segundos. Detectarla después de generar el diseño cuesta rediseñar.

La explicación completa de EARS y de por qué importa está en el artículo base sobre spec-driven development. La versión corta: es un formato de 30 años, de la ingeniería de requisitos, pensado justo para la ambigüedad que arruina el código generado por IA. Kiro lo adoptó como formato por defecto, y fue la decisión correcta.

Los hooks convierten la disciplina en automatización

Los hooks son uno de los diferenciales más prácticos de Kiro. Un hook es un disparador por eventos que ejecuta un prompt de agente o un comando de shell cuando pasa algo concreto en el IDE. Los defines como archivos JSON en .kiro/hooks/.

La lista completa de disparadores:

• PostFileSave, PostFileCreate, PostFileDelete (el agente tocó un archivo)
• UserPromptSubmit y Stop (eventos de la conversación)
• PreToolUse y PostToolUse (ciclo de vida de las herramientas del agente)
• PreTaskExec y PostTaskExec (antes o después de que corra una tarea de la spec)
• SessionStart y SessionEnd (solo en la CLI, agregados en septiembre de 2026)

Algunos disparadores pueden bloquear al agente (PreToolUse, UserPromptSubmit, PreTaskExec) devolviendo exit code 2. Otros corren después y agregan contexto. Un hook PostFileSave que pasa el linter por cada archivo TypeScript que guarda el agente son tres líneas de JSON. Un hook PostTaskExec que actualiza la documentación después de cada tarea terminada es un prompt corto. Lo que de otro modo tendrías que acordarte de hacer a mano pasa a ser estructura.

En mi setup con Claude Code, dependo del hábito y de un subagent revisor para atrapar lo que se me pueda olvidar. En Kiro, los hooks ponen esas verificaciones en el proyecto, no en la memoria de quien desarrolla. Para equipos donde no todos tienen la misma disciplina, es una diferencia importante.

Steering es el memory bank que sobrevive a la sesión

Kiro llama “steering” a su sistema de contexto persistente. Los archivos de steering viven en .kiro/steering/ y se cargan por defecto en cada interacción con el agente. Los tres archivos base que Kiro genera automáticamente son product.md, tech.md y structure.md. Puedes agregar todos los archivos que quieras.

Los archivos de steering soportan cuatro modos de inclusión, más granular que cualquier cosa que yo armé a mano:

• Always: se carga en cada interacción, para los estándares centrales
• fileMatch: se carga solo cuando trabajas con archivos que coinciden con un patrón definido
• manual: se carga bajo demanda, referenciando el archivo en el chat con un prefijo de hash
• auto: se carga cuando el pedido coincide semánticamente con la descripción del archivo

Los modos condicionales hacen que un security-standards.md solo se cargue cuando tocas código de autenticación, y el contexto queda limpio en las sesiones que no tienen nada que ver. Los archivos de steering globales (en ~/.kiro/steering/) aplican a todos los workspaces, lo que permite a los equipos distribuir convenciones compartidas a las máquinas de todos automáticamente.

Esto es paralelo directo al enfoque que describo en spec-driven development con Claude Code, donde la carpeta steering/ tiene cuatro archivos (producto, stack técnico, convenciones, principios) que le dan al agente el contexto de producto que necesita antes de que empieces una sesión. Kiro formaliza el mismo patrón con una UI y una carga más flexible.

Cómo se compara Kiro con las alternativas

Hoy existen tres enfoques distintos de spec-driven development en AI coding: Kiro, GitHub Spec Kit y setups de agente más toolkit, como Claude Code con pi-sdd-kit. Uno no reemplaza al otro. Apuntan a workflows distintos y a preferencias distintas de control.

Kiro vs GitHub Spec Kit vs Claude Code con pi-sdd-kit

Los tres están en puntos distintos de la escala entre integración y control. Más integración es un arranque más rápido y menos setup a medida. Más control es más configuración, pero el workflow se ajusta exactamente a tus restricciones y a tu editor.

Dimensión	Kiro	GitHub Spec Kit	Claude Code + pi-sdd-kit
Formato de entrega	IDE (basado en VS Code), CLI, interfaz web	CLI más skills en 40+ agentes	Agente de terminal más kit npm, cualquier editor
Pipeline de specs	requirements.md, design.md, tasks.md con gates de aprobación en la UI	spec, plan, tasks, después implement y converge	PRD, SPEC, TASKS, EXEC, REVIEW vía gate de token en .status
Sistema de memoria	Archivos de steering en .kiro/steering/, cuatro modos de inclusión	constitution.md (archivo de reglas de alto nivel)	steering/ con archivos de producto, tech, convenciones y principios
Gate de aprobación	Paso visual en la UI, en el panel del IDE, entre cada fase	Ninguno: --require-spec solo verifica que el archivo exista	Token explícito en .status: que el archivo exista no es aprobación
Automatización	Hooks: disparadores por eventos de archivo, herramienta y tarea	Workflows en YAML y hooks de extensión	Subagent revisor, hábito y disciplina de workflow
Verificación de corrección	Tests basados en propiedades opcionales (estilo fuzz), solo en el IDE	Converge verifica el código contra los artefactos	Subagent revisor que verifica contra los criterios de la spec
Requisito de editor	El IDE Kiro reemplaza tu editor; la CLI corre en cualquier lugar	Cualquier editor, con cualquier agente compatible	Cualquier editor, Claude Code corre en la terminal
Precio	Plan gratuito (50 créditos), planes pagos desde US$ 20/mes	Open source, gratuito	pi-sdd-kit es gratuito, requiere suscripción a Claude Code

La comparación más a fondo entre GitHub Spec Kit y el enfoque de pi-sdd-kit está en el artículo sobre el workflow con Claude Code, incluido por qué uso un gate de token en .status en lugar de un paso visual en la UI: la verificación mecánica elimina la ambigüedad que una persona leyendo un archivo terminado todavía puede pasar por alto. Para la decisión entre los dos, mira Kiro vs Claude Code.

La crítica honesta: tres cosas a vigilar

Birgitta Boeckeler, Distinguished Engineer en Thoughtworks, publicó en octubre de 2025 una evaluación práctica de Kiro, GitHub Spec Kit y Tessl. Sus observaciones son la crítica independiente más creíble del Kiro de los primeros tiempos y, aunque el producto evolucionó desde entonces, las preguntas que planteó siguen valiendo.

Un solo workflow para todos los tamaños de problema. Boeckeler probó Kiro con un bug fix pequeño y recibió cuatro user stories con dieciséis criterios de aceptación. El documento de requisitos convirtió un cambio sencillo en algo que ella describió como “matar moscas a cañonazos”. Desde entonces Kiro agregó Quick Spec, que genera los tres archivos sin los gates de aprobación para features bien entendidas, un tipo de spec bugfix dedicado, y un camino Design-First para trabajo con restricciones técnicas. Pero la pregunta sigue abierta: ¿un workflow de tres archivos con gates humanos aporta más valor que overhead en un cambio de dos horas? No siempre.

Revisar markdown en lugar de revisar código. El workflow spec-driven produce documentos para revisar antes de que exista el código. En teoría, atrapar errores en los requisitos es más barato que atraparlos en la implementación. En la práctica, Boeckeler encontró la revisión tediosa y dijo que prefería revisar código antes que markdown verboso. Es un costo de fricción real. Si no le das a la revisión atención de verdad, la vas a hacer a las apuradas, y una revisión apurada anula el sentido del gate. No es una falla exclusiva de Kiro, pero Kiro produce tres documentos separados para aprobar antes de que veas una línea de código.

Falsa sensación de control. Incluso con specs estructuradas, Boeckeler vio a los agentes saltarse instrucciones con frecuencia o aplicar otras de más. Context windows más grandes aumentan el riesgo de que el agente encuentre un patrón y lo siga al pie de la letra, o ignore una restricción que nunca salió a la superficie. Una spec crea las condiciones para un buen resultado. No lo garantiza. La spec es la memoria. El agente igual la interpreta. Esto aplica por igual a Kiro, a GitHub Spec Kit y al setup que uso con Claude Code.

Cuándo Kiro es la elección correcta

Kiro tiene más sentido cuando quieres spec-driven development sin armarlo tú mismo. Instalas el IDE, abres un proyecto, escribes un prompt en el panel Specs y el workflow arranca. No hay sistema de contexto que configurar, ni convención de gate que definir, ni prompts de subagent que escribir. El costo es cambiar de editor y aceptar el workflow tal como Kiro lo diseñó.

Más concretamente: Kiro encaja bien en equipos donde no todos los devs tienen la paciencia de escribir archivos de steering a mano y gestionar convenciones de gate manualmente. El paso de aprobación visual en el IDE es más difícil de saltarse que un archivo que simplemente puedes no actualizar. El sistema de hooks elimina categorías enteras de errores del tipo “me olvidé de correr el linter”. Los tests basados en propiedades atrapan problemas de corrección que los tests unitarios dejan pasar, verificando reglas sobre muchas entradas generadas, no solo sobre los casos que se te ocurrió escribir.

Kiro encaja peor si necesitas control preciso sobre la lógica del gate, trabajas con varios modelos y quieres cambiar entre ellos libremente, tienes requisitos de corrección complejos que piden pasos de verificación a medida, o ya tienes un setup con Claude Code que funciona. Cambiar de IDE tiene un costo real: memoria muscular, extensiones, configuración del editor, las terminales y herramientas que organizaste alrededor de tu entorno actual.

La comparación con vibe coding también aplica aquí. Kiro queda entre el vibe coding y un pipeline de SDD completamente a medida. Es más estructurado que mandar prompts directamente y menos configurable que construir tu propio workflow. No es una crítica. La mayoría de los equipos gana con más estructura y menos configuración. Depende de qué estés optimizando.

FAQ

¿Qué es Kiro?+

Kiro es un IDE agéntico construido y operado por AWS que hace del spec-driven development el workflow de código por defecto. Le das un prompt que describe una feature y genera requirements.md, design.md y tasks.md en secuencia, con gates de aprobación humana entre cada uno. Después, agentes en paralelo implementan el código a partir de esos archivos.

Está disponible como IDE descargable (construido sobre Code OSS, la base open source de VS Code), como CLI headless y como interfaz web. No necesitas una cuenta de AWS. Puedes entrar con GitHub, Google, AWS Builder ID o AWS IAM Identity Center.

¿Kiro es gratis?+

Sí, hay un plan gratuito permanente con 50 créditos al mes. Incluye acceso a Claude Sonnet 4.5 y a modelos open-weight como DeepSeek 3.2, Qwen3 Coder Next y MiniMax M2.1. Tiene límites de uso.

Los planes pagos empiezan en US$ 20 al mes por 1.000 créditos (Pro), después US$ 40 (Pro+, 2.000 créditos), US$ 100 (Pro Max, 5.000 créditos) y US$ 200 (Power, 10.000 créditos). Los créditos adicionales cuestan US$ 0,04 cada uno en los planes individuales. Los planes de equipo agregan facturación consolidada, SSO vía AWS IAM Identity Center, analítica de uso y controles de seguridad enterprise.

¿Quién hace Kiro?+

Kiro está construido y operado por AWS (Amazon Web Services). Corre sobre la infraestructura de AWS y hereda sus estándares de seguridad, confiabilidad y privacidad. Ofrece autenticación con IAM y SSO, funciones de gobernanza enterprise y soporte para GovCloud (US) en entornos regulados.

Los modelos de IA son los Claude de Anthropic (variantes Sonnet, Haiku y Opus, hasta Opus 5.5), el GPT-5.6 de OpenAI (Sol, Terra y Luna) y modelos open-weight como DeepSeek, Qwen, MiniMax y GLM. Un modo Auto elige el mejor modelo para cada tarea según complejidad, latencia y costo.

¿Kiro usa spec-driven development?+

Sí. SDD es el workflow central de Kiro, no un complemento opcional. Genera requirements.md, design.md y tasks.md a partir de un prompt, con un gate de aprobación humana entre cada fase. Los requisitos usan la notación EARS (condición WHEN, comportamiento THE SYSTEM SHALL), lo que hace que cada requisito sea directamente testeable.

Kiro también agrega un paso de análisis de requisitos antes del diseño (buscando contradicciones y huecos) y tests basados en propiedades después de la implementación, que verifican reglas de corrección sobre un rango de entradas generadas en lugar de un conjunto fijo de ejemplos.

Kiro vs Cursor: ¿cuál es la diferencia?+

Cursor es un fork de VS Code enfocado en código asistido por IA: sugerencias inline, ediciones en varios archivos y un agente conversacional. No tiene un workflow spec-driven incluido. Puedes aplicar prácticas de SDD en Cursor sumando GitHub Spec Kit o armando tu propia estructura, pero Cursor en sí es un editor con IA de propósito general.

Kiro está construido específicamente alrededor de SDD como workflow principal. El pipeline de specs (requisitos, diseño, tareas) es la puerta de entrada de cada feature, no un modo opcional. Si el spec-driven development es central en cómo quieres trabajar, esa diferencia pesa.

Kiro vs Claude Code: ¿cuál elegir?+

Son cosas de naturaleza distinta, no competidores directos. Kiro es un IDE con SDD integrado en la interfaz. Claude Code es un agente de terminal que corres dentro del editor que ya usas. Los dos pueden soportar workflows spec-driven, pero el pipeline de Kiro está integrado en la UI; en Claude Code tienes que armar o importar la estructura tú mismo (vía pi-sdd-kit, GitHub Spec Kit o markdown plano).

Si quieres un workflow de SDD listo, con gates visuales, automatización con hooks y el mínimo de setup, Kiro es el arranque más rápido. Si quieres control máximo sobre el pipeline, la lógica del gate de aprobación y los modelos que usas, Claude Code con un kit estructurado te da más flexibilidad, a costa de más configuración.

Dónde encaja esto en el panorama general

Kiro es un intento honesto de hacer del spec-driven development el camino de menor resistencia para los devs que no armarían el workflow por su cuenta. El pipeline de tres archivos es correcto. El sistema de hooks resuelve una fricción real. Los archivos de steering atacan el problema de memoria que sabotea cualquier proyecto asistido por agentes que dure más de una sesión.

Las críticas también son reales. Un workflow con opiniones fuertes no sirve para todos los tamaños de problema. Revisar markdown con presión de plazos produce la misma calidad de revisión que revisar código con presión de plazos: insuficiente. Una spec ayuda a la disciplina, no la reemplaza.

La herramienta viene después del método. El spec-driven development funciona porque escribir requisitos, diseño y tareas antes del código obliga a una claridad que ningún prompt logra. Kiro hace que esa obligación sea más fácil de alcanzar. Ya sea con Kiro, GitHub Spec Kit o Claude Code con un kit y algo de disciplina, lo que importa es la spec. La herramienta es solo la superficie.

Si ya haces SDD con Claude Code y te funciona, no hay una razón de peso para cambiar. Si empiezas de cero y quieres el workflow incluido desde la primera sesión, Kiro es el camino más directo.