ASDM es una metodología que resuelve el problema fundamental del desarrollo asistido por IA: los agentes no tienen memoria entre sesiones y generan código inconsistente sin contexto. La solución es documentar antes de implementar.
Los agentes de IA son extraordinariamente capaces, pero tienen una limitación estructural que el flujo de desarrollo tradicional no resuelve: cada sesión empieza desde cero.
Cada fase produce un documento que alimenta a la siguiente. No se avanza hasta que el artefacto está commitado en Git.
Sesión de entrevista guiada entre la IA y el responsable funcional. Rondas iterativas de preguntas con opciones. El documento resultante habla exclusivamente en lenguaje de negocio: sin tecnologías, sin tablas, sin capas. Solo actores, flujos y criterios de aceptación verificables.
4 bloques de decisiones: stack base (con versiones concretas), capas y módulos, componentes e integraciones, y restricciones no funcionales. Cada decisión se documenta con alternativas consideradas y su justificación. Sensible al contexto AAPP/ENS. Genera diagrama de componentes en Mermaid.
El diferenciador de ASDM. Antes de diseñar ninguna tabla, se construye el Query Inventory: todas las operaciones de datos que el sistema necesita, clasificadas por frecuencia. El esquema satisface ese inventario. Cada índice está justificado por una query concreta. Auditoría doble nivel, NLS español, scripts Flyway Oracle 19c.
Genera primero el roadmap con épicas e historias de usuario (Fibonacci), con dependencias derivadas del ARCH y el DDL. Luego genera los sprints uno a uno con tareas de granularidad módulo completo. Cada tarea incluye: alcance detallado, DoD verificable y prompt ejecutable en dos partes (contexto + instrucción) listo para pasar al agente.
El desarrollador abre la tarea del sprint, copia el prompt (contexto + instrucción) y lo pasa al agente con los skills de implementación activos. El agente tiene todo el contexto para trabajar de forma autónoma. El desarrollador actúa como revisor, verificando contra el DoD en lugar de juzgar subjetivamente.
Cada skill es un documento de instrucciones que Claude lee antes de ejecutar una tarea, garantizando comportamiento consistente y reproducible.
Conduce la sesión de definición de requisitos mediante rondas iterativas de preguntas con opciones. El documento resultante habla solo en lenguaje de negocio.
Toma el REQ y conduce la entrevista arquitectónica en 4 bloques. Versiones concretas del stack, sensible al contexto AAPP/ENS, genera diagrama Mermaid.
Construye el Query Inventory desde los REQ antes de diseñar ninguna tabla. El esquema satisface las operaciones reales. Flyway Oracle 19c, auditoría doble nivel, NLS español.
Genera roadmap con épicas e historias, luego sprints con tareas de granularidad módulo completo. El prompt de cada tarea tiene dos partes: contexto (qué leer) e instrucción ejecutable.
ASDM no es un proceso burocrático. Es la infraestructura mínima necesaria para que los agentes de IA produzcan trabajo de calidad y consistente a lo largo del tiempo.
Todos los agentes de todos los sprints consultan el mismo ARCH. El código del Sprint 5 tiene la misma estructura que el del Sprint 1 porque ambos leyeron el mismo documento.
¿Hazelcast o Redis? Se decide una vez, con alternativas documentadas. Ningún agente futuro pregunta ni reinventa la respuesta. La deuda técnica por inconsistencia desaparece.
Los índices del DDL están justificados por queries reales antes de escribir código. Sin índices añadidos reactivamente cuando ya hay problemas en producción.
Un nuevo miembro del equipo lee 4 documentos (REQ + ARCH + ERD + ROADMAP) y entiende el sistema completo: qué hace, cómo está construido y qué queda por hacer.
El desarrollador verifica contra el DoD y el ARCH, no juzga subjetivamente. Si el código cumple el contrato, está bien. La revisión se vuelve sistemática y reproducible.
Cada prompt referencia secciones concretas del ARCH. Si la arquitectura cambia, se actualiza el ARCH y todos los prompts futuros son automáticamente coherentes.
Toda metodología tiene límites. Estos son los gaps actuales de ASDM v1.0 que determinan su roadmap de evolución.
Cuando los requisitos cambian después de iniciar la implementación, no hay un proceso formal para actualizar REQ-v2.md, propagarlo al ARCH y evaluar el impacto en los sprints pendientes. La gestión del cambio es manual.
Los skills de análisis (4 skills ASDM) y los skills de implementación (spring-boot-expert, angular-expert, cybersecurity-expert) son piezas separadas. No hay un mecanismo formal que active automáticamente los skills correctos al ejecutar una tarea.
La experiencia de implementación (velocidad real, historias que crecen en complejidad, decisiones del ARCH que resultaron inadecuadas) no fluye de vuelta a los documentos de análisis de forma sistemática. El aprendizaje es manual.
No existe un mecanismo automático que verifique que el código generado por los agentes respeta la estructura de módulos del ARCH (sin dependencias cruzadas entre módulos, paquetes correctos, etc.). La verificación es manual en el DoD.
ASDM está validado para sistemas monolíticos modulares con un solo repositorio. La extensión a arquitecturas de microservicios con múltiples repos, contratos de API entre servicios y despliegue independiente no está cubierta en v1.0.
La metodología está diseñada para un agente ejecutando tareas de forma secuencial o semiparalela bajo supervisión humana. El uso de múltiples agentes trabajando en paralelo sobre el mismo proyecto plantea problemas de conflictos y coherencia no resueltos.
La metodología es un proyecto vivo. Cada versión cierra uno o más gaps y añade capacidades que multiplican la autonomía de los agentes.
4 skills de análisis (requirements-analyst, architecture-designer, data-model-designer, sprint-planner) validados en un proyecto completo de 96 story points, 5 sprints y 21 tareas técnicas con prompts ejecutables.
Cierra el Gap 02: los prompts de cada tarea activan automáticamente los skills de implementación correctos mediante un mecanismo de selección declarativa en el SPRINT-NN.md. Un skill "implementation-router" decide qué stack activar según el módulo ARCH.
Cierra el Gap 01: un skill "change-manager" analiza el impacto de un cambio de requisito sobre el ARCH y el DDL existentes, genera las secciones modificadas de los documentos con control de versiones y propone los ajustes al roadmap.
Cierra el Gap 03: un "retrospective-analyst" skill analiza las notas de la retrospectiva del sprint, detecta decisiones del ARCH que resultaron inadecuadas, y propone actualizaciones de documentos y ajustes de velocidad para los sprints siguientes.
Cierra los Gaps 04, 05 y 06: extensión de la metodología a arquitecturas distribuidas con múltiples repositorios, contratos OpenAPI entre servicios, tests de conformidad arquitectónica automatizados (ArchUnit), y orquestación de múltiples agentes trabajando en paralelo con resolución de conflictos.
Una herramienta web que implementa el flujo ASDM de forma visual: interfaz de entrevista guiada con edición de documentos en tiempo real, visualización del grafo de dependencias entre sprints, exportación de prompts y seguimiento del estado de cada tarea por agente.
La metodología está documentada en detalle y los skills están disponibles para instalar en Claude. Si quieres colaborar, proponer mejoras o compartir tu experiencia aplicándola, estoy a un mensaje de distancia.