ASDM
AI-Assisted Spec-Driven Methodology
PRESENTACIÓN · v0.1
AI-Assisted Spec-Driven Methodology
ASDM
Una metodología para desarrollar software con agentes de IA sin perder el control del proceso.
El punto de partida: una necesidad de negocio ◇ Idea BRS, REQ, ARCH, DDL — la especificación es la fuente de verdad ▤ Especificación Gate: aprobación humana obligatoria antes de avanzar Gate Skills expertos generan el código siguiendo la especificación aprobada </> Código Entrega validada, trazable y auditable ✓ Entregado
De la idea a la entrega, con un gate humano en el camino
Sixto J. · IT Project Manager & Arquitecto de Software · 02/07/2026
02 / 11

Spec-Driven Development

Idea fuerza Especificar antes de generar es lo que separa un proyecto controlado de uno improvisado.

El Spec-Driven Development consiste en definir con precisión el «qué» y el «porqué» de una funcionalidad antes de que un agente de IA genere una sola línea de código. La especificación —no el prompt improvisado— se convierte en la fuente de verdad del proyecto.

Sin SDD, el código generado funciona a corto plazo, pero pierde trazabilidad: nadie sabe qué decisión originó cada línea, ni cómo auditar o mantener el sistema con garantías cuando el equipo cambia o el proyecto crece.

SIN SDD Prompt improvisado, sin especificación previa Prompt Código que funciona hoy, sin registro de por qué Código ? ? ? sin trazabilidad CON SDD Necesidad de negocio identificada Idea El «qué» y el «porqué» quedan escritos, no en la memoria de nadie Spec Código trazable hasta el requisito que lo originó Código ✓ trazable · auditable
03 / 11

ASDM: algo más que SDD

Idea fuerza ASDM no solo especifica antes de generar: valida antes de automatizar, y coloca al humano en los puntos que importan.

Sobre la base de la especificación, ASDM añade dos principios propios que determinan cómo se ejecuta el proyecto en la práctica.

Validar antes de automatizar — No se automatiza nada hasta demostrar, con casos reales, que el patrón funciona y su coste de error es asumible
Gates humanos — Puntos de aprobación obligatorios entre fases: decide el criterio humano, no el agente
nuevo patrón Se prueba a mano, con casos reales Manual Tasa de error y coste del error, ya conocidos Validado Solo entonces se automatiza el paso Automa- tizado
manual → validado → automatizado
Fase de trabajo — genera un artefacto verificable Fase 1 Gate: no se avanza sin aprobación humana Fase de trabajo — genera un artefacto verificable Fase 2 Gate: no se avanza sin aprobación humana Fase 3 ◈ = aprobación humana obligatoria
04 / 11

RadarDD

Idea fuerza No se aplica todo al máximo en todos los proyectos: se dosifica cada técnica según lo que el proyecto necesita.

RadarDD aplica técnicas ya conocidas del desarrollo de software —no inventa de cero— y las dosifica según la naturaleza de cada proyecto, como un radar que asigna intensidad por distancia en lugar de emitir siempre al máximo. Los 12 principios se agrupan en tres áreas (negocio, diseño, construcción) y se colorean por tipo: motor de diseño, verificación o restricción transversal.

Entre estas últimas, Sec-DD —seguridad desde el diseño— se aplica de forma automática en los skills técnicos: no hace falta pedirla, viene incorporada en cómo el agente genera cada componente.

Mapa de los doce principios de diseño e implementación agrupados por área de preocupación Doce principios DD agrupados en tres áreas de preocupación (negocio, diseño, construcción), con el color indicando si cada uno es un motor de diseño que produce artefacto, una verificación, o una restricción transversal. Sec-DD atraviesa las tres áreas. Entre áreas hay gates de decisión. Todo converge en el sprint log con su Definition of Done, que es el entregable antes de codificar. Motor de diseño Verificación / validación Restricción transversal Sec-DD transversal cumplimiento ENS · RGPD arquitectura authn · cifrado operativo SAST · deps Negocio · el qué Spec-DDrequisitos Behavior-DDcriterios UAT Domain-DDlenguaje ubicuo Gate · negocio validado Diseño · el cómo Arch-DDno-funcionales Data-DDBBDD · CQS Model-DDobjetos negocio API-DDcontratos REST Event-DDasync · eventos UX/UI-DDpantallas Gate · diseño congelado + DoD Construcción · el código (se codifica como DoD) Test-DDtest-first · cobertura Clean-DDSOLID·DRY·KISS·YAGNI Sprint Log + Definition of Doneel entregable antes de escribir código El peso de cada área varía según el proyecto — los gates frenan las malas decisiones
05 / 11

El Skill: unidad de trabajo

Idea fuerza Cada fase se ejecuta mediante un skill: una receta estructurada que le dice al agente exactamente cómo actuar.

Un SKILL.md no es una idea propia de ASDM: es un formato ya adoptado como estándar abierto por más de 30 entornos de agentes de IA. Cada skill define el objetivo de la fase, el proceso a seguir, los criterios de calidad y el formato exacto del artefacto de salida.

Esto le da a la metodología algo poco habitual: portabilidad real. El mismo skill funciona, con ajustes mínimos, en distintos modelos y entornos de desarrollo.

--- name · description · triggers --- Objetivo de la fase que ejecuta este skill ① Objetivo Proceso paso a paso que debe seguir el agente ② Proceso Criterios de calidad que debe cumplir el resultado ③ Criterios Formato exacto del artefacto de salida ④ Salida objetivo de la fase pasos a seguir qué debe cumplirse formato del artefacto
06 / 11

Las 3 etapas

Idea fuerza Todo proyecto ASDM recorre el mismo camino: Diseño → Implementación → Entrega y mantenimiento.

Cada etapa se apoya en skills específicos y termina en un gate que exige aprobación humana antes de continuar.

Etapa 1 — Diseño
Negocio · requisitos · arquitectura · datos
Etapa 2 — Implementación
Backlog · sprints · entrega gradual · UAT
Etapa 3 — Entrega
DevOps · mantenimiento · soporte
07 / 11 ETAPA 1

Diseño: skills y artefactos

Idea fuerza Antes de escribir una sola línea de código, el proyecto ya está especificado de punta a punta.

La Etapa 1 convierte una idea de negocio en un conjunto de documentos verificables: qué necesita el negocio, cómo trabajan los usuarios, qué arquitectura lo soporta y qué datos maneja.

business-analyst→BRS — requisitos de negocio
user-journeys→JOURNEYS — flujos de trabajo por actor
requirements-analyst→REQ — requisitos funcionales y no funcionales
architecture-designer→ARCH + TECH-DECISIONS
data-model-designer→DDL + ERD
business-analyst → BRS Negocio user-journeys → JOURNEYS Journeys requirements-analyst → REQ Requisitos architecture-designer → ARCH + TECH-DECISIONS Arquitectura data-model-designer → DDL + ERD Datos Gate G1 — aprobación humana obligatoria G1
08 / 11 ETAPA 2

Implementación: skills y artefactos

Idea fuerza El desarrollo avanza en sprints con criterios de calidad explícitos, no a golpe de intuición.

A partir de la arquitectura y el modelo de datos, ASDM planifica el trabajo en sprints con historias de usuario, story points y una Definition of Done verificable para cada tarea.

sprint-planner→ROADMAP + SPRINT-XX
skills expertos (stack)→Código de cada módulo, siguiendo el stack del proyecto
Definition of Done→Criterio de cierre verificable por tarea
UAT→Validación del usuario final en cada entrega
sprint-planner → ROADMAP + SPRINT-XX Planificación skills expertos (stack) → código por módulo Código Definition of Done → criterio de cierre por tarea DoD UAT → validación del usuario final por entrega UAT Gate G2 — aprobación humana obligatoria G2
09 / 11 ETAPA 3

Entrega, mantenimiento y soporte

Idea fuerza El proyecto no termina al desplegar: mantenerlo con disciplina es parte de la metodología, no una excepción.

ASDM cubre también el ciclo de vida posterior al despliegue: gestión de incidencias, mantenimiento correctivo y evolución del sistema en producción.

DevOps→Despliegue y operación del sistema
Gestión de incidencias→Resolución de tickets con trazabilidad
Mantenimiento correctivo→Postmortem clasificado + commit único de fix y documentación
DevOps → despliegue y operación del sistema DevOps Gestión de incidencias → resolución de tickets con trazabilidad Incidencias Mantenimiento correctivo → postmortem clasificado + commit único de fix y documentación Mantenim. Gate G3 — aprobación humana obligatoria G3
10 / 11

Evolución: CLI y hoja de ruta

Idea fuerza La metodología se apoya en una herramienta que guía al usuario, y evoluciona hacia una versión pública y más madura.

Un CLI de apoyo permite saber en todo momento en qué fase está el proyecto, qué falta y qué toca a continuación, sin depender de la memoria del usuario ni del agente.

De la validación con proyectos reales están naciendo aprendizajes que ya dan forma a la siguiente versión: ASDM evoluciona hacia GuardSpec, su maduración pública como marco reutilizable.

$ asdm-meth status
◉ Fase     : F00 — Discovery  [ACTIVA]
◉ Gate     : G00              [PENDIENTE]
✓ 2/4 artefactos completados
○ Próximo  : generar prototipo
status · next · gate · context
hoy Metodología en validación activa con proyectos reales ASDM metodología validada Evolución pública — en validación, sin fecha de publicación cerrada Guard- Spec evolución pública
11 / 11

Por qué importa

Idea fuerza Cuando generar código es casi gratis, lo que tiene valor es la capa de intención y verificación por encima de ese código.

Esa es la apuesta de ASDM: no compite con la velocidad de la IA generando código, sino que gobierna esa velocidad con especificación, principios dosificados y control humano en los puntos que importan.

Gracias por la atención. Quedo abierto a preguntas.

↑ aquí está el valor Especificación, RadarDD y gates humanos — lo que ASDM aporta Intención + verificación Lo que genera el agente de IA a partir de la especificación Código generado por IA Servidores, redes, servicios sobre los que corre el sistema Infraestructura