La mayoría de las herramientas de codificación con IA funcionan igual, describís lo que querés, el modelo escribe código y repetís el ciclo. Kiro está construido sobre una premisa diferente. Cuando describís una feature, no empieza a codear sino que primero escribe tres documentos: requirements.md con historias de usuario y criterios de aceptación, design.md con la arquitectura y contratos de interfaces TypeScript, y tasks.md con tareas ejecutables y dependencias entre ellas, y recién después de que revisás y aprobás ese plan se genera código.

En un hackathon con una ventana de dos días (por situaciones personales), ese proceso inicial suena a overhead que no podés pagar. Terminamos descubriendo que era lo que nos mantuvo en pie.

El proyecto

Entiscore es un agente que audita la presencia digital de un sitio web, evaluando schema markup, consistencia de identidad, señales de autoridad y accesibilidad técnica. Devuelve un reporte con puntuación dividida por eje y un plan de acción generado por IA con snippets de código listos para implementar. Construido para el hackathon Kiro powered by AWS organizado por Código Facilito, con dos días de desarrollo real tras un comienzo accidentado.

El stack fue Next.js, TypeScript, Supabase y Claude API de Anthropic. Sin infraestructura de AWS porque no teníamos créditos disponibles, algo que vale la pena ser honesto respecto a un hackathon que promocionaba servicios de AWS. Kiro fue nuestro IDE durante toda la construcción.

Qué produjo la fase de specs

Antes de tocar el editor escribimos tres documentos y en Kiro esto sucede a través de un flujo estructurado donde describís la feature y el IDE genera la spec para que la revisés y editás. Lo que salió no fue boilerplate.

requirements.md tenía historias de usuario, criterios de aceptación y una columna de prioridad con etiquetas P0 y P1, donde P0 significaba que la feature tenía que salir para que el producto tuviera sentido y P1 significaba que era valiosa pero prescindible si el tiempo apretaba. Teníamos cinco ejes de análisis planificados: datos estructurados, consistencia de identidad, señales de autoridad, accesibilidad técnica, y un quinto que no sobrevivió el primer día. La etiqueta P1 en consistencia de identidad y señales de autoridad nos dio una razón documentada para despriorizar esos ejes sin sentir que estábamos abandonando el alcance. Cuando el reloj corría, no debatíamos, simplemente mirábamos la columna.

design.md tenía la arquitectura con contratos de interfaces TypeScript para cada límite importante del sistema. Eso importó más de lo que esperábamos. Cuando dos personas escriben partes distintas del mismo sistema en paralelo, las definiciones de interfaces compartidas previenen una categoría de bugs de integración que son particularmente costosos de debuguear bajo presión. Nunca tuvimos un desajuste entre lo que el orquestador esperaba y lo que devolvía un analizador porque el contrato fue escrito antes de implementar ninguno de los dos.

tasks.md tenía un grafo de dependencias con un orden explícito donde la tarea B depende de la tarea A y la tarea D puede empezar en paralelo con la tarea C, y esa estructura se convirtió en una división natural del trabajo entre dos developers sin necesidad de una reunión de planning.

Steering y hooks, la capa invisible

Kiro tiene dos features que no reciben tanta cobertura como las specs pero resultaron ser más consistentemente útiles durante la construcción.

Los documentos de Steering son instrucciones que Kiro aplica a todo lo que genera en todo el proyecto sin que tengas que repetirlas en cada prompt. Definimos coding-standards.md con reglas no negociables que incluían cero comentarios en el código, TypeScript estricto sin any, una responsabilidad por función con límite de treinta líneas y separación estricta entre capas de servidor y cliente. Kiro respetó esas reglas de forma consistente en cientos de archivos generados durante dos días. Nunca tuvimos que decir "acordate de no usar any" o "mantené la función pequeña". Ya estaba en el contexto.

Las convenciones de commits también estaban en Steering, con prefijos tipados en español (feat, fix, chore, refactor, docs) y un formato específico. El historial de git de ese fin de semana es legible.

Los Hooks son acciones que corren automáticamente cuando algo pasa en el proyecto. Configuramos un hook de type check que corría npx tsc --noEmit en cada guardado. Los errores de TypeScript aparecían de inmediato en lugar de acumularse hasta el build. En una codebase que crecía rápido con dos personas escribiendo en paralelo, ese feedback loop atajó problemas antes de que se complejizaran.

Dónde el spec-driven development nos salvó

El ejemplo más concreto llegó el segundo día. Estábamos implementando el motor de scoring, que toma la salida de cuatro analizadores en paralelo y produce un promedio ponderado. El documento de diseño tenía la distribución de pesos, con 30% para datos estructurados, 20% para consistencia de identidad, 20% para señales de autoridad y 30% para accesibilidad técnica, y también tenía una nota sobre redistribución dinámica de pesos donde si un analizador devolvía estado failed o partial, su peso debía redistribuirse proporcionalmente entre los que sí habían tenido éxito.

Ese comportamiento estaba escrito en la fase de diseño antes de que existiera una sola línea de código, de modo que cuando lo implementamos el comportamiento ya estaba definido y no tuvimos que inventar el manejo del edge case durante la implementación, sino simplemente leer la spec.

Sin la spec, esa lógica de redistribución hubiera sido una decisión tomada bajo presión. Con ella, fue ejecución.

Qué haríamos diferente

La fase de specs tiene un costo que se hace visible cuando estás operando con un deadline duro. Los diez a veinte minutos para generar y revisar documentos al inicio de cada feature importante se acumularon. Para features donde teníamos confianza, a veces hojeábamos la spec en lugar de leerla, lo cual anulaba parte del propósito.

El documento de tasks fue el más débil de los tres en la práctica. Kiro lo genera basándose en el diseño y las dependencias que infiere son generalmente correctas, pero la granularidad de las tareas a veces es demasiado gruesa para ser directamente accionable. Terminamos usándolo más como checklist que como grafo de dependencias.

Los defaults de Kiro tienden hacia servicios de AWS, lo cual tiene sentido dado lo que es. Cuando describís una capa de persistencia, tiende a sugerir DynamoDB. Cuando describís un destino de deployment, sugiere Lambda o Amplify. Sobreescribirlo está bien pero vale la pena saberlo de antemano, especialmente si tu stack ya apunta hacia otro lado.

La lección de proceso que se transfiere

Algo que notamos al final del fin de semana fue que dejamos de aceptar los reportes de "listo" de Kiro al pie de la letra, porque el botón de compartir que desapareció después de un refactor de animaciones, el componente de chat que se fue después de otro y el favicon que faltaba en una comparación de deployment no fueron detectados por Kiro reportando completado sino por nosotros abriendo la URL desplegada y mirando.

Trabajar con un agente de IA que escribe, ejecuta y reporta sobre su propio output genera una dinámica específica donde es fácil confundir ejecución fluida con ejecución correcta, y esas dos cosas no son lo mismo. Kiro es muy bueno en la primera mientras que verificar la segunda sigue siendo responsabilidad del developer, y eso no es una crítica a Kiro específicamente sino una propiedad de cualquier herramienta agéntica que puede completar tareas sin un humano en el loop en cada paso.

Entiscore está disponible en entiscore.vercel.app. Construido con Next.js, TypeScript, Supabase y Claude API.