Deja el Vibe Coding: SDD con Kiro para construir software real

En la evolución del desarrollo asistido por IA, nos encontramos en una bifurcación crítica. Martin Fowler define el "vibe coding" como un estilo donde el programador confía ciegamente en la intuición: envía un prompt, prueba el resultado y solicita cambios sin revisar realmente el código generado. Si bien este enfoque es una herramienta poderosa para el prototipado rápido y la exploración, carece de la rigurosidad necesaria para construir sistemas de producción mantenibles.

Kiro surge como el antídoto técnico a la fragilidad del "vibe coding". No es un simple generador de código; es un arnés de planificación y ejecución diseñado para transformar la intención en artefactos trazables. Su objetivo es evitar la deuda técnica latente y las alucinaciones mediante un flujo de "documentación primero", donde cada línea de código es el resultado de un contrato previo de requerimientos y diseño.

Juicio Ejecutivo: Cuándo aplicar SDD y cuándo usar "Quick Plan"

Como arquitectos, debemos aplicar el proceso adecuado a la magnitud del problema. El Spec-Driven Development (SDD) es una inversión en calidad que no debe aplicarse de forma indiscriminada a cambios triviales o correcciones de estilo.

Dimensión	Vibe Coding	SDD con Kiro
Estilo de interacción	Conversacional, rápido e informal.	Flujo estructurado por fases (Reqs, Design, Tasks).
Enfoque de revisión	Foco en salida visual; se suele omitir el código.	Revisión profunda de lógica, arquitectura y contratos.
Fuente de verdad	El último mensaje del chat y el código actual.	Archivos en .kiro/specs y reglas de steering.
Mejor ajuste (Best fit)	Experimentos, prototipos y herramientas desechables.	Características complejas, refactorizaciones y bugs críticos.

Para tareas de menor envergadura donde el flujo completo de SDD podría percibirse como excesivo (verbosidad innecesaria), Kiro permite el uso de Quick Plan. Este modo agiliza la generación de especificaciones sin sacrificar la estructura básica, permitiendo mantener la agilidad en cambios locales.

El Modelo Operativo: El Flujo de los 6 Pasos en Kiro

El valor real de la ingeniería reside en las fases de planificación (Pasos 1 al 4). La implementación es, en última instancia, una consecuencia de un plan bien ejecutado.

1. Steering (Contexto base): Definición de reglas persistentes en .kiro/steering/. Aquí se establecen los estándares globales que evitan que la IA tome decisiones arquitectónicas erróneas en cada sesión.
2. Requirements Review: Kiro transforma el prompt inicial en requirements.md. En esta fase se formalizan historias de usuario y criterios de aceptación utilizando el estándar EARS (Easy Approach to Requirements Syntax). Trate este archivo como un contrato: si el requerimiento es ambiguo, el código lo será también.
3. Design Review: Se genera design.md con la arquitectura, modelos de datos e interfaces. Es imperativo que el ingeniero intervenga aquí con una postura firme. La IA tiende a generar diseños monolíticos por defecto; el ingeniero debe forzar la modularidad (por ejemplo, separando la lógica de negocio de la persistencia) para evitar el "context rot" futuro.
4. Tasks: El diseño se desglosa en tasks.md. Cada tarea posee dependencias rastreables y apunta directamente a los números de requerimiento definidos en el paso 2, garantizando una trazabilidad total.
5. Code (Implementación): Ejecución de las tareas. Kiro optimiza la productividad ejecutando tareas independientes de forma concurrente en "waves", pero siempre anclado al contexto del #spec.
6. Property-based checks (Verificación): A diferencia de los unit tests basados en ejemplos manuales, Kiro extrae propiedades de los requerimientos EARS y genera cientos de casos aleatorios. La gran ventaja para el arquitecto es la Trazabilidad: en la interfaz de Kiro, se puede pasar el cursor sobre una propiedad para ver exactamente qué requerimiento y qué tarea la originaron.

Configuración Crítica: Steering y la "Fuente de Verdad"

Para mitigar alucinaciones, es vital alimentar a Kiro con límites claros mediante archivos de steering. Esto reduce el ruido y enfoca la capacidad de razonamiento del modelo.

Ejemplo: Estructura de Steering para una API REST

# .kiro/steering/tech.md
- Stack: Node.js 22, TypeScript, Express.
- Persistencia: Repository Pattern (in-memory para v1).
- Prohibido: El uso de ORMs pesados; preferir funciones puras y abstracciones claras.

# .kiro/steering/structure.md
- src/routes: Solo registro de endpoints.
- src/controllers: Orquestación de peticiones (handlers delgados).
- src/services: Núcleo de lógica de negocio.
- src/repositories: Adaptadores de persistencia.

Para optimizar el rendimiento y evitar la degradación del contexto, utilice los modos de inclusión:

• always: Estándares universales.
• fileMatch: Se activa solo en archivos específicos (ej. reglas de seguridad solo en src/routes/).
• auto: Permite que Kiro decida incluir el contexto basándose en la descripción del prompt, manteniendo la ventana de contexto limpia.

Secretos Operacionales: Gestión de Costos y Disciplina

El uso de agentes requiere una mentalidad de eficiencia de recursos. No se trata solo de ahorrar dinero, sino de maximizar la calidad del razonamiento.

1. Elección Estratégica de Modelos: La arquitectura no es lugar para ahorrar. Use Opus (2.2x) para las fases de requerimientos y diseño complejo. Para la implementación rutinaria y la codificación de tareas, Sonnet 4.6 (1.3x) o los modelos Auto ofrecen el equilibrio óptimo.
2. Powers vs. MCP Global: Activar múltiples servidores MCP de forma global puede consumir más de 50,000 tokens antes de siquiera escribir el primer prompt. Use "Powers" para cargar herramientas dinámicamente solo cuando la tarea lo requiera, evitando el "context bloat".
3. Disciplina con el Plan Agent: En la CLI, el comando /plan activa un agente de solo lectura. Su propósito no es simplemente ahorrar créditos, sino forzar una disciplina arquitectónica: obliga al ingeniero a validar la investigación y el plan de tareas antes de permitir que el sistema realice cambios mutantes en el árbol de archivos.

Automatización con Hooks: El guardián de la calidad

Los Hooks permiten que el rigor técnico no dependa de la memoria del programador. Son disparadores automáticos (ej. al guardar un archivo) que ejecutan acciones específicas. Para mantener la agilidad, los hooks deben ser quirúrgicos y conscientes del rendimiento.

Ejemplo de prompt para un File-save hook de alta eficiencia:

"Al detectar cambios en un archivo fuente: 1. Identifica las funciones modificadas. 2. Verifica si existen tests correspondientes. 3. Si falta cobertura, genera tests solo para el cambio detectado. 4. Ejecuta únicamente los tests afectados y reporta fallos sin alterar archivos no relacionados."

Conclusión

Adoptar Kiro y el Spec-Driven Development significa elevar el estándar de la programación asistida: pasamos de un historial de chat efímero a un sistema de ingeniería donde los requerimientos son contratos y el diseño funciona como un registro de decisiones arquitectónicas (ADR) vivo.

Llamado a la acción: La transición al SDD no requiere una migración masiva. Comience mañana con una sola característica real: cree un Feature Spec (Requirements-First), itere sobre el diseño modular y experimente la seguridad que brinda la trazabilidad total. Deje de "vibrar" con el código y comience a construir con evidencia.

¿Ha sido el "vibe coding" suficiente para sus proyectos actuales, o ha sentido que la falta de estructura está creando una deuda técnica que ya no puede rastrear?