Amazon Q Developer CLI ahora es Kiro CLI — ¿Qué cambió y por qué importa?

Si llevas un tiempo en el ecosistema AWS y usas herramientas de desarrollo con IA, probablemente ya notaste el cambio: Amazon Q Developer CLI ya no existe como tal. Ahora se llama Kiro CLI. Y no, no es solo un rebrand de nombre — es un cambio de filosofía completo.

Vamos a explorar qué pasó, qué cambió realmente, y por qué creo que esto importa más de lo que parece.

---

Un poco de contexto: ¿qué era Amazon Q Developer CLI?

Amazon Q Developer era el asistente de IA de AWS para desarrolladores. Tenía una versión en el IDE (VS Code, JetBrains), una versión en la consola de AWS, y también una CLI que te permitía interactuar con tu entorno desde la terminal usando lenguaje natural.

La idea era buena: preguntarle a un agente directamente desde tu terminal cosas como "¿qué instancias EC2 tengo corriendo en us-east-1?" o "genera un script para limpiar buckets S3 sin versioning". Útil, pero limitado en su enfoque — era básicamente un chatbot en tu terminal.

---

Entonces, ¿qué es Kiro?

Kiro es un IDE agéntico construido sobre VS Code, lanzado por AWS. Pero lo que muchos no saben es que también tiene una CLI — Kiro CLI — que reemplaza directamente a Amazon Q Developer CLI.

Lo interesante es que Kiro no es solo "Q con otro nombre". El cambio refleja una evolución real en cómo AWS piensa las herramientas de desarrollo:

Amazon Q Developer CLI	Kiro CLI
Asistente conversacional en terminal	Agente con contexto del proyecto
Respuestas puntuales	Spec-driven + MCP-driven + Steering-driven
Foco en queries rápidas	Foco en workflows completos
Sin memoria de proyecto	Entiende tu arquitectura y convenciones
Comando: q chat	Comando: kiro-cli chat

La idea aquí es que Kiro no solo responde preguntas — razona sobre tu proyecto, lee tus steering files, se conecta a herramientas externas vía MCP, y actúa en consecuencia.

---

El cambio más importante: de "asistente" a "agente"

En la práctica esto significa que Kiro CLI opera con capacidades que Amazon Q Developer CLI nunca tuvo de forma nativa:

Core Features de Kiro CLI

• Interactive Chat — Conversaciones en lenguaje natural directamente en tu terminal con kiro-cli chat. Puede leer y escribir archivos, ejecutar comandos, y razonar sobre tu código.

• Custom Agents — Puedes crear y desplegar agentes especializados para tus workflows específicos. No estás limitado al agente genérico.

• MCP Integration — Conecta herramientas y fuentes de datos externas a través del Model Context Protocol. Esto es enorme — puedes conectar Kiro CLI a servidores MCP de CloudWatch, MSK, OpenSearch, Okta, y muchos más.

• Smart Hooks — Automatiza workflows con hooks inteligentes que se ejecutan antes o después de comandos específicos.

• Agent Steering — Guía al agente con las mejores prácticas y preferencias de tu equipo usando steering files. Esto es lo que hace que Kiro entienda tu contexto, no solo el contexto genérico.

• Auto Complete — Sugerencias inteligentes de comandos con contexto mientras escribes en la terminal.
  

# Antes con Amazon Q Developer CLI
q chat "lista mis funciones Lambda en us-east-1"

# Ahora con Kiro CLI — con contexto de proyecto y MCP
kiro-cli chat
> revisa las funciones Lambda del proyecto y sugiere optimizaciones basándote en las métricas de CloudWatch

La diferencia no es solo sintáctica. Kiro sabe qué proyecto es, tiene acceso a tus herramientas vía MCP, y puede actuar sobre eso.

---

¿Cómo instalar Kiro CLI hoy?

La instalación es directa:

# macOS / Linux
curl -fsSL https://cli.kiro.dev/install | bash

# Windows (PowerShell)
irm 'https://cli.kiro.dev/install.ps1' | iex

# Verificar instalación
kiro-cli --version

Una vez instalado, empezar es así de simple:

# Navega a tu proyecto
cd mi-proyecto

# Inicia Kiro CLI
kiro-cli

# O directamente al chat
kiro-cli chat

Otros comandos útiles

# Traducir lenguaje natural a comandos bash
kiro-cli translate "muestra los últimos 10 logs de mi función Lambda"

# Habilitar sugerencias inline (requiere zsh)
kiro-cli inline enable

# Deshabilitar sugerencias inline
kiro-cli inline disable

Lo interesante es que kiro-cli translate convierte tu instrucción en el comando bash correspondiente sin ejecutarlo — tú decides si lo corres o no. Perfecto para aprender comandos complejos de AWS CLI.

---

Kiro CLI en CloudShell

Si no quieres instalar nada localmente, Kiro CLI ya viene disponible en AWS CloudShell. Solo abre CloudShell y ejecuta kiro-cli.

Las sugerencias inline en CloudShell requieren Z shell:

# Cambiar a zsh en CloudShell
zsh

# Las sugerencias inline se habilitan automáticamente
# Para deshabilitarlas:
kiro-cli inline disable

---

Agent Steering: dale contexto persistente a Kiro CLI

Esta es una de las features más importantes de Kiro CLI y la que marca la diferencia real con lo que teníamos en Amazon Q Developer CLI. Los steering files son archivos markdown que le dan a Kiro conocimiento persistente sobre tu proyecto, tu stack, y las convenciones de tu equipo.

La idea aquí es simple: en vez de re-explicar tu proyecto cada vez que abres una sesión, escribes un steering file una vez y Kiro lo lee automáticamente en cada interacción.

¿Qué poner en un steering file?

Un steering file es un .md que vive en tu proyecto (típicamente en .kiro/steering/) y puede contener:

• Stack tecnológico — qué lenguajes, frameworks y servicios usas
• Convenciones del equipo — naming conventions, patrones de diseño, estructura de carpetas
• Contexto de infraestructura — nombres de instancias, ubicación de logs, usuarios del sistema
• Requisitos de compliance — estándares de seguridad, accesibilidad, auditoría
• Reglas de negocio — lógica específica de tu dominio que el agente debe respetar

Ejemplo real: steering file para un proyecto serverless

# Project Context

## Stack
- Runtime: Python 3.12 on AWS Lambda
- API: Amazon API Gateway (REST)
- Database: Amazon DynamoDB (single-table design)
- IaC: AWS CDK (Python)

## Conventions
- All Lambda handlers go in `src/handlers/`
- Business logic goes in `src/services/` — never in handlers
- Use structured logging with aws-lambda-powertools
- DynamoDB access patterns use PK/SK with GSI1

## Security
- All API endpoints require IAM authorization
- No hardcoded credentials — use environment variables from Secrets Manager
- Input validation on every handler entry point

Lo que hace esto particularmente poderoso es que Kiro CLI usa este contexto en cada interacción. Si le pides que genere un nuevo endpoint, va a seguir tus convenciones automáticamente — handlers en src/handlers/, lógica en src/services/, con powertools y validación de input. Sin que tengas que repetirlo.

Steering files en la práctica

El blog de AWS sobre Oracle EBS con Kiro CLI muestra un caso real: usan steering files para darle a Kiro el conocimiento de su entorno Oracle — patrones de nombres de instancias, usuarios del OS, ubicación de logs y scripts. Así, cuando preguntan "¿está sano el concurrent manager?", Kiro ya sabe dónde buscar sin que se lo expliquen cada vez.

Para equipos, esto es oro. Un nuevo developer se une, clona el repo, y Kiro CLI ya tiene todo el contexto del proyecto en los steering files. La curva de onboarding se reduce dramáticamente.

---

Spec-Driven Development: ¿disponible en Kiro CLI?

Acá hay que ser claros porque es una pregunta que muchos se hacen. Spec-Driven Development es una feature del Kiro IDE, no de Kiro CLI.

Según la documentación oficial de Kiro, las Specs viven bajo la sección de documentación del IDE (/docs/specs/), y no aparecen en la sidebar de la CLI. La CLI tiene: Chat, Custom Agents, MCP, Hooks, Steering, Autocomplete, y Headless — pero no Specs.

¿Qué es Spec-Driven Development?

Para los que no lo conocen, es el workflow estrella de Kiro IDE. Funciona así:

1. Le describes tu idea al agente en lenguaje natural
2. Kiro genera requirements estructurados (en formato EARS)
3. Kiro crea un design document con arquitectura, modelos de datos, APIs
4. Kiro produce un plan de implementación con tareas concretas y ordenadas
5. Kiro ejecuta cada tarea — escribe código, tests, documentación

Cada spec genera tres archivos clave: requirements.md, design.md, y tasks.md. Hay dos tipos de specs: Feature Specs (para funcionalidades nuevas) y Bugfix Specs (para diagnosticar y corregir bugs).

¿Por qué no está en la CLI?

Mi lectura es que Spec-Driven Development requiere una experiencia visual que la terminal no puede ofrecer fácilmente — la navegación entre archivos de spec, la vista de progreso de tareas, y la interacción con el design document son inherentemente visuales. La CLI está optimizada para workflows más directos: chat, automatización, MCP, y headless.

¿Qué usar entonces?

Necesidad	Herramienta
Desarrollar features completas con specs	Kiro IDE
Chat agéntico desde la terminal	Kiro CLI
Automatización y CI/CD	Kiro CLI (headless)
Conectar herramientas externas vía MCP	Kiro CLI o Kiro IDE
Steering files para contexto de equipo	Kiro CLI o Kiro IDE
Troubleshooting rápido de AWS	Kiro CLI

Mi recomendación: usa ambos. Kiro IDE para desarrollo de features con specs, y Kiro CLI para todo lo que haces en la terminal — troubleshooting, automatización, operaciones, y CI/CD. Los steering files funcionan en ambos, así que tu contexto de proyecto se comparte.

---

MCP: lo que hace a Kiro CLI realmente poderoso

El Model Context Protocol es un estándar abierto que permite a agentes de IA conectarse de forma segura con herramientas externas, fuentes de datos y servicios. En la práctica esto significa que puedes extender las capacidades de Kiro CLI conectándolo a servidores MCP especializados.

Algunos ejemplos reales que ya existen:

Servidor MCP	Qué hace
CloudWatch MCP	Consulta métricas, logs y alarmas con lenguaje natural
Amazon MSK MCP	Administra clusters de Kafka — topics, configuraciones, health
AWS Diagram MCP	Genera diagramas de arquitectura AWS desde prompts
OpenSearch MCP	Busca índices, inspecciona estado del cluster, diagnósticos
Okta MCP	Gestión de identidades — usuarios, grupos, permisos
AWS Documentation MCP	Busca y lee documentación de AWS en contexto

La configuración de un servidor MCP se hace en ~/.kiro/settings/mcp.json. Una vez configurado, Kiro CLI tiene acceso a las herramientas del servidor y las usa automáticamente cuando son relevantes para tu pregunta.

Lo que hace esto particularmente poderoso es que puedes combinar múltiples servidores MCP. Imagina preguntarle a Kiro CLI: "¿por qué mi aplicación está lenta?" y que automáticamente consulte CloudWatch para métricas, OpenSearch para logs, y te dé un diagnóstico completo — todo desde tu terminal.

---

Los métodos de login — esto es clave

Acá es donde la cosa se pone interesante de verdad, porque Kiro CLI hereda el modelo de autenticación de Amazon Q Developer pero con matices que importan. Hay cuatro formas de conectarte, y cada una te da acceso a cosas diferentes:

1. Builder ID (Free) — para empezar rápido

Es la forma más simple. Te creas un AWS Builder ID gratis (con tu email, Google, Apple, GitHub o Amazon) y listo, ya puedes usar Kiro CLI y el IDE.

La limitación: tienes límites mensuales de uso y solo funciona en el IDE y la CLI. No tienes acceso a la consola de AWS ni a features avanzados. Pero para proyectos personales y exploración, es más que suficiente.

2. Builder ID + Pro — más límites, tu propia cuenta AWS

Acá es donde empieza a ponerse bueno. Puedes hacer upgrade de tu Builder ID al tier Pro conectándolo a tu propia cuenta de AWS. Esto te da límites de uso mucho más altos.

# Inicia chat con Kiro CLI
kiro-cli chat

# Dentro del chat, escribe:
/subscribe
# Esto abre la consola de AWS para confirmar la suscripción Pro

El punto clave es que con Builder ID Pro tienes límites más altos, pero no todas las features Pro. Algunas features avanzadas solo están disponibles vía IAM Identity Center.

3. IAM Identity Center (Free) — para equipos y organizaciones

Si tu empresa ya usa IAM Identity Center (antes AWS SSO), puedes autenticarte con tu identidad corporativa. Esto te da acceso a la consola de AWS, apps y websites de AWS — algo que Builder ID no puede hacer.

Ideal si tu admin ya configuró el Identity Center en la organización.

4. IAM Identity Center + Pro — el combo completo 🔥

Y acá está el gold standard. Tu admin te suscribe a Amazon Q Developer Pro vía IAM Identity Center, y tienes acceso a todo: CLI, IDE, consola, apps de AWS, features avanzados, límites altos, y control empresarial.

Lo que hace esto particularmente poderoso es que tu empresa tiene control total: puede suscribir usuarios en bulk, trackear uso, cancelar suscripciones, y tú como developer tienes la experiencia completa en todos los canales.

La guía rápida de acceso

🆓 Builder ID — Free

✅ CLI · ✅ IDE · ❌ Consola AWS · ❌ Features Pro
→ Para empezar rápido con proyectos personales

💰 Builder ID — Pro

✅ CLI · ✅ IDE · ❌ Consola AWS · ⚠️ Features Pro parciales
→ Límites más altos, pero no el suite completo

🏢 IAM Identity Center — Free

❌ CLI · ❌ IDE · ✅ Consola AWS · ❌ Features Pro
→ Solo consola, ideal si tu admin aún no activó Pro

🔥 IAM Identity Center — Pro

✅ CLI · ✅ IDE · ✅ Consola AWS · ✅ Features Pro completos
→ La experiencia completa — el gold standard

Mi recomendación sincera: si eres developer individual, empieza con Builder ID Free y cuando sientas los límites, haz upgrade a Pro con tu cuenta AWS. Si estás en una empresa, pídele a tu admin que configure IAM Identity Center con Pro — es la experiencia más completa y además puedes usarlo desde Kiro IDE con toda la potencia.

---

Headless Mode: Kiro CLI en CI/CD

Una capacidad nueva que no existía en Q Developer CLI es el modo headless — puedes ejecutar prompts de forma no interactiva usando API keys. Esto abre la puerta a integrar Kiro CLI en pipelines de CI/CD.

En la práctica esto significa que puedes automatizar tareas como:

• Revisión de código automatizada en PRs
• Generación de documentación en cada merge
• Análisis de seguridad como paso del pipeline
• Generación de tests para código nuevo

---

¿Debería migrar ya?

Sí, y sin dudarlo. Amazon Q Developer CLI ya no recibe actualizaciones activas. Todo el desarrollo está en Kiro CLI.

Pero más allá de la migración técnica, lo que me parece más valioso es el cambio de mentalidad que propone Kiro: dejar de usar la IA como un buscador glorificado y empezar a usarla como un agente que entiende tu contexto, se conecta a tus herramientas, y trabaja contigo en workflows reales.

La migración en sí es simple:

# 1. Instalar Kiro CLI
curl -fsSL https://cli.kiro.dev/install | bash

# 2. Donde antes usabas 'q chat', ahora usas:
kiro-cli chat

# 3. Donde usabas 'q translate', ahora:
kiro-cli translate "tu instrucción aquí"

---

El takeaway principal

El cambio de Amazon Q Developer CLI a Kiro CLI no es cosmético. Es una señal clara de hacia dónde va AWS con sus herramientas de desarrollo: agentes con contexto persistente, conectados a tus herramientas vía MCP, que entienden las convenciones de tu equipo vía steering files, y que pueden actuar — no solo responder.

Las capacidades clave que ganamos:

• kiro-cli chat — Chat agéntico con capacidad de leer/escribir archivos y ejecutar comandos
• kiro-cli translate — Traduce lenguaje natural a bash
• kiro-cli inline — Sugerencias inteligentes mientras escribes
• MCP Integration — Conecta herramientas externas (CloudWatch, MSK, OpenSearch, etc.)
• Agent Steering — Dale contexto persistente a Kiro con las prácticas y convenciones de tu equipo
• Custom Agents — Crea agentes especializados para tus workflows
• Smart Hooks — Automatización pre/post comandos
• Headless Mode — Integración con CI/CD vía API keys

Y un punto importante: Spec-Driven Development es exclusivo del Kiro IDE. Si quieres el workflow completo de specs (requirements → design → tasks → implementación), necesitas el IDE. La CLI es para chat, automatización, MCP, y operaciones desde la terminal. Ambos comparten steering files, así que tu contexto de proyecto funciona en los dos.

Mi recomendación: instala Kiro CLI, crea un steering file para tu proyecto más activo, conecta un servidor MCP relevante para tu stack, y experimenta. La curva de aprendizaje es corta y el salto de productividad es real.

---

Yo soy Carlos Cortez y esto es Breaking the Cloud — nos vemos pronto.

Sígueme en:

• 🔗 LinkedIn
• 🐦 X / Twitter
• 💻 GitHub
• 📝 Dev.to
• 🦸 AWS Community
• ✍️ Medium