Tus agentes están tomando decisiones de arquitectura. ¿Hay alguien registrándolas?
Puntos clave
- El problema de las herramientas de coding con IA no es producir código. Es que, seis meses después, nadie sabe por qué el código se ve como se ve. Kiro es el intento más directo de resolverlo.
- El desarrollo guiado por specs suma overhead. La pregunta no es si es más lento. Lo es. La pregunta es si tu equipo puede asumir el costo de la alternativa.
- Los modos de falla son reales: specs superficiales, falsa precisión por la notación EARS, ADRs que parecen completos pero no lo son. El flujo solo funciona si los gates de revisión se tratan como gates de verdad.
Las herramientas de coding con IA se han vuelto buenas produciendo código. Muy buenas. Frameworks multi-agente, asistentes agénticos, pipelines autónomos: si el problema es "convertir esta idea en código que funcione", las opciones sobran. Pero si construyes software en equipo, seguramente chocaste con el muro que aparece unas dos semanas después del demo impresionante: el código funciona, nadie sabe por qué se ve así y, cuando alguien pregunta por qué se tomó cierto enfoque, la respuesta honesta es "dejé que el agente decidiera, y no estoy del todo seguro".
Lo he visto pasar en varios equipos. El problema no es que el agente haya tomado malas decisiones. Es que casi toda herramienta de coding con IA en el mercado está optimizada para ejecutar tareas, y pocas invierten en los artefactos que mantienen coherente al desarrollo de software en equipo a lo largo del tiempo.
Kiro de Amazon, lanzado en preview en julio de 2025, es el intento más directo que he visto para cerrar esa brecha. Esto no es una comparación "Kiro vs. Cursor"; en velocidad pura para tareas individuales, Cursor, Claude Code y los frameworks multi-agente son formidables. La verdadera pregunta es si el modelo de desarrollo guiado por specs de Kiro, combinado con un flujo de Architecture Decision Record (ADR) que se configura a través de su sistema de Steering, le ofrece a los equipos algo que esas herramientas no: un registro compartido y revisable por humanos de cómo se diseñó el software y por qué.
El panorama multi-agente: poderoso, pero estructuralmente incompleto
La generación actual de frameworks multi-agente (CrewAI, LangGraph, AutoGen, MetaGPT) está madura. Empresas como DocuSign y PwC corren pipelines multi-agente en producción a escala. El argumento a favor de Kiro solo importa si aceptas que la alternativa ya es buena produciendo código.
Vale la pena examinar MetaGPT directamente — se usa en producción menos que LangGraph o CrewAI, pero es el que más se solapa con lo que Kiro promete entregar. Le das un requerimiento de una línea y produce artefactos estructurados: PRDs, documentos de diseño, especificaciones de interfaz, código de implementación. En el papel, cubre el mismo terreno que el flujo guiado por specs de Kiro.
La diferencia estructural no está en la calidad del output. Está en quién ve las decisiones y cuándo.
En MetaGPT, los agentes producen artefactos y los pasan al siguiente agente. El output es exhaustivo, pero el proceso es opaco: las decisiones que toma el agente Architect no aparecen como registros revisables. No hay un gate de aprobación donde tu equipo lea el documento de diseño y marque una restricción antes de que arranque la implementación. Los artefactos son outputs para consumir, no documentos colaborativos para revisar.
La misma brecha existe en los frameworks multi-agente en general. Son motores de ejecución excelentes. No fueron diseñados para producir un entendimiento compartido en el equipo sobre por qué el software se construyó de cierta manera. Eso es una decisión de diseño, no una carencia. Estos frameworks están optimizados para completar tareas. Kiro está optimizado para que el equipo pueda leer la historia a través del tiempo.
Lo que Kiro realmente hace
Kiro es un fork de VS Code impulsado por Claude Sonnet en Amazon Bedrock. El entorno familiar importa: no hay un IDE nuevo que aprender, no hay cambio de contexto, y los plugins, temas y configuraciones existentes de Open VSX se migran sin fricción. Como es un IDE de propósito general, Kiro funciona en distintos lenguajes y frameworks, aunque el flujo guiado por specs se demuestra de la forma más natural en el desarrollo backend y full-stack, donde las decisiones de arquitectura tienen mayor peso.
La diferenciación está en el flujo que impone.
Desarrollo guiado por specs: artefactos antes de la ejecución
Cada feature en Kiro empieza con un spec, un conjunto de archivos Markdown estructurados que se commitean al repositorio antes de escribir una sola línea de código. El proceso de tres fases es deliberado:
Fase 1: Requerimientos (requirements.md)
El primer gate es el que la mayoría de los equipos se salta por completo: requerimientos escritos, revisados y aprobados antes de que exista código. Describes lo que quieres en lenguaje natural. Kiro no empieza a programar. En lugar de eso, produce un documento formal de requerimientos usando la notación EARS (Easy Approach to Requirements Syntax), un formato que obliga a que cada requerimiento esté en una forma inequívoca y testeable:
WHEN [trigger condition] THE SYSTEM SHALL [observable behavior]La notación EARS saca a la luz suposiciones que de otra forma quedarían implícitas. Si Kiro genera un criterio de aceptación que no querías, lo detectas aquí, no en el code review, no en producción. Los requerimientos los revisa y aprueba un humano antes de que pase nada más.
Fase 2: Diseño técnico (design.md)
Esta es la fase donde deberían darse los verdaderos debates de arquitectura — y donde la mayoría de las herramientas de IA ya empezaron a escribir código. Con los requerimientos aprobados, Kiro analiza el codebase existente y genera un documento de diseño: jerarquías de componentes, diagramas de flujo de datos, esquemas de base de datos, contratos de API, interfaces de TypeScript. El diseño refleja la arquitectura real de tu proyecto.
Este es el documento que tu equipo revisa antes de que se escriba una sola línea de código de producción. Un arquitecto puede cuestionar un esquema. Un senior engineer puede levantar una preocupación de escalabilidad. Un engineer que está trabajando en un feature paralelo puede revisar si el nuevo diseño genera conflictos de integración con su trabajo. Todo esto pasa contra un artefacto escrito en un pull request.
Fase 3: Tareas de implementación (tasks.md)
Recién en este punto comienza la implementación. Kiro genera una lista de tareas ordenadas por dependencia y mapeadas de vuelta a los requerimientos; cada tarea incluye los unit tests e integration tests relevantes y, cuando aplica, estados de carga y consideraciones de accesibilidad. Las tareas se pueden ejecutar una a la vez con aprobación humana explícita en cada paso, o de forma autónoma en modo autopilot. Los diffs de código y el historial de ejecución del agente quedan visibles en cada etapa.
Los archivos del spec viven en .kiro/specs/<feature-name>/ dentro del repositorio del proyecto. Están commiteados, versionados y son revisables en pull requests, además de navegables a través del historial de git. Todo el equipo los ve en el momento en que existen.
Esa visibilidad cambia la forma en la que los senior engineers usan su tiempo. En vez de quedar atrapados en la arqueología de averiguar qué se decidió y por qué, revisan un diseño escrito, cuestionan lo que hay que cuestionar y aprueban antes de que arranque el trabajo. Su criterio se aplica donde tiene mayor palanca.
La brecha que las herramientas multi-agente no llenan: el registro de decisiones
Aquí es donde la comparación con los frameworks multi-agente se pone aguda, y donde la elección de herramienta tiene consecuencias de largo plazo que no vas a ver en un demo corto.
Los archivos de spec de Kiro documentan qué debe hacer el sistema y cómo fue diseñado para hacerlo. Eso ya es más de lo que retiene la mayoría de los flujos asistidos por IA. Pero design.md te va a decir que se eligió PostgreSQL y describirá el esquema. No te va a decir que se evaluó DynamoDB y se descartó porque tus patrones de acceso requieren filtrado multi-columna que el modelo de queries de DynamoDB no puede manejar sin desnormalización costosa y rutas de escritura duplicadas. Tampoco te va a decir que se consideró event sourcing y se descartó porque el equipo no tiene experiencia operacional con event stores y el presupuesto de latencia no permitía consistencia eventual.
Ese contexto — qué se evaluó, por qué se rechazó, qué trade-offs se aceptaron — es lo que captura un Architecture Decision Record (ADR). El concepto fue introducido por Michael Nygard en 2011 y desde entonces se ha vuelto un pilar de la arquitectura de software sostenible. La organización ADR en GitHub mantiene una buena visión general del formato y sus variantes si quieres profundizar.
Los ADRs son una práctica bien establecida. El GOV.UK Digital Service publicó 39 de ellos durante su migración a AWS, cubriendo decisiones desde la selección de la plataforma de hosting hasta la consolidación de bases de datos y la arquitectura DNS. Cada uno es un archivo Markdown corto: Status, Context, Decision, Consequences. La colección es el registro de decisiones de toda la migración, versionado junto a la infraestructura que describe.
La razón por la que la mayoría de los equipos no mantiene ADRs es la fricción. Producirlos compite con la presión de entregar, la disciplina se erosiona después de uno o dos sprints, y las decisiones que efectivamente quedan capturadas son las que se toman al inicio en design time, no las igualmente importantes que aparecen a mitad de implementación, cuando una restricción resulta ser distinta a la esperada.
Kiro elimina esa fricción mediante dos mecanismos:
Generación automatizada de ADRs vía Steering
El sistema Steering de Kiro te permite commitear instrucciones persistentes en .kiro/steering/ que aplican a cada interacción de agente en el equipo. Un único archivo de steering hace que la generación de ADRs sea automática:
When generating or updating design.md for any spec, also create or updatea decisions/ subdirectory within the spec folder. For each significantarchitectural choice — technology selection, data model, integrationpattern, security mechanism — create an ADR file following the namingconvention ADR-NNN-short-title.md.
Each ADR must include: Status, Context, Decision, and Consequences(positive, negative, risks). Record options considered but not chosenand the reasons they were rejected.Una vez commiteada, esta instrucción aplica a todo el equipo. Los ADRs se producen sin que nadie tenga que acordarse de producirlos.
# ADR-001: Use PostgreSQL over DynamoDB for review storage
## StatusAccepted
## ContextThe review system requires complex multi-column filtering (rating, date, product).DynamoDB's query model requires denormalized duplicates per access pattern,increasing storage and write complexity by an estimated 3-4x.The team has existing PostgreSQL operational experience and monitoring tooling.DynamoDB was the initial default assumption given existing AWS infrastructure.
## DecisionUse PostgreSQL with a normalized schema. Index the columns used in the fourmost common filter combinations. Accept the horizontal scaling trade-off.
## Consequences- Positive: Query logic is significantly simpler; existing tooling applies- Negative: Horizontal scaling requires more coordination than DynamoDB- Risk: Revisit if read throughput exceeds 20k RPS at peak; document thresholdCaptura por hooks de decisiones a mitad de implementación
Las decisiones que se toman en design time son las fáciles de capturar. Las peligrosas pasan durante la implementación: una librería que resulta tener un edge case que rompe todo, una medición de performance que cambia el patrón de acceso a datos. Estas se resuelven en una conversación o en un cambio rápido de código, y nunca quedan registradas en ningún lado.
Un Hook de Kiro sobre los cambios de design.md resuelve esto. Cuando se modifica el documento de diseño (sea por un engineer o por Kiro durante la ejecución de tareas), el Hook dispara un agente que evalúa si el cambio representa una nueva decisión de arquitectura y, de ser así, redacta un ADR para que el equipo lo revise. El spec y el registro de decisiones se mantienen sincronizados durante toda la implementación, no solo en el punto de diseño inicial.
ADRs en pipelines multi-agente: un enfoque complementario
Los ADRs automatizados no son exclusivos de Kiro; puedes agregar un agente ADR Writer a un pipeline existente de CrewAI o LangGraph. Pero que el ADR resultante llegue al equipo en una forma revisable depende de cómo hayas conectado el output del pipeline a tu flujo de desarrollo. Kiro integra el ADR dentro de un flujo en el que el equipo lo ve, lo revisa y lo cuestiona antes de que se escriba el código.
Para equipos que ya corren pipelines multi-agente, los dos coexisten de forma natural: Kiro maneja el diseño, los specs y la captura de decisiones; tu pipeline existente se encarga de tareas de ejecución acotadas dentro de las restricciones que estableció el spec. El spec se vuelve el contrato entre la fase de diseño (donde el equipo tiene supervisión) y la fase de ejecución (donde los agentes operan con más autonomía).
Dónde se cae el modelo
Sería deshonesto no nombrar los modos de falla, porque no son obvios hasta que llevas algunos sprints adentro.
La calidad del spec está acotada por la calidad del prompt
Los documentos de requerimientos y diseño de Kiro son tan buenos como la descripción inicial que le des. Un prompt vago produce un spec vago, pero ahora es un spec vago con apariencia de rigor, porque viene formateado en notación EARS con criterios de aceptación y todo. Eso es peor que no tener spec, porque el equipo lo revisa, ve la estructura y asume que el contenido es sólido.
La mitigación es cultural, no técnica: trata la revisión del spec como una revisión de diseño real, no como un trámite. Si los requerimientos se sienten genéricos o el diseño no aborda tus restricciones específicas, cuestiona antes de aprobar. El sentido del gate de aprobación es justamente que sea un gate, no una formalidad.
La notación EARS puede generar falsa precisión
EARS es buena para eliminar ambigüedad en requerimientos individuales. Lo que no hace es asegurar completitud: puedes tener veinte requerimientos perfectamente inequívocos que en conjunto se pierden el problema realmente difícil. He visto a Kiro generar requerimientos EARS técnicamente correctos pero operacionalmente inútiles, porque describen el happy path en detalle e ignoran los modos de falla que en realidad van a determinar si el sistema funciona en producción.
La solución: cuando revises requirements.md, no chequees solo si cada requerimiento está bien formado. Chequea si el conjunto de requerimientos cubre los casos de falla, los edge cases y las preocupaciones operacionales (monitoreo, alertas, rollback) que importan para tu sistema. Si no los cubre, agrégalos antes de aprobar.
Los ADRs autogenerados pueden ser superficiales
Un archivo de steering que dice "genera ADRs para decisiones de arquitectura significativas" va a producir ADRs. Que esos ADRs contengan razonamiento útil depende de cuánto contexto tenga Kiro sobre tus restricciones. Un ADR que dice "elegimos PostgreSQL porque soporta queries relacionales" es técnicamente correcto y completamente inútil; cualquier senior engineer ya lo sabe. El valor está en las alternativas rechazadas y las razones específicas por las que se rechazaron.
Afina tu archivo de steering para que sea explícito sobre qué quieres capturar. En vez de "registra decisiones significativas", prueba con "para cada selección de tecnología, documenta al menos dos alternativas evaluadas, la razón técnica u operacional específica por la que cada una se rechazó y las condiciones bajo las cuales la decisión debería revisitarse". Mientras más específica la instrucción, más útil el output.
El spec drift es silencioso por defecto
Kiro no detecta automáticamente cuándo la implementación diverge del diseño. El spec es una foto de la intención en design time. Si un engineer (o un agente en modo autopilot) hace un cambio que contradice el diseño (un motor de base de datos distinto, un endpoint adicional de API, un modelo de datos modificado), los archivos del spec no se actualizan solos.
Esto se puede resolver con Hooks, como se describió arriba, pero no es el comportamiento por defecto. Si vas a adoptar Kiro, configurar Hooks de detección de drift debería ser parte de tu configuración inicial, no algo que agregas después de descubrir el problema.
El gobierno se detiene en el límite del diseño
En diciembre de 2025, un agente de Kiro borró un entorno de producción de AWS en vivo y provocó una caída de 13 horas de AWS Cost Explorer en una región de China (The Register, feb 2026). Amazon atribuyó el incidente a que el rol del engineer tenía permisos más amplios de los previstos. Reportes independientes describieron que Kiro decidió de forma autónoma borrar y recrear el entorno en lugar de aplicar un fix dirigido — una distinción que Amazon impugnó.
Ambos relatos llevan a la misma lección: un equipo puede tener specs revisados, diseños aprobados y ADRs documentados, y aun así sufrir una falla catastrófica porque nadie revisó lo que pasó entre el diseño aprobado y el deploy a producción.
El modelo de gobierno de Kiro cubre la fase de diseño a fondo. Lo que no cubre es el límite de ejecución: el momento en que un agente actúa sobre infraestructura real con permisos reales. El modo autopilot es útil, pero exige la misma disciplina que cualquier pipeline de CI/CD: revisión de deploy, permisos acotados y un humano en el loop antes de que los cambios lleguen a producción. El flujo de specs hace fácil dar por sentado que el gobierno está cubierto. No lo está, a menos que tu equipo extienda esa disciplina más allá del punto donde termina el flujo de Kiro.
Qué cambia para el equipo
El diseño ocurre en público, no en sesiones privadas con agentes
En un pipeline multi-agente, la decisión de diseño se toma dentro del pipeline. Cuando un miembro del equipo la ve, ya está implementada o commiteada en un archivo de output que puede o no llegar a un pull request. Con Kiro, el documento de diseño es el primer output que se commitea al repositorio, antes de que arranque la implementación. El equipo ve y revisa el diseño mientras se crea, no después.
Esto cambia el code review directamente. Revisar código sin un spec implica inferir intención desde la implementación, lo que es lento y se sesga hacia comentarios de estilo en lugar de sustancia. Revisar código contra un spec implica chequear si la implementación satisface los requerimientos declarados y si las decisiones se alinean con el razonamiento documentado. Las revisiones se vuelven más rápidas y más sustantivas.
El trabajo en paralelo expone los conflictos a tiempo
Los pipelines multi-agente típicamente operan sobre un único contexto de tarea. En un equipo donde varios engineers están construyendo en paralelo, cada uno con sus propias sesiones de agente o corriendo sus propios pipelines, no hay mecanismo para detectar que dos features están haciendo suposiciones de arquitectura conflictivas. Los specs de Kiro, commiteados antes de la implementación, ofrecen el punto de referencia compartido que hace visibles esos conflictos en el momento adecuado, antes de que se escriba el código en conflicto.
El conocimiento sobrevive a los cambios de personal
Cuando un engineer deja un equipo que estaba haciendo vibe coding o corriendo pipelines de agentes sin estructura, su contexto se va con él. Lo he visto pasar suficientes veces como para saber cómo termina: tres meses después, alguien está haciendo ingeniería inversa de un servicio que nadie entiende del todo. Los ADRs y specs en el modelo de Kiro están atados al repositorio, no a las personas. El razonamiento detrás de cada decisión significativa queda ahí para quien venga después, sea un engineer que se incorpora en tres meses o un equipo que hereda el sistema en tres años.
El desafío honesto
Aquí va el desafío honesto a los equipos que corren pipelines multi-agente: tu pipeline produce código. ¿Sabes por qué fue diseñado como fue diseñado? ¿Lo sabe tu equipo? ¿Lo van a saber en seis meses? Si la respuesta a alguna de esas preguntas es incierta, estás acumulando deuda de conocimiento que se va a componer.
Esa deuda tiene un arco predecible: la velocidad se degrada, el onboarding se ralentiza y, en algún momento, alguien propone reescribir todo — porque modificar un sistema que nadie entiende se siente más riesgoso que empezar de cero.
Kiro no reemplaza tu tooling multi-agente para la ejecución de tareas acotadas. Provee la capa estructural (specs, ADRs, Hooks, artefactos visibles para el equipo y commiteados antes de la implementación) que convierte el output generado por IA en software del que tu equipo puede ser dueño de verdad.
La pregunta del overhead
El flujo de specs suma tiempo de planificación antes de la implementación. Para un script efímero o una tarea de automatización acotada, ese overhead no se justifica. Algunos equipos descubren que el enfoque estructurado de Kiro sobre-especifica problemas simples, y los gates de aprobación agregan una fricción que se siente innecesaria para cambios de bajo impacto.
El equipo de Martin Fowler examinó las herramientas de desarrollo guiado por specs (Kiro entre ellas) y concluyó que el enfoque opinado y de un único flujo probablemente "no es adecuado para la mayoría de los problemas reales de coding". Tienen un punto. La mayor parte del trabajo de ingeniería del día a día son modificaciones a sistemas existentes, fixes de bugs y cambios incrementales: trabajo donde un ciclo completo de spec genera más fricción que valor. El argumento a favor del desarrollo guiado por specs descansa en el subconjunto de trabajo donde se están tomando decisiones de arquitectura y el costo de equivocarse es alto. Ese subconjunto es más chico de lo que este artículo podría sugerir, pero es donde se cometen los errores más consecuentes.
Kiro ofrece tanto el modo guiado por specs como el modo de vibe coding en el mismo IDE, y los dos coexisten bien: vibe coding para exploración y trabajo desechable, specs para todo lo que vaya a mantenerse. La pregunta más difícil es si los equipos están aplicando ese criterio con precisión. En mi experiencia, la tentación es usar el camino rápido para todo y convencerse de que el feature es más simple de lo que es. La mayor parte de la deuda de conocimiento en los codebases es el residuo acumulado de esa decisión, tomada muchas veces.
Una heurística práctica: usa el modo spec cuando se cumpla alguna de estas condiciones — el feature toca un modelo de datos, introduce una nueva integración externa, cruza un límite de seguridad o lo va a trabajar más de un engineer. Usa vibe coding para todo lo demás. El costo de una decisión de arquitectura equivocada se compone en cada sprint que sigue; el costo de sobre-especificar un script desechable es una hora de tu tiempo.
Para equipos que introducen el modo spec por primera vez, un enfoque por fases reduce la resistencia. Empieza con un feature nuevo que cumpla al menos dos de las condiciones heurísticas de arriba — suficiente complejidad para que el spec valga la pena, pero no tanta como para que la primera experiencia resulte abrumadora. Corre la revisión del spec como una reunión de diseño real: asigna a alguien para que cuestione el documento de requerimientos antes de aprobarlo, no solo para que lo lea. Después de que el primer feature se entregue, haz una retrospectiva corta sobre si el spec atrapó algo que de otro modo habría aparecido más tarde. Ese único dato — "detectamos el problema del esquema en design review en vez de en producción" — convence más a un equipo de ingeniería escéptico que cualquier argumento de proceso.
Conclusión
La generación actual de tooling de desarrollo con IA básicamente resolvió el problema de producir código. Las herramientas pueden convertir requerimientos en lenguaje natural en implementaciones funcionales a una velocidad que hace tres años habría parecido inverosímil.
Lo que la mayoría no resolvió es el problema de equipo: ¿cómo construye software un grupo de engineers en conjunto, con asistencia de IA, de una forma que produzca entendimiento compartido en lugar de output compartido del que nadie es dueño del todo? ¿Cómo respondes "¿por qué se diseñó así?" cuando el diseño ocurrió dentro de una sesión de agente que nadie más vio?
La respuesta de Kiro es estructural: producir los artefactos que vuelven respondibles esas preguntas, antes de que exista el código, como parte estándar del flujo. Los archivos de spec le dan al equipo visibilidad sobre la intención del diseño. Los ADRs, generados a través de un archivo de steering que tú configuras y mantenidos vigentes mediante Hooks, le dan al equipo visibilidad sobre el razonamiento de las decisiones. Ambos viven en el repositorio y viajan a través de pull requests como cualquier otro artefacto de código.
Para equipos que ya usan frameworks multi-agente para tareas de ejecución, Kiro no es un reemplazo. Es la capa que esas herramientas no proveen: un flujo revisable y visible para el equipo que captura decisiones y convierte el código generado por IA en software que un equipo de ingeniería puede mantener.
El problema de ejecución está, en gran medida, resuelto. El de equipo no. Ese es el problema que vale la pena trabajar — y es el que el resto de la industria del tooling todavía no se anima a apostar.