Del caso de uso a producción

Source: Dev.to

Introducció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 era 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. Desde mi punto de vista no era un problema de habilidad técnica, pues sabía hacer las cosas; tiempo después entendí que era un problema de proceso.

Si estás 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 algo más introductivo, Ana Cunha escribió una guía de primeros pasos que te puede servir como punto de partida.

Por qué fallan los proyectos

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, 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.

Definir casos de uso

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.

Qué necesitas (versión práctica)

1. Historias de usuario – Qué quiere hacer el usuario y por qué.
2. Criterios de aceptación – Cómo sabes que funciona correctamente.
3. Entidades y relaciones – Qué “cosas” existen en tu sistema y cómo se conectan.

Ejemplo: Comparador de CVs

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.
• El resultado es una comparación.

Criterios de aceptación

Con esto ya sabes qué construir y cuándo está “listo”.

De requisitos a código: Spec‑Driven Development (SDD)

Spec‑Driven Development es un enfoque donde primero diseñas las especificaciones y después implementas. Se divide en cuatro fases:

1. Capturar la intención

   • Define qué quieres construir en lenguaje natural (historias de usuario y criterios de aceptación).
   • 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

   • Convierte esos requisitos en un diseño técnico: componentes, comunicación, tecnologías.
   • Es el plano de tu arquitectura.

3. Generar unidades de trabajo

   • Divide el diseño en tareas concretas e incrementales.
   • Cada tarea debe ser pequeña, clara y producir algo funcional que puedas probar.

4. Implementar y validar

   • Escribe código.
   • Cada tarea se valida contra los criterios de aceptación definidos en la fase 1.

💡 Nota: Este proceso se repite cada vez que agregas una nueva feature.

El enfoque no depende de ninguna herramienta específica; puedes usar un documento de texto, una pizarra o incluso una servilleta. Lo importante es pensar antes de codear.

Kiro y el flujo de SDD

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, 3️⃣ tasks) que se mapea directamente con lo que acabamos de ver.

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

Aplicación práctica: proyecto del comparador de CVs

A continuación, veamos cómo se ve este proceso aplicado al proyecto del comparador de CVs.

Historia de usuario y criterios de aceptación

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 los criterios de aceptación que ya había definido:

• Contexto del proyecto
• Quién es el usuario
• Qué necesita hacer
• Cómo sabemos que funciona

Ejemplo de archivo:

# Ejemplo de archivo de historias de usuario
---
proyecto: "Generador de CV"
usuario: "Candidato a empleo"
historias:
  - id: HU-01
    descripción: "Como candidato, quiero crear mi CV a partir de un formulario sencillo para poder exportarlo en PDF."
    criterios_de_aceptación:
      - "El formulario debe incluir campos obligatorios: nombre, email, experiencia y educación."
      - "Al guardar, el CV se genera en formato PDF con el diseño seleccionado."
      - "El PDF debe descargarse automáticamente y también estar disponible en la cuenta del usuario."
  - id: HU-02
    descripción: "Como candidato, quiero previsualizar mi CV antes de descargarlo para asegurarme de que la información está correcta."
    criterios_de_aceptación:
      - "Debe mostrarse una vista previa en tiempo real mientras el usuario completa el formulario."
      - "La vista previa debe reflejar exactamente el diseño final del PDF."

Nota: Este es solo un ejemplo; adapta las historias y los criterios a las necesidades específicas de tu proyecto.

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.
• (Agregar aquí el resto de los criterios de aceptación…)

Fase 2 – Blueprint del sistema

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

Nota: Kiro inicialmente propuso Python para las Lambdas, pero el equipo prefirió Rust. Kiro ajustó automáticamente la arquitectura, dependencias y tareas para usar Rust en el backend.

Arquitectura resultante

• Frontend: Astro (framework web moderno).
• Backend: Funciones serverless en Rust, desplegadas con AWS Lambda.
• IA: Análisis de CVs con Amazon Bedrock (modelos generativos).
• Almacenamiento temporal: Amazon S3.

Todo quedó definido antes de escribir la primera línea de código.

Implementación paso a paso

1. Creación del monorepo – Kiro generó la estructura del proyecto.
2. Inicialización del frontend – Astro configurado.
3. Workspace de Rust – Configuración del entorno y dependencias.
4. Plantilla SAM (template.yaml) – Base para la infraestructura serverless.

Plan de tareas (21 en total)

Cada tarea referencia los requisitos que implementa, lo que permite saber qué se está construyendo y por qué en todo momento.

Resultado final

Una aplicación funcional donde el usuario:

1. Sube su CV (PDF o texto).
2. Pega una oferta de trabajo.
3. Obtiene un análisis de compatibilidad y una lista de áreas de mejora.

Todo construido a partir de seis historias de usuario escritas en un archivo de texto.

Reflexión

Dedicar al menos 30 minutos a pensar qué vas a construir antes de decidir cómo hacerlo ahorra horas de frustración después.

Si este enfoque te resulta útil y deseas conversar sobre su aplicación en tu proyecto, encuéntrame en LinkedIn.

Recursos adicionales

• Spec‑Driven Development – Kiro
• Guía de primeros pasos con Kiro – Cómo comenzar con Kiro: tu tutorial paso a paso (Ana Cunha)
• AWS Free Tier – Empieza sin gastar nada.