La Metodología Designio
El recorrido completo del método, fiel al libro y con su vocabulario: de los pilares al sprint semanal, de la Fase 0 al dividendo de la intención. Cada bloque ancla su capítulo y enlaza la plantilla descargable correspondiente — esta página es la síntesis; el libro, la profundidad.
Los seis pilares de la metodología
Designio no es un acrónimo ni un juego de iniciales: es la palabra que mejor nombra la idea de todo el libro. Un designio es una intención deliberada, un propósito firme, un plan trazado con voluntad. Sobre esa idea, la metodología se sostiene en seis pilares.
La intención es el pilar central, del que toma el nombre la metodología: toda construcción nace de una intención de negocio capturada, despejada de ambigüedad y convertida en una EIS que la máquina puede ejecutar y un humano puede auditar.
La gobernanza: la máquina construye, pero no manda. El Agente Guardián orquesta y controla, los roles humanos firman lo que importa, y un comité tiene la última palabra cuando algo se sale de lo previsto.
La construcción agéntica es el motor de ejecución: agentes que levantan el software a una velocidad imposible para un equipo humano, trabajando sobre la intención certificada. Es lo que se delega, y lo único que se delega.
La trazabilidad inmutable: todo queda registrado de forma inalterable. No es una carga de auditoría, es la memoria del proyecto, el conocimiento que sobrevive a las personas.
El contexto: un agente sin contexto construye a ciegas. Este pilar es todo lo que el sistema necesita saber para trabajar «a la manera de la casa».
La seguridad: un control especializado audita el código antes de que se despliegue nada, porque la velocidad no puede comprometer la integridad.
El capítulo 1 del libro desarrolla cada pilar y explica por qué, juntos, convierten la IA generativa en soberanía y no en caja negra.
«Y eso es justo lo que esta metodología defiende: que la intención humana, clara y deliberada, es la que manda, y que la máquina ejecuta esa intención sin apropiarse de ella.»
— Soberanía de la Intención, p. 17
Las cuatro fases de la implantación
Un proyecto gobernado con Designio atraviesa cuatro fases bien diferenciadas. No son una cascada: son el recorrido lógico por el que madura la intención, y su peso cambia radicalmente según el proyecto.
Fase de Configuración de Roles. Antes de tocar una sola línea de código, lo que tiene que cambiar son las personas: el personal técnico deja de producir código y evoluciona hacia la figura del Intent Director, que dirige la intención en lugar de escribir la sintaxis. El libro analiza con honestidad qué perfiles se reconvierten mejor (consultores funcionales, gestores de proyecto, especialistas de QA) y cuáles necesitan más acompañamiento.
Fase de cimientos (Fase 0). Auditar el punto de partida, montar la estructura de gobierno, codificar el ADN arquitectónico de la casa y poner las barreras de seguridad y de gasto. Es la fase de mayor fricción de toda la metodología, y casi desaparece en un proyecto greenfield.
Fase de construcción (el sprint). El corazón ejecutor: un ciclo semanal cerrado de intención, construcción gobernada y validación humana, donde el artefacto central es la EIS (Especificación Ejecutable de Intenciones) con sus cuatro elementos: contexto técnico, restricciones de arquitectura, criterios de aceptación y definición de «hecho».
Fase de evolución (el activo vivo). El software en producción no se acaba: empieza a vivir. Cada cambio nace de una intención registrada, y el horizonte es un activo que se cultiva y gana valor con el tiempo en lugar de degradarse.
El capítulo 1 explica por qué la semana es la unidad natural del ciclo y por qué el cuello de botella ya no es construir, sino validar.
«Entiéndelas, por tanto, como las cuatro grandes etapas por las que pasa la intención hasta convertirse en software gobernado, no como casillas que haya que tachar en orden estricto.»
— Soberanía de la Intención, p. 19
La Fase 0: cimientos y preparación del entorno agéntico
Una empresa que viene del desarrollo clásico no puede saltar de golpe a delegar la ejecución en agentes. La Fase 0 levanta el entorno agéntico, auditado y bajo control, antes de que ningún agente toque una línea de código.
Empieza con el Diagnóstico de Madurez y Auditoría del SDLC Existente: se mide la fricción actual, se calcula el Agential Legibility Score (ALS) del código y se consolida un Readiness Score (por debajo de 65 puntos puede inhabilitar el inicio) que desemboca en una decisión de Go/No-Go.
Sigue la constitución del AI Governance Board (AIGB) —con el Chief Intent Arbiter, el Security Sentinel y el Business Owner, y sus Sesiones de Sintonía de 30 minutos—, la Matriz de Umbrales de Confianza (Trust Thresholds) con sus tres niveles de autonomía y las Rules of Engagement (RoE): exfiltración prohibida, privilegio cero, alucinación cero y transparencia de razonamiento.
Después se codifica el ADN Arquitectónico en system prompts y se construye el Master Architecture Prompt (MAP), versionado como código fuente (PromptOps). Los talleres de captura de visión estratégica definen el MVI (Minimum Viable Intent), el lenguaje ubicuo inspirado en DDD y los Legacy Anchors, y culminan en la EIS Maestra, que un agente actuando como «abogado del diablo» tecnológico pone en jaque antes del primer sprint, estimando esfuerzo de tokens, riesgos y conflictos lógicos.
Cierra la fase la fábrica: el pipeline CI/CD con el Agente Guardián como gateway único, y el fuerte de Railguards y whitelists: proxy de comandos, gobernanza de dependencias, Financial Guard con alertas de tres niveles, bóveda de secretos y Shadow Sandbox. El capítulo 2 del libro detalla cada paso.
«Esta fase es la clave para mantener la “SOBERANÍA DE LA INTENCIÓN”»
— Soberanía de la Intención, p. 34
El ciclo de ejecución semanal (sprint)
| Lunes | Martes | Miércoles | Jueves | Viernes | |
|---|---|---|---|---|---|
| Mañana | Fase 1 Ingesta Crítica y Protocolo de Interrogación AM | Fase 3 Aceleración de Entorno y Pre-vuelo Técnico Día completo ✍ | Fase 4 Construcción PM (martes) y día completo (miércoles) | Fase 5 Auditoría de Salud Técnica y Despliegue en Pre con Certificación de Seguridad Día completo ✍ | Fase 6 Validación de Valor (UAT) y Refactorización Flash AM ✍ |
| Tarde | Fase 2 Certificación del EIS y Alineación de Negocio PM ✍ | Fase 7 Release, Merge y Retrospectiva del Sprint PM |
firma humana obligatoria La Fase 4 (Construcción) arranca el martes por la tarde y ocupa el miércoles.
El sprint de Designio dura una semana porque el cuello de botella ya no es construir: son las tareas humanas que rodean a la construcción. Siete fases lo recorren de lunes a viernes.
El lunes (AM), la Ingesta Crítica y Protocolo de Interrogación (AI-Refiner): el agente interrogador confronta los requisitos del Business Owner contra su ambigüedad hasta dejar un margen residual de en torno al 5%. El lunes (PM), la Certificación del EIS y Alineación de Negocio: el Delivery Lead y el Intent Director firman ✍ las EIS —nada pasa a construcción sin esa firma— y se definen los puntos de control de soberanía en los que la IA debe detenerse y pedir permiso.
El martes, la Aceleración de Entorno y Pre-vuelo Técnico: si hay re-arquitecturación, el Shadow Architect genera varias propuestas de ADRs y el Arquitecto humano firma ✍ la elegida, que se vuelve referencia inmutable del sprint. Del martes (PM) al miércoles, la Construcción: el Agente Constructor diseña los tests antes que el código (cobertura superior al 90%) mientras el Delivery Lead realiza pruebas de intención en caliente.
El jueves, la Auditoría de Salud Técnica: el Security Sentinel y el Sandbox de Validación de Fidelidad alimentan un Health Score que debe alcanzar 98, el Arquitecto firma ✍ la certificación de salud y el código se despliega en PRE con el UAT agéntico pasado al 100%. El viernes (AM), la Validación de Valor (UAT): QA y Business Owner validan, se distingue Error de Intención de Evolutivo de Último Minuto, y el BO firma ✍ el cierre de la EIS. El viernes (PM), Release, Merge y Retrospectiva: producción, Traceability Log sellado y un sistema que aprende solo para el lunes siguiente. El capítulo 3 del libro recorre cada hora de esta semana.
«En todos esos casos, el patrón es el mismo: la IA puede proponer, pero quien decide es el humano, porque son cambios cuyo coste de equivocarse es demasiado alto para delegarlo.»
— Soberanía de la Intención, p. 87
El ecosistema técnico de Designio
La metodología necesita una capa técnica que garantice que la IA construye en un entorno limpio, sin residuos de sprints anteriores ni configuraciones ocultas. El capítulo 4 la describe capa a capa.
Los agentes construyen en micro-VMs aisladas en la nube, con imágenes distroless, política TTL de destrucción al terminar y Zero Data Residue: no queda rastro físico del código del cliente. La red se gobierna con un egress proxy con inspección profunda de paquetes (DPI) y lista blanca generada al inicio del sprint. El contexto llega por RAG sobre una base de datos vectorial que indexa código, OpenAPI, esquemas y ADRs históricos, porque el contexto largo «no es selectivo y se dispersa».
Cada agente actúa con una identidad sintética y tokens JWT de vida corta y permisos mínimos; los secretos viven en la bóveda del cliente y el agente solo ve referencias opacas. La trazabilidad se sella en un log WORM con hashing encadenado tipo Merkle Tree. La observabilidad agéntica añade tres métricas propias —Token Burn Rate, Reasoning Path Depth y Self-Correction Rate— y kill switches configurables.
El pipeline incorpora la revisión cruzada: un segundo agente de una familia de modelos distinta busca errores lógicos, desviaciones de estándares y sesgos del modelo principal. La orquestación multi-agente combina bus de mensajes, el Agente Guardián como mediador, arquitectura blackboard y, opcionalmente, un Agente Orquestador que reparte bundles de EIS. Todo se endurece antes de operar: pruebas de estrés, pentesting de prompt injection y firma de la línea base. El capítulo cierra con una especificación operativa pensada para que un agente la convierta en infraestructura real.
«Lo nuevo en Designio es que también hay que monitorizar el razonamiento de la IA, no solo el rendimiento de la máquina.»
— Soberanía de la Intención, p. 123
Requisitos de infraestructura del cliente y checklist de readiness
Cuando un cliente adopta Designio, no basta con firmar el contrato: hay cosas que debe tener en orden en su propia infraestructura antes del primer sprint. El autor lo escribe desde la experiencia: los proyectos con la infraestructura preparada arrancaban en una semana; los demás se retrasaban entre tres y cinco.
El cliente aporta los canales de comunicación (un buzón dedicado, Slack o Teams, o su herramienta ALM como Jira) por los que el agente interrogador recibe las intenciones; una identidad sintética en su Git, el Machine User, con permisos mínimos, llaves rotadas cada 30 días y commits firmados; una Landing Zone aislada en su cloud, gestionada íntegramente con Infraestructura como Código; acceso a su bóveda de secretos sin credenciales estáticas; y la telemetría de retorno para que el agente vea cómo se comporta el código en producción.
Antes del primer sprint se ejecuta el checklist de readiness, con cuatro bloques. Bloque 1: Pruebas de humo de conectividad (bóveda, handshake de Git, proxy de comandos, telemetría: nada «concedido» se asume «operativo»). Bloque 2: Auditoría de la línea base semántica: el agente debe describir la arquitectura del cliente con fidelidad superior al 95% y el Security Sentinel identificar el 100% de las infracciones de estándares. Bloque 3: Gobernanza y firmas: protocolo de delegación, Financial Guard y plan de contingencia. Bloque 4: Sprint cero (Dry Run): una tarea trivial que recorre todas las fases de la metodología. El capítulo 5 del libro detalla cada requisito.
«El cumplimiento del 100% de este checklist es obligatorio para proceder al primer sprint real. No se aceptan excepciones parciales, porque cualquier hueco en el readiness compromete la autonomía de los agentes y la integridad del código que vayan a generar.»
— Soberanía de la Intención, p. 145
Jerarquía de inteligencia y protocolo de fallback multimodelo
No se puede depender de un solo modelo de un solo proveedor: si se cae, se degrada o dispara la factura, el sprint se detiene. Designio organiza los modelos en una jerarquía de tres niveles: el modelo principal, el más capaz para razonamiento denso; un modelo de un proveedor distinto —y conviene que sea de otra familia—; y la opción de modelos locales en infraestructura del cliente, con sentido para privacidad, cumplimiento normativo, coste y resiliencia.
Se conmuta cuando el principal deja de responder, su latencia se degrada, empieza a fallar tests que antes pasaba o el consumo proyectado se dispara. Y conmutar no es solo cambiar de endpoint: hay que adaptar el formato de la instrucción al estilo del modelo de destino, transferir el estado del trabajo (qué está construido y validado, dónde se atascó el anterior) y aprovechar las fortalezas del nuevo modelo.
El capítulo recoge además una observación que va contra la intuición: cada vez funciona mejor que un bug lo arregle un modelo distinto del que escribió el código, porque el modelo nuevo llega sin la mochila de sus propios intentos fallidos; para depurar, los ojos frescos ganan. Cuando ni eso basta, queda el rollback de intención: volver al último estado sano del proyecto y reconstruir desde la intención original de la EIS, sin heredar nada de la cadena de parches. Y al retornar al modelo principal, este homogeneiza lo escrito durante la contingencia para que el activo quede coherente, como si lo hubiera escrito una sola mano.
«Este capítulo trata justamente de qué hacer cuando el modelo falla, porque va a fallar, y la diferencia entre un sistema serio y uno de juguete es tener previsto el plan B.»
— Soberanía de la Intención, p. 147
El núcleo irreductible: qué hace falta para poder decir que esto es Designio
Hacer cosas con IA no es aplicar Designio. El libro deja claro cuál es el mínimo innegociable, el umbral por debajo del cual ya no se puede usar el nombre de la metodología con propiedad. Para que un proyecto esté gobernado de verdad por Designio tienen que existir, sí o sí, cinco cosas:
Una intención escrita y ejecutable que precede al código. Sin una EIS que capture y certifique la intención antes de empezar, no hay metodología.
Una trazabilidad completa e inmutable. Cada acción del sistema, cada decisión, cada cambio, registrado de forma inalterable. Sin trazabilidad no hay gobierno, hay caja negra.
Un agente que gobierna y un control de seguridad que audita. Una figura que orquesta y controla (el Agente Guardián) y un control que valida antes de desplegar (el Security Sentinel). Sin esto, hay agentes trabajando, pero no hay nadie al mando.
Validación humana de lo que importa. Las decisiones críticas —la intención, la salud técnica, el valor de negocio— las firma un humano. La autonomía llega hasta donde el riesgo lo permite.
Un control del gasto y del comportamiento. Saber cuánto se consume, detectar cuándo un agente se descontrola, y poder cortar.
Todo lo demás —proveedor cloud, modelo, herramientas— es negociable y se adapta a cada cliente. Pero esos cinco elementos son la columna vertebral: si falta uno, se podrá estar haciendo un trabajo excelente con IA, pero no será Designio. El capítulo 7 explica por qué esta distinción separa un proceso soberano de un experimento que funciona hasta el día que falla.
«Si se construye sin una EIS que capture y certifique la intención antes de empezar, no es Designio; es generación de código asistida, que es otra cosa.»
— Soberanía de la Intención, p. 155
El dividendo de la intención
El capítulo final explica por qué la Soberanía de la Intención es, además de una forma mejor de construir software, el mejor negocio de la década. Y empieza por nombrar el problema: el «Impuesto a la Ambigüedad», lo que paga toda organización que construye sin haber entendido del todo qué quería construir. El sector lo lleva décadas midiendo: rehacer requisitos, diseño y código defectuosos consume típicamente entre el 40 y el 50 por ciento del coste total de un desarrollo, y la mayor parte de ese retrabajo se rastrea hasta requisitos mal definidos. Designio ataca la causa en su origen: toda la maquinaria de captura de la intención existe para bajar ese impuesto antes de que se devengue.
La segunda fuente de rentabilidad es el paso de Tokenomics vs. Headcount: el coste del software deja de ser función del número de personas y pasa a serlo del número de tokens. Cuatro vías lo explican: la paralelización de los agentes constructores, el Arquitecto humano a tiempo parcial, el Delivery Lead liberado del seguimiento de personas y un equipo de QA que recibe el código con la cobertura ya hecha. Sumadas, la reducción de coste puede llegar a un orden de magnitud, y el autor es honesto con las advertencias: la cifra es una estimación razonada, y cuando los tokens dejen de estar subvencionados la ratio bajará, pero seguirá siendo mucho más barato.
El dividendo de fondo no es el ahorro: es que la ventaja competitiva se desplaza del código a la intención. Quien mejor defina su intención dominará el mercado.
«Ya no gana quien más código escribe, sino quien mejor sabe lo que quiere y mejor lo sabe expresar.»
— Soberanía de la Intención, p. 169