Guiada por especificaciones
Ningún código se escribe sin contrato y criterios previos.
Cómo se verificaTodo cambio referencia una especificación con criterios de aceptación no vacíos.
Hasta un 62% del código generado con IA sin metodología contiene fallos de seguridad (Veracode, 2025). Ironspec AI enseña a usar la IA como ejecutor de contratos verificables, no como autocompletado.
El modelo no recuerda nada entre una sesión y la siguiente. Las metodologías ágiles podían descansar en el conocimiento tácito del equipo —la conversación era el canal—; con un par que no recuerda nada, ese canal no existe.
Ironspec AI invierte la regla: todo lo que sostiene el sistema se externaliza en artefactos durables. La documentación deja de ser burocracia y se vuelve la condición de posibilidad de trabajar con una IA.
La IA implementa el ticket. Funciona, se mergea. Tres semanas después nadie —ni quien lo pidió— entiende cómo está hecho. El conocimiento vivió en el chat y se evaporó.
Sin un mecanismo estándar para entregar contexto, cada sesión arranca de cero: se re-explica la arquitectura, las convenciones, los contratos. El mismo contexto se re-paga una y otra vez.
Sin una forma explícita de definir qué se quiere, la IA llena los huecos con suposiciones. El resultado pasa la demo, pero falla en los bordes o resuelve el problema equivocado.
No optimizamos el arranque, optimizamos la trayectoria. Ironspec AI no compite en el sprint del lunes — compite en el mes 18.
Una metodología propia de ingeniería de software aumentada por IA, derivada de eXtreme Programming y de otras prácticas ágiles: el doble bucle de BDD, la eliminación de desperdicio de Lean, el flujo continuo y los límites de trabajo de Kanban, las compuertas de entrada y salida de Scrum, y el dimensionamiento de alcance de Shape Up.
Su unidad de trabajo es la SPEC-EXEC: un contrato ejecutable por ticket, con un núcleo obligatorio y criterios de aceptación que corre la máquina. La especificación es el artefacto primario — el código es un resultado derivado, no el punto de partida.
No es teoría: así construimos Yggdrasil.
Conozca Yggdrasil →Aprenda construyendo un proyecto real: una plataforma de gestión de proyectos colaborativa en tiempo real (estilo Linear/Jira/Notion). Cada sesión produce un artefacto durable, no un ejercicio.
No son eslóganes: cada una viene con su mecanismo de verificación. Eso es lo que separa una metodología de un conjunto de buenas intenciones.
Ningún código se escribe sin contrato y criterios previos.
Cómo se verificaTodo cambio referencia una especificación con criterios de aceptación no vacíos.
Toda decisión de arquitectura deja rastro.
Cómo se verificaUn registro por decisión, con su contexto y las alternativas descartadas.
El contrato nunca diverge de la implementación.
Cómo se verificaEl contrato se deriva del código; un desajuste falla el CI.
«Funciona» se prueba, no se opina.
Cómo se verificaCriterios corribles + suite obligatoria: unitarias, integración real, tipado estricto.
Cualquier agente retoma cualquier trabajo solo desde los artefactos.
Cómo se verificaLa prueba de arranque en frío: ¿implementa sin preguntar? Si pregunta, falta contrato.
El método se corrige a sí mismo.
Cómo se verificaSi el arranque costó más de cinco preguntas, la tarea no cierra hasta corregir el artefacto que la produjo.
Separarlos es lo que mantiene el método iterativo sin perder el diseño aguas arriba. El razonamiento caro se paga una vez, arriba, donde produce conocimiento reutilizable.
El micro retroalimenta al macro: una tarea bloqueada por una decisión no tomada nace como registro de decisión, y la fricción repetida corrige el artefacto que la produjo. Es un ciclo cerrado, no una cascada.
Cinco pilares, cada uno externalizando una clase distinta de memoria.
Diagramas como código
La memoria visual y estructural del sistema.
Registros de decisión
Por qué la arquitectura es como es, y qué se descartó.
Base de conocimiento fragmentada
El dominio y la arquitectura, cargables por partes.
Contratos de API derivados del código
Las interfaces entre componentes, nunca escritas a mano.
Especificaciones ejecutables
Las unidades de trabajo y su definición de correcto.
La restricción técnica que obliga a un método nuevo
El contrato ejecutable y la prueba de arranque en frío
Del documento de diseño a contratos accionables
Diagramas, decisiones y contratos derivados del código
Criterios que corre la máquina, pruebas reales, CI
Qué carga el modelo al arrancar, y a qué costo
Modelo y esfuerzo decididos tarea por tarea
Tablero, límites de trabajo y mejora continua
USD 600 – 800 por persona
Cotización a medida
según equipo, modalidad y alcance
USD 250 – 350 por persona
Aún no tenemos fecha confirmada para la primera cohorte. Déjenos sus datos y le avisamos apenas la tengamos.
Puede elegir una opción, o ambas — lo que le acomode más.