1. 🧨 El Problema: La Trampa del VibeCoding (10 min)

• 🤔 ¿Qué es el VibeCoding?
  Programar por "sensaciones", aceptando código que "parece que funciona" sin entender las implicaciones arquitectónicas.

• ⚠️ Consecuencias:
  Deuda técnica acelerada, pérdida del control del flujo de datos y el temido "código espagueti generado por IA".

• 🏗️ El papel del Arquitecto:
  Por qué ahora es más importante que nunca saber qué construir antes de preguntar cómo.

---

2. 🏛️ El Pilar: Design Specs Development (15 min)

• 📄 Documentación viva:
  El prompt no es la instrucción, el documento de diseño (Markdown/System Instructions) lo es.

• 📐 Definición de Contratos:
  Uso de esquemas (JSON Schema, OpenAPI, Interfaces TypeScript) como fuente de verdad antes de generar una sola línea de lógica.

• 🧠 Context Window Optimization:
  Cómo estructurar las especificaciones para que la IA no "alucine" por falta de contexto.

---

3. 🛠️ La Técnica: Rigorous Prompting (15 min)

• 🧩 Chain-of-Thought (CoT) aplicado a la arquitectura:
  Forzar a la IA a razonar el patrón de diseño (Hexagonal, Clean, etc.) antes de escribir el código.

• 🪜 Iteración por capas:
  No pedir "toda la app", sino pedir la capa de dominio, luego la de infraestructura, validando contra la Spec en cada paso.

• ✅ Test-Driven Development (TDD) + IA:
  Escribir los tests basados en la Spec y que la IA los use como "raíles" para su generación.

---

4. 🎬 Demo Práctica (10 min)

Mostrar un flujo rápido:

• 📝 Tengo una Design Spec en Markdown.
• 🧱 Genero el Contrato/Interfaz.
• 🚫 Uso un System Prompt rígido que prohíbe el VibeCoding.
• 🎯 Resultado: Código predecible, testeable y alineado con la arquitectura.

---

5. 🎤 Conclusión y Q&A (5 min)

💡 La IA es un multiplicador, pero si multiplicas por cero (falta de diseño), el resultado sigue siendo cero.