Del caso de uso a producción

Cuando estaba en la universidad, lo primero que hacía cuando tenía una idea nueva para un proyecto era abrir VS Code y empezaba a escribir código. ¿Te suena familiar?

El problema es que mis proyectos crecían sin dirección, cambiaba cosas constantemente, nunca sabía cuándo estaba "listo", hacía código que ni yo entendía dos semanas después y terminaba como un proyecto más que no volvía a retomar. Y desde mi punto de vista no era un problema de habilidad técnica puesto que sabía hacer las cosas, tiempo después entendí que era un problema de proceso.

Si vas comenzando tu carrera en tecnología y te pasa algo parecido, está bien, todos empezamos así. Pero hay una manera que puede funcionarte mejor.

En este artículo vamos a usar Kiro para llevar una idea desde casos de uso hasta código funcional. Si es tu primera vez con Kiro y prefieres empezar con algo más introductorio, Ana Cunha escribió una guía de primeros pasos que te puede servir como punto de partida.

El verdadero problema no es el código

En mi experiencia, muchos de mis proyectos no fallaron por código malo. Fallaron porque nunca definí bien el problema que quería resolver.

Imagina que quieres construir una aplicación que compare tu CV con una oferta de trabajo usando IA y te diga qué te falta. ¿Por dónde empiezas? ¿El frontend? ¿La base de datos? ¿La integración con inteligencia artificial?

En algún punto de mi carrera fui freelancer y en esa experiencia fue cuando le di valor a mis clases de ingeniería de software. Aprendí algo que cambió mi forma de construir: el código no es el punto de partida, es la consecuencia. Antes de escribir una sola línea, necesitas entender qué estás construyendo y para quién.

Casos de uso: Tu plano antes de construir

Un caso de uso es simplemente una descripción de cómo un usuario interactúa con tu sistema. Piénsalo como los planos de un arquitecto, no construyes una casa sin ellos, y no deberías empezar a codear sin entender qué estás construyendo.

Si quieres profundizar en la definición formal, hay documentación excelente al respecto. Pero para lo práctico, lo que necesitas son tres cosas:

• Historias de usuario: Qué quiere hacer el usuario y por qué
• Criterios de aceptación: Cómo sabes que funciona correctamente
• Entidades y relaciones: Qué "cosas" existen en tu sistema y cómo se conectan

Volvamos al ejemplo del comparador de CVs. Una idea vaga como "quiero una app que analice mi CV" se convierte en algo concreto cuando la escribes como historia de usuario:

Como persona que busca trabajo, quiero subir mi CV en formato PDF o texto, para que el sistema pueda analizarlo y compararlo con una oferta de trabajo.

De repente, ya sabes varias cosas: necesitas soportar PDF y texto, necesitas una descripción de trabajo como segunda entrada, y el resultado es una comparación. Eso es mucho más útil que "hacer una app de CVs".

Y cuando agregas criterios de aceptación, las cosas se ponen aún más claras:

• CUANDO un usuario sube un PDF, EL SISTEMA DEBE extraer el contenido correctamente
• CUANDO un usuario intenta subir un formato no soportado, EL SISTEMA DEBE mostrar un error con los formatos válidos

Ahora no solo sabes qué construir, sino cuándo está "listo". Eso es algo que como estudiante nunca tenía claro.

Spec Driven Development: El puente entre la idea y el código

Definir casos de uso es el primer paso. Pero, ¿cómo pasas de esos requisitos a código real sin perderte en el camino?

Aquí es donde entra el concepto de Spec Driven Development, un enfoque donde primero diseñas las especificaciones de lo que vas a construir y después implementas. Esta metodología se divide en cuatro fases:

1. Capturar la intención: Defines qué quieres construir en lenguaje natural. Aquí es donde entran las historias de usuario y los criterios de aceptación que vimos antes. El objetivo es que cualquier persona (técnica o no) entienda qué se va a construir.

2. Traducir la intención en un blueprint del sistema: Tomas esos requisitos y los conviertes en un diseño técnico: qué componentes necesitas, cómo se comunican entre sí, qué tecnologías vas a usar. Es el plano de tu arquitectura.

3. Generar unidades de trabajo: Divides ese diseño en tareas concretas e incrementales. Cada tarea debe ser pequeña, clara y debe resultar en algo funcional que puedas probar.

4. Implementar y validar: Ahora sí, escribes código. Pero cada tarea que implementas se valida contra los criterios de aceptación que definiste en la primera fase. Así sabes que lo que construyes es lo que necesitas.

💡 Nota: Este no es un proceso que haces una sola vez. Cada que agregas una nueva feature a tu proyecto, vuelves a recorrer las cuatro fases. Defines la intención de esa feature, actualizas el blueprint, generas las unidades de trabajo y las implementas. Es un ciclo que se repite, y cada iteración se vuelve más natural.

Lo interesante de este enfoque es que no depende de ninguna herramienta específica, puedes hacerlo con un documento de texto, una pizarra, o una servilleta. Lo importante es el proceso de pensar antes de codear.

Dicho esto, herramientas como Kiro implementan esta metodología y te ayudan a recorrer las fases de manera estructurada. Kiro sigue un flujo de tres fases (1. requirements, 2. design y 3. tasks) que se mapea directamente con lo que acabamos de ver:

Fase de SDD	Qué pasa	En Kiro
Capturar la intención	Describes tu idea en lenguaje natural	Le dices a Kiro qué quieres construir
Blueprint del sistema	Requisitos + Diseño + Tareas	Kiro genera requirements.md, design.md y tasks.md
Unidades de trabajo	Ejecutar las tareas	Corres cada task desde el IDE
Implementar y validar	Código + validación	Kiro implementa y tú validas contra los criterios de aceptación

Pero la metodología funciona con o sin herramientas. Kiro simplemente hace el proceso más rápido.

💡 Tip importante: Las herramientas de IA no reemplazan tu pensamiento crítico. Lo amplifican. No se trata de documentar por documentar, se trata de pensar antes de codear. La documentación es el resultado de ese pensamiento.

SDD en acción: Construyendo el comparador de CVs

Para que esto no se quede en teoría, veamos cómo se ve este proceso aplicado al proyecto del comparador de CVs.

Fase 1: Capturar la intención

Aquí es donde todo lo que vimos antes cobra sentido. En lugar de abrir Kiro con un prompt vago como "hazme una app de CVs", primero escribí un archivo con las historias de usuario y criterios de aceptación que ya había definido el contexto del proyecto, quién es el usuario, qué necesita hacer y cómo sabemos que funciona. Algo así:

## Contexto del Proyecto
**Usuario principal:** Personas que buscan trabajo activamente
**Objetivo:** Mejorar la calidad del CV para fortalecer el perfil profesional

### Historia 1: Subir CV para análisis
**Como** persona que busca trabajo
**Quiero** subir mi CV en formato PDF o texto
**Para** que el sistema pueda analizarlo y compararlo con ofertas de trabajo

**Criterios de aceptación:**
CUANDO un usuario sube un archivo CV en formato PDF
EL SISTEMA DEBE extraer el contenido del documento correctamente
...

Ese archivo fue el punto de partida para Kiro. El trabajo previo de pensar el problema es lo que le da a la herramienta el contexto necesario para generar algo útil.

Fase 2: Blueprint del sistema

A partir de los casos de uso, Kiro generó tres documentos que juntos forman el blueprint completo del proyecto:

requirements.md: Kiro tomó las historias de usuario y las expandió en un documento de requisitos formal. Agregó un glosario con los términos del dominio (como "Brecha_Crítica" o "Generador_Recomendaciones"), detalló los criterios de aceptación de cada historia, e incluso identificó requisitos técnicos que no estaban explícitos en las historias originales, como la extracción de texto de PDFs y el análisis estructurado de descripciones de trabajo.

design.md: Con los requisitos claros, Kiro generó el diseño técnico: un diagrama de arquitectura con todos los componentes, los flujos de datos (cómo viaja un PDF desde el navegador hasta el análisis con IA), las interfaces entre componentes (qué recibe y qué retorna cada Lambda), y una estrategia de manejo de errores. Aquí es donde la idea se convirtió en un plano técnico concreto.

tasks.md: Finalmente, Kiro descompuso el diseño en tareas incrementales. Cada tarea referencia los requisitos que implementa, tiene subtareas claras, y construye sobre la anterior. Por ejemplo: primero la infraestructura (SAM template), después la Lambda de presigned URLs, luego la extracción de PDF, y así sucesivamente hasta tener la aplicación completa.

Un detalle interesante: Kiro inicialmente me sugirió usar Python para las funciones Lambda. Pero a mí personalmente me gusta mucho Rust, así que le pedí que cambiara el diseño para usar Rust en el backend. Y lo hizo sin problema, ajustó la arquitectura, las dependencias y las tareas. Esto es importante: la herramienta propone, pero tú decides. Si hay algo que quieres hacer diferente, experimentar con un lenguaje que te interesa o usar una tecnología que quieres aprender, puedes hacerlo. El blueprint se adapta a tus decisiones, no al revés.

El resultado fue una arquitectura clara:

Un frontend en Astro (un framework web moderno), funciones serverless en Rust desplegadas con AWS Lambda (funciones que se ejecutan bajo demanda sin manejar servidores), análisis de CVs con Amazon Bedrock (acceso a modelos de IA generativa) y almacenamiento temporal en Amazon S3 (almacenamiento de objetos en la nube). Todo definido antes de escribir la primera línea de código.

Fase 3: Ejecutar unidades de trabajo

Con el blueprint listo, pasé a ejecutar las tareas directamente desde el IDE de Kiro. En el video ejecuto la primera tarea. Kiro creó el monorepo, inicializó el frontend en Astro, configuró el workspace de Rust y generó el template.yaml base para SAM.

A partir de ahí, el plan de implementación tenía 21 tareas que iban construyendo la aplicación de forma incremental: primero la infraestructura en AWS (S3, Cognito, API Gateway, Lambdas), después las funciones backend una por una (presigned URLs, extracción de PDF, integración con Bedrock, parseo de respuestas), luego todo el frontend (autenticación, carga de CV, página de resultados), y al final el despliegue. Cada tarea referenciaba los requisitos que implementaba, así que en todo momento sabías qué estabas construyendo y por qué.

El resultado: una aplicación funcional donde subes tu CV, pegas una oferta de trabajo, y el sistema te dice qué tan compatible eres y qué te falta. Todo construido a partir de seis historias de usuario escritas en un archivo de texto.

El cambio que haría si pudiera volver

Si pudiera regresar a cuando comencé a construir mis primeras aplicaciones, lo primero que cambiaría es esto: dejaría de abrir el editor como primer paso.

No porque codear esté mal, obvio; al final es lo que nos apasiona. Sino porque dedicar aunque sea 30 minutos a pensar en qué vas a construir antes de cómo, te ahorra horas de frustración después.

Si este enfoque te resulta útil y quieres platicar sobre cómo aplicarlo en tu proyecto, encuéntrame en LinkedIn.

---

Recursos

• Spec Driven Development - Kiro
• Cómo comenzar con Kiro: Tu guía de primeros pasos - Si quieres un tutorial más paso a paso para empezar con Kiro, Ana Cunha escribió esta guía
• Kiro
• AWS Free Tier - Empieza sin gastar nada