Software Architect · Módulo 22
La AI no reemplaza el pensamiento arquitectónico. Acelera la exploration, la critique y la documentación — si el arquitecto sabe poner el marco y verificar el resultado.
AI-assisted design · critique · verification · quality gates
La AI es útil como amplificador del reasoning y peligrosa como fuente de confianza no verificada.
La AI amplía bien el espacio de opciones
Un asistente puede traer diez mapas de ruta en un minuto. El conductor sigue siendo el dueño de la elección del camino.
El arquitecto puede usar AI para generar alternatives, risk checklists, borradores de ADR, comparaciones de trade-offs, escenarios de testing, amenazas de security y preguntas de review. Eso acelera la preparación.
Pero la AI no conoce todo el contexto del sistema, puede alucinar APIs, subestima el operational cost y suena segura justo donde se necesitan datos. Por eso el output tiene que pasar por verification: el codebase, las docs, las métricas, los constraints y el conocimiento del equipo.
El prompt tiene que llevar constraints
Pedirle a un arquitecto "diseñá una casa" no significa nada. Necesitás el terreno, el presupuesto, el clima, la familia, los plazos y las restricciones.
Para trabajo arquitectónico, la AI necesita contexto: el dominio, la arquitectura actual, la team topology, la carga, compliance, restricciones de presupuesto, objetivos de producto, decisiones existentes y criterios de éxito.
Sin constraints, el modelo tiende a las generic best practices: microservicios, Kafka, Kubernetes, event sourcing. Eso puede ser bello y dañino al mismo tiempo.
El trabajo AI-native debe reforzar la disciplina de ingeniería, no esquivarla.
Ejemplo: AI como reviewer de ADR
El copiloto no vuela el avión en lugar del capitán — ayuda a chequear los instrumentos y a detectar lo que se le pasó.
El equipo escribe un ADR sobre la migración a async processing. La AI recibe el contexto, el ADR, los constraints y la lista de incidents conocidos. Su tarea: encontrar missing risks, assumptions poco claras, migration gaps y test scenarios. El arquitecto revisa el output y suma los puntos reales al documento.
Así la AI ayuda a sacar a la luz los blind spots sin tomar la decisión por el equipo.
Antiejemplo: aceptar un diseño AI sin verificación
Un plano hermoso de un puente es inútil si nadie revisó el suelo, la carga y los materiales.
La AI propone event sourcing y CQRS para un sistema CRUD simple. El equipo acepta porque la explicación suena profesional. Un mes después aparecen la complejidad del replay, schema evolution, debugging y el onboarding del equipo — y el business value no se movió.
La AI puede acelerar el over-engineering cuando el arquitecto no sostiene los criterios de calidad.
- ¿Qué constraints le pasé a la AI? - ¿Qué hechos hay que verificar contra el código o la documentación? - ¿Dónde pudo la AI proponer una generic solution? - ¿Qué quality gates nos protegen del output no verificado?