Xauen Devs • 22 de mayo de 2026
Por qué tu IA necesita un Arquitecto,
no un entusiasta
Usa las flechas ◀ ▶ o Espacio para navegar
@xtoxico
Entusiasta y adoptante de la IA desde sus inicios, aplicando control arquitectónico estricto.
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.
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.
Aceptación ciega de bloques de código por la simple ausencia de alertas visuales.
50 líneas de código
Gratificación instantánea automatizada
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."
Inversión previa de tiempo para conceptualizar la modularidad, acoplamiento, flujos y manejo de excepciones antes de tocar una sola tecla del editor.
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.
El VibeCoding funciona de maravilla para scripts de 20 líneas, maquetas visuales desechables o proyectos personales de fin de semana.
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?
El Frankenstein Inmantenible
Tiempo estimado de degradación estructural sin control
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."
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.
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.
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.
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.
El histórico cuello de botella (memorizar APIs complejas, depurar sintaxis, escribir boilerplate) ha quedado superado de forma definitiva por la IA generativa.
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.
Donde reside el verdadero valor del Ingeniero Senior en la actualidad.
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."
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.
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.
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.
# Spec: Autenticación
## 1. Casos de Uso
- Bloqueo tras 3 intentos fallidos.
## 2. Restricciones
- Token JWT debe expirar en 15m.
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.
Margen de Improvisación
Toda interfaz debe estar sellada antes de codificar la lógica
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."
Definición formal e inequívoca del comportamiento del API (verbos, códigos de retorno y esquemas).
Validación estricta y blindaje del tipado de entrada y salida en tiempo de ejecución.
Tipado estático inquebrantable que obliga al compilador a validar el flujo interno de la app.
Le proporcionas a la IA el contrato exacto (OpenAPI o la interfaz de TS) y le exiges acoplarse estrictamente a esa firma lógica.
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;
}
Retención atencional empírica del LLM
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."
Contiene de forma atómica únicamente las entidades y reglas duras del negocio, completamente libre de frameworks o librerías externas.
Encapsula estrictamente las firmas públicas, endpoints definidos, validaciones de entrada y modelos Swagger.
Modelados de persistencia de datos (como Prisma), adaptadores de almacenamiento y herramientas autorizadas.
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."
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.
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.
Obliga a estructurar conceptualmente la solución técnica primero.
"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."
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."
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.
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.
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.
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.
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.
Blindar las capas nucleares elimina de plano el acoplamiento cruzado de variables en el sistema.
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.
El desacoplamiento habilita la agilidad real en la era de los modelos generativos.
Cualquier fragmento lódigo generado por una IA que carezca de tests automáticos.
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.
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.
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.
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."
Enfrentamos a la IA a un escenario empresarial real en directo: estructurar un microservicio de facturación con reglas complejas.
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.
Cero improvisación. La IA lee el repositorio de especificaciones antes de teclear.
✗ shouldCalculateTaxesCorrectly
✗ shouldApplyDiscountOnBulk
Total: 2 failed, 2 total
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."
La suite pasa a Verde de forma limpia. El microservicio está completamente blindado ante regresiones y deuda técnica.
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.
100% Cobertura de la Spec
Garantía matemática y determinista en vivo
Hacia un desarrollo determinista con Inteligencia Artificial.
Xauen Devs • 22 de mayo de 2026