Prompting Riguroso: Por qué tu IA necesita un Arquitecto, no un entusiasta

Contenido: 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.