PIVO&CODE 41 • 22/may/26
Prompting Riguroso
Por qué tu IA necesita un Arquitecto,
no un entusiasta
Usa las flechas ◀ ▶ o Espacio para navegar
¿Quién soy?
Antonio Tirado Peña
@xtoxico
- 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)
- Azure Solutions Architect Expert, Linux (LPIC2), Oracle DB, Cisco (CCNA), Python (IBM)
- Maker de corazón | Perfil Hands-on | Cultura DIY | Arch Linux User
Entusiasta y adoptante de la IA desde sus inicios, aplicando control arquitectónico estricto.
¿Qué es el VibeCoding?
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 por "sensaciones" o "vibras": escribir una idea vaga en Cursor, Copilot o ChatGPT y aceptar ciegamente el código resultante porque, a primera vista, "parece que funciona" o el linter no da errores.
"Vibras sobre Rigor"
Aceptación ciega de bloques de código por la simple ausencia de alertas visuales.
El Sesgo de la Inmediatez
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.
"Confundimos escribir código rápido con resolver problemas de ingeniería."
Erosión del Análisis Crítico
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.
Espectador Pasivo
Delegación del pensamiento en el modelo. El desarrollador se limita a validar superficialmente que el "happy path" funciona en local.
El Coste de las Sensaciones
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 se rompe cuando intentas aplicarlo a software empresarial o a sistemas que tienen que durar más de un mes.
Límite de Vida del Software
¿Durará más de 30 días con múltiples desarrolladores interactuando en él?
Deuda Técnica Acelerada
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, te dará el parche más rápido, aunque ignore el patrón arquitectónico del resto del proyecto."
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.
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.
El Rol del Arquitecto
La Paradoja de Roles
La Varita Mágica
Ve la IA como una varita mágica que escribe el código que aún no sabe escribir.
Motor de Altísima Tracción
Ve la IA como un motor de ejecución ultrapotente que necesita raíles estrictos para no descarrilar.
Diseño vs. Implementación
El cuello de botella ya no es memorizar sintaxis ni escribir boilerplate. Eso lo resuelve muy bien la IA.
El Verdadero Bottleneck Actual: El Criterio
Saber qué patrón de diseño encaja, cómo aislar las capas de la aplicación y cuáles son las restricciones reales de negocio.
Criterio sobre Sintaxis
Donde reside el verdadero valor del Ingeniero Senior en la actualidad.
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."
Documentación Viva
El Prompt es Efímero; la Spec es Permanente
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.
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.
¿Qué es una Spec en la Era de la IA?
Es un archivo `.md`, o un conjunto pequeño de archivos, que vive en el repositorio junto al código y contiene reglas de negocio, casos de uso, arquitectura y restricciones técnicas.
# Spec: Autenticación
## 1. Casos de Uso
- Bloqueo tras 3 intentos fallidos.
## 2. Restricciones
- Token JWT debe expirar en 15m.
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.
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.
Contratos como Fuente de Verdad
Cero Lógica sin Contrato
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."
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).
Zod / TypeBox
Validación estricta y blindaje del tipado de entrada y salida en tiempo de ejecución.
Types de TS / Rust
Tipado estático inquebrantable que obliga al compilador a validar el flujo interno de la app.
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.
interface UserPayload {
id: string;
email: string;
createdAt: Date;
}
Context Window Optimization
El Mito del Contexto Infinito
Atención dispersa / Lost in the Middle
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."
Atomic Specs
Dominio Puro
Contiene de forma atómica únicamente las entidades y reglas duras del negocio, completamente libre de frameworks o librerías externas.
Firmas de APIs
Encapsula estrictamente las firmas públicas, endpoints definidos, validaciones de entrada y modelos Swagger.
Infraestructura
Modelados de persistencia de datos (como Prisma), adaptadores de almacenamiento y herramientas autorizadas.
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."
Chain-of-Thought aplicado a la arquitectura
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.
El Prompt de Veto Arquitectónico
"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."
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.
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.
Iteración por capas: El fin del "Hazme toda la app"
La Falacia de la Petición Única
El enfoque entusiasta consiste en pedir un boilerplate completo de una sola vez: base de datos, API, validaciones y estructura de proyecto.
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.
Flujo Secuencial Estricto
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.
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.
Test-Driven Development (TDD) + IA: Los raíles de acero
Los Tests no se Negocian
Código que nace muerto
Cualquier fragmento de código generado por 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.
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.
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."
Demo Práctica
¡Gracias!
Hacia un desarrollo determinista con Inteligencia Artificial.
PIVO&CODE 41 • 22/may/26