Xauen Devs • 22 de mayo de 2026

Prompting Riguroso

Por qué tu IA necesita un Arquitecto,
no un entusiasta

Usa las flechas ◀ ▶ o Espacio para navegar

Presentación

¿Quién es Antonio Tirado Peña?

Antonio Tirado Peña

Antonio Tirado Peña

@xtoxico

ESTRATEGIA & PRODUCTO
  • Director de IT y Estrategia @ Instituto de Innovación, Ciencia y Empresa
  • Product Strategist de NormaPro (Cumplimiento Normativo Digitalizado)
  • Ing. Técnica Informática de Gestión (UJA) + Postgrado en Digital Product Management (IEBS)
RIGOR TÉCNICO & CERTIFICACIONES
  • Azure Solutions Architect Expert, Linux (LPIC2), Oracle DB, Cisco (CCNA), Python (IBM)
  • Maker de corazón | Perfil Hands-on | Cultura DIY | Arch Linux User
STACK & R&D
Day job: Node.js, TypeScript, Angular
Night shift / R&D: Rust, Python

Entusiasta y adoptante de la IA desde sus inicios, aplicando control arquitectónico estricto.

Xauen Devs • 22 de mayo de 2026 Ponente
Capítulo 01 • Sección 01

¿Qué es el VibeCoding?

Sección 01 • Diapositiva 1

Del Meme al Hecho

El término "VibeCoding" nació en las redes como un meme divertido, pero hoy representa una descripción dolorosamente exacta del desarrollo de software actual.

Definición de VibeCoding:

El acto de programar guiado por "sensaciones" o "vibras". Escribir una idea vaga en lenguaje natural en Cursor o Copilot, y aceptar ciegamente el código resultante porque "parece que compila" en local.

"Vibras sobre Rigor"

Aceptación ciega de bloques de código por la simple ausencia de alertas visuales.

Xauen Devs • 22 de mayo de 2026 La Trampa del VibeCoding
Sección 01 • Diapositiva 2

El Sesgo de la Inmediatez

3 seg

50 líneas de código

Gratificación instantánea automatizada

La Adicción a la Velocidad de Sintaxis

Ver cómo la IA escupe decenas de líneas de código en segundos genera una descarga de dopamina cognitiva que nos hace sentir increíblemente productivos.

"Se confunde severamente el acto de escribir sintaxis de forma veloz con la verdadera labor ingenieril de resolver problemas complejos de negocio."

Xauen Devs • 22 de mayo de 2026 La Trampa del VibeCoding
Sección 01 • Diapositiva 3

Erosión del Análisis Crítico

Flujo Tradicional de Desarrollo

Rol Activo Pensante

Inversión previa de tiempo para conceptualizar la modularidad, acoplamiento, flujos y manejo de excepciones antes de tocar una sola tecla del editor.

Análisis riguroso manual
Flujo VibeCoding de Desarrollo

Espectador Pasivo

Delegación de toda la arquitectura en el modelo. El desarrollador se limita a validar visualmente que el "happy path" compile superficialmente en su entorno local.

Delegación cognitiva absoluta
Xauen Devs • 22 de mayo de 2026 La Trampa del VibeCoding
Capítulo 01 • Sección 02

El Coste de las Sensaciones

Sección 02 • Diapositiva 1

El Límite del Prototipo

El VibeCoding funciona de maravilla para scripts de 20 líneas, maquetas visuales desechables o proyectos personales de fin de semana.

El Punto de Quiebre Técnico:

El enfoque colapsa estrepitosamente cuando se intenta aplicar a software empresarial de gran escala o sistemas productivos diseñados para perdurar en el tiempo.

Límite de Vida del Software

¿Durará más de 30 días con múltiples desarrolladores interactuando en él?

Xauen Devs • 22 de mayo de 2026 La Trampa del VibeCoding
Sección 02 • Diapositiva 2

Deuda Técnica Acelerada

3 sem

El Frankenstein Inmantenible

Tiempo estimado de degradación estructural sin control

Hiperinflación de Código por IA

Históricamente, la deuda técnica crecía orgánicamente por falta de tiempo. Con la IA, se inyecta de forma masiva en segundos porque el modelo carece de contexto global y solo busca resolver el prompt aislado del momento.

"Si le pides un parche ágil, te devolverá la solución más egoísta e inmediata, violando sigilosamente la arquitectura y cohesión general de tu código."

Xauen Devs • 22 de mayo de 2026 La Trampa del VibeCoding
Sección 02 • Diapositiva 3

Síntomas del Caos

Pérdida del Control del Flujo

Al no haber diseñado mentalmente la estructura de los datos, dejas de comprender cómo se comunican las dependencias. Nace el miedo a refactorizar porque se desconoce el impacto en el otro extremo de la app.

Parálisis por falta de control

El "Código Espagueti de IA"

Un caos sutil, ordenado e impecablemente indentado. Usa nombres de variables elegantes y comentarios sumamente convincentes, pero esconde un acoplamiento infernal y llamadas de base de datos ineficientes.

Caos vestido de gala
Xauen Devs • 22 de mayo de 2026 La Trampa del VibeCoding
Capítulo 01 • Sección 03

El Rol del Arquitecto

Sección 03 • Diapositiva 1

La Paradoja de Roles

Perspectiva del Junior

La Varita Mágica

Considera a la IA como un motor mágico para generar código de bajo nivel que él aún no domina, delegando de plano la responsabilidad del diseño conceptual del software.

Evasión de responsabilidad
Perspectiva del Arquitecto

Motor de Altísima Tracción

Sabe perfectamente que la IA es una turbina de arrastre ultrapotente. Precisamente por esa increíble fuerza, requiere de rieles de diseño inflexibles para no descarrilar el sistema.

Estructuración técnica estricta
Xauen Devs • 22 de mayo de 2026 La Trampa del VibeCoding
Sección 03 • Diapositiva 2

Diseño vs. Implementación

El histórico cuello de botella (memorizar APIs complejas, depurar sintaxis, escribir boilerplate) ha quedado superado de forma definitiva por la IA generativa.

El Verdadero Bottleneck Actual: El Criterio

Definir qué patrón de diseño encaja con el problema del negocio, cómo encapsular de forma limpia las capas lógicas de la aplicación y salvaguardar los límites del dominio.

Criterio sobre Sintaxis

Donde reside el verdadero valor del Ingeniero Senior en la actualidad.

Xauen Devs • 22 de mayo de 2026 La Trampa del VibeCoding
Sección 03 • Diapositiva 3

Tomar el Mando

Si dejas que la IA proponga de forma autónoma la arquitectura, elegirá la senda más genérica y propensa a generar incoherencias de diseño. Tu valor es definir las reglas del juego.

"La IA es un copiloto fantástico, pero si el piloto no sabe a dónde va el avión, el copiloto simplemente os ayudará a estrellaros contra la montaña mucho más rápido."

Xauen Devs • 22 de mayo de 2026 La Trampa del VibeCoding
Capítulo 02 • Sección 04

Documentación Viva

Sección 04 • Diapositiva 1

El Prompt es Efímero; la Spec es Permanente

Petición Reactiva

El Prompt Improvisado

Tratar la interfaz de chat de la IA como un bloc de notas donde se apilan parches rápidos y peticiones reactivas. Conduce irremediablemente a la inconsistencia y pérdida de control global.

Lienzo en blanco e ineficiente
Instrucción Persistente

La Design Spec

Un documento de diseño técnico escrito en Markdown que vive en tu repositorio junto al código de producción. Define de forma inmutable la guía rectora de desarrollo para la IA.

Documentación estructurada y duradera
Xauen Devs • 22 de mayo de 2026 Design Specs Development
Sección 04 • Diapositiva 2

¿Qué es una Spec en la Era de la IA?

No es una especificación pesada tradicional de 80 páginas. Es un manifiesto estructurado en Markdown (`.md`) que sirve como manual de referencia directo para los modelos.

✓ Lógicas del Negocio Reglas de dominio y casos de uso del mundo real.
✓ Límites del Diseño Patrón técnico elegido y contratos de servicios.
docs/specs/auth_system.md

# Spec: Autenticación

## 1. Casos de Uso

- Bloqueo tras 3 intentos fallidos.

## 2. Restricciones

- Token JWT debe expirar en 15m.

Xauen Devs • 22 de mayo de 2026 Design Specs Development
Sección 04 • Diapositiva 3

La IA como Consumidora

El Cambio Metodológico: Dónde Leer

Al configurar entornos nativos de IA (como las reglas de workspace o prompts del sistema), el Arquitecto ya no enseña a programar a la IA; le dice en qué parte del disco leer las políticas actuales.

System Rule: "Lee docs/specs/auth_system.md de forma obligatoria antes de modificar o crear archivos de lógica en este módulo."
Documentación Viva

Si las necesidades del negocio cambian, no alteras el prompt efímero: actualizas el archivo Markdown de la Spec en Git. La IA reacciona inmediatamente al nuevo contexto en el siguiente ciclo.

Xauen Devs • 22 de mayo de 2026 Design Specs Development
Capítulo 02 • Sección 05

Contratos como Fuente de Verdad

Sección 05 • Diapositiva 1

Cero Lógica sin Contrato

0%

Margen de Improvisación

Toda interfaz debe estar sellada antes de codificar la lógica

Fronteras Innegociables

Si dejas que la IA defina los esquemas de intercambio de información de forma dinámica, cada endpoint inventará un formato de datos diferente, rompiendo la coherencia de tu aplicación.

"El rigor metodológico inicia delimitando de forma matemática las fronteras de tu software antes de escribir una sola línea lógica."

Xauen Devs • 22 de mayo de 2026 Design Specs Development
Sección 05 • Diapositiva 2

Herramientas de Tipado y Validación

OpenAPI / Swagger

Definición formal e inequívoca del comportamiento del API (verbos, códigos de retorno y esquemas).

Contratos HTTP

Zod / TypeBox

Validación estricta y blindaje del tipado de entrada y salida en tiempo de ejecución.

Runtime Validation

Types de TS / Rust

Tipado estático inquebrantable que obliga al compilador a validar el flujo interno de la app.

Compile-time Safety
Xauen Devs • 22 de mayo de 2026 Design Specs Development
Sección 05 • Diapositiva 3

El Flujo del Contrato

Le proporcionas a la IA el contrato exacto (OpenAPI o la interfaz de TS) y le exiges acoplarse estrictamente a esa firma lógica.

Beneficio de Velocidad y Precisión:

Al automatizar la validación del contrato, el espacio probabilístico de respuestas de la IA se reduce drásticamente. El modelo ya no improvisa nombres; encauza todo su potencial computacional exclusivamente a codificar la lógica del negocio.

// Interfaz rígida e inamovible

interface UserPayload {

id: string;

email: string;

createdAt: Date;

}

Xauen Devs • 22 de mayo de 2026 Design Specs Development
Capítulo 02 • Sección 06

Context Window Optimization

Sección 06 • Diapositiva 1

El Mito del Contexto Infinito

Lost in the Middle

Retención atencional empírica del LLM

Más contexto no es mejor comprensión

Aunque las IA modernas soporten miles de tokens, su capacidad cognitiva y su precisión decaen a medida que añadimos ruido o archivos irrelevantes de la base de código.

"Inyectar datos innecesarios confunde al modelo, causando que ignore directrices críticas o mezcle accidentalmente bases lógicas antiguas con componentes nuevos."

Xauen Devs • 22 de mayo de 2026 Design Specs Development
Sección 06 • Diapositiva 2

Atomic Specs

specs/domain_model.md

Dominio Puro

Contiene de forma atómica únicamente las entidades y reglas duras del negocio, completamente libre de frameworks o librerías externas.

Capa del Negocio
specs/api_contracts.md

Firmas de APIs

Encapsula estrictamente las firmas públicas, endpoints definidos, validaciones de entrada y modelos Swagger.

Capa del Transporte
specs/infrastructure.md

Infraestructura

Modelados de persistencia de datos (como Prisma), adaptadores de almacenamiento y herramientas autorizadas.

Capa de Persistencia
Xauen Devs • 22 de mayo de 2026 Design Specs Development
Sección 06 • Diapositiva 3

Inyección Selectiva

Menos es más. Si vas a codificar el almacenamiento de persistencia, alimenta a la IA únicamente con el modelo del dominio y la especificación del ORM. Oculta el CSS de UI y la lógica de endpoints innecesaria.

"La IA no es mala leyendo código; nosotros somos malos acotando lo que tiene que leer. Diseñar la Spec es darle a la IA un mapa de Jaén en lugar de un globo terráqueo cuando solo tiene que ir a la catedral."

Xauen Devs • 22 de mayo de 2026 Design Specs Development
Capítulo 03 • Sección 07

Chain-of-Thought aplicado a la arquitectura

Sección 07 • Diapositiva 1

Razonamiento Antes que Código

El peligro inherente de los LLMs es la velocidad: escupen código tan rápido que no se detienen a analizar si es la senda óptima para el proyecto.

Rigor Metodológico CoT:

No consiste en pedirle que razone de forma genérica "paso a paso". Significa forzar al modelo a realizar un análisis técnico riguroso de trade-offs arquitectónicos en formato de texto puro antes de escribir una sola línea lógica.

Alterar el Orden

Obliga a estructurar conceptualmente la solución técnica primero.

Xauen Devs • 22 de mayo de 2026 La Técnica: Rigorous Prompting
Sección 07 • Diapositiva 2

El Prompt de Veto Arquitectónico

@prompt

"Analiza los requisitos de la Spec adjunta. Escribe un análisis técnico proponiendo cómo estructurar este servicio siguiendo Hexagonal. No generes código aún. Espera mi aprobación."

Exigir Planificación Escrita

En lugar de ordenarle de plano "escribe el código del módulo", se restringe su salida forzándole a debatir de forma reflexiva qué componentes formarán el dominio y cuáles la infraestructura.

"Se le despoja de su capacidad de improvisar obligándole a someter su plan estructural a tu veto conceptual."

Xauen Devs • 22 de mayo de 2026 La Técnica: Rigorous Prompting
Sección 07 • Diapositiva 3

Autolimitación Lógica

Anclar Razonamiento en Contexto

Al obligar al modelo a redactar un texto debatiendo sobre cohesión y patrones de diseño, este análisis queda firmemente alojado en su memoria activa de conversación.

Reducción del rango probabilístico

Ejecución de su Propio Plan

Al requerirle finalmente el código, la IA se autolimita de forma estricta y se autocorrige basándose en las conclusiones técnicas que ella misma acaba de plasmar en la ventana de chat.

La IA sigue un plan real
Xauen Devs • 22 de mayo de 2026 La Técnica: Rigorous Prompting
Capítulo 03 • Sección 08

Iteración por capas: El fin del "Hazme toda la app"

Sección 08 • Diapositiva 1

La Falacia de la Petición Única

El enfoque entusiasta e ingenuo consiste en pedir todo un boilerplate lógicas de base de datos, API y frontales en un único comando masivo.

El Caos de la Mezcla de Conceptos:

Por pura probabilidad matemática, el modelo confundirá las fronteras. Acabará insertando lógica de negocio compleja dentro del controlador HTTP o consultas SQL directas en la capa de transporte.

Dosificar la Construcción

Exactamente igual que estructurarías las fases de entrega en un equipo técnico de alto rendimiento.

Xauen Devs • 22 de mayo de 2026 La Técnica: Rigorous Prompting
Sección 08 • Diapositiva 2

Flujo Secuencial Estricto

Aislamiento de Responsabilidades
1. Capa de Dominio
2. Capa de Aplicación
3. Infraestructura

Construir con Núcleo Blindado

1. Capa de Dominio Primero: Entidades puras y value objects libres de dependencias de ORMs o drivers. Validamos de forma aislada las reglas puras del negocio.

2. Capa de Aplicación: Orquestadores, casos de uso prácticos e interfaces (puertos) lógicas de salida.

3. Infraestructura al Final: Adaptadores lógicos, controladores e integraciones directas con frameworks o bases de datos físicas.

Xauen Devs • 22 de mayo de 2026 La Técnica: Rigorous Prompting
Sección 08 • Diapositiva 3

El Beneficio del Aislamiento

Blindar las capas nucleares elimina de plano el acoplamiento cruzado de variables en el sistema.

Migraciones y Cambios Instantáneos:

Si mañana requieres migrar tu framework HTTP de Express a Fastify, o tu ORM de Prisma a consultas nativas SQL, la IA podrá acometer la migración estructural completa en segundos dado que el contexto general se mantiene limpio, desacoplado y perfectamente delimitado.

Migración Segura

El desacoplamiento habilita la agilidad real en la era de los modelos generativos.

Xauen Devs • 22 de mayo de 2026 La Técnica: Rigorous Prompting
Capítulo 03 • Sección 09

Test-Driven Development (TDD) + IA: Los raíles de acero

Sección 09 • Diapositiva 1

Los Tests no se Negocian

Código que nace muerto

Cualquier fragmento lódigo generado por una IA que carezca de tests automáticos.

Blindar Criterios de Aceptación

Tener una Design Spec clara y unos contratos perfectamente tipados proporciona de manera automática los criterios de aceptación ideales para orquestar tests de integración robustos antes de programar una sola función lógica.

Xauen Devs • 22 de mayo de 2026 La Técnica: Rigorous Prompting
Sección 09 • Diapositiva 2

Suite de Tests Primero (Rojo)

Alimentamos a la IA con la Spec de diseño y las interfaces de contratos definidas, y le ordenamos escribir de forma exclusiva la suite de tests en base a ese alcance.

El Estado Rojo Inicial

La suite generada de Jest, Vitest o Rust nativo se ejecuta y falla inmediatamente debido a que no existe aún implementación de código funcional para resolver los criterios de validación.

Flujo TDD + IA
1. Spec Conceptual
2. Test en Rojo
3. IA Genera Código
4. Test en Verde
Xauen Devs • 22 de mayo de 2026 La Técnica: Rigorous Prompting
Sección 09 • Diapositiva 3

Bucle Determinista de Calidad

Entrega la suite de tests en rojo y ordena a la IA: "Escribe la lógica necesaria para poner en verde todos estos tests. Prohibido tocar la suite de validación."

"No evalúes el código de una IA leyendo sus líneas de texto; evalúalo haciendo que se estrelle contra tus tests. Si sobrevive a los tests y cumple la Spec, entonces y solo entonces, tienes software de verdad."

Xauen Devs • 22 de mayo de 2026 La Técnica: Rigorous Prompting
Capítulo 04 • Sección 10

Demo Práctica: De la Spec al Verde

Sección 10 • Diapositiva 1

El Desafío: Levantar un Servicio de Cero

Enfrentamos a la IA a un escenario empresarial real en directo: estructurar un microservicio de facturación con reglas complejas.

Preparando el Terreno:

En lugar de abrir un chat vacío, inyectamos nuestra Atomic Spec y el Contrato OpenAPI definido en los raíles del espacio de trabajo. Acotamos el universo del modelo.

Entorno Controlado

Cero improvisación. La IA lee el repositorio de especificaciones antes de teclear.

Xauen Devs • 22 de mayo de 2026 Demo Práctica
Sección 10 • Diapositiva 2

La IA Bajo Control: Ejecución TDD

FAIL (Suite en Rojo)

✗ shouldCalculateTaxesCorrectly

✗ shouldApplyDiscountOnBulk

Total: 2 failed, 2 total

El Bucle del Programador

La IA genera la suite de pruebas contra la Spec. Ejecutamos: los tests fallan de inmediato. Entregamos el fallo del compilador a la máquina y le vetamos modificar el test.

"El modelo no tiene opción de inventar salidas creativas. Solo puede programar el código exacto que de forma determinista sane la suite de pruebas."

Xauen Devs • 22 de mayo de 2026 Demo Práctica
Sección 10 • Diapositiva 3

Soberanía de Código y Verde

La suite pasa a Verde de forma limpia. El microservicio está completamente blindado ante regresiones y deuda técnica.

Cero Deuda Técnica Acumulada

Al estructurar el flujo con rigor técnico, erradicamos la hiperinflación de código y el acoplamiento caótico de raíz. El arquitecto conserva el control absoluto de la soberanía técnica del software de la empresa.

PASS (Green State)

100% Cobertura de la Spec

Garantía matemática y determinista en vivo

Xauen Devs • 22 de mayo de 2026 Demo Práctica

¡Gracias!

Hacia un desarrollo determinista con Inteligencia Artificial.

Xauen Devs • 22 de mayo de 2026

1 / 43