ATLAS + GOTCHA -- Parte 9
ATLAS + GOTCHA vs Spec-Driven Development: Qué tienen en común y en qué se diferencian
El Problema
Has seguido esta serie. Conoces ATLAS (5 fases de pensamiento estructurado) y GOTCHA (6 capas de instrucciones para la IA). Los has usado para construir APIs, pipelines e infraestructura. Funcionan.
Entonces abres Twitter y ves: “Spec-Driven Development es el futuro.” Thoughtworks lo pone en el radar. GitHub lanza spec-kit. Amazon lanza Kiro. Martin Fowler escribe sobre ello. Todos los blogs de AI coding hablan de specs.
Y te preguntas: ¿es esto lo mismo que yo he estado haciendo? ¿ATLAS + GOTCHA ya es SDD? ¿Debería cambiar? ¿Son complementarios? ¿Qué hay realmente de nuevo aquí?
Este artículo responde a esas preguntas con honestidad. Nada de “nuestro framework es mejor.” Nada de “SDD es solo hype.” Una comparación real: qué ADN comparten, qué es genuinamente diferente y cuándo usar cada enfoque.
Qué es SDD realmente
Spec-Driven Development invierte el flujo de trabajo tradicional. En lugar de escribir código y documentarlo después, escribes la especificación primero y usas IA para generar el código a partir de ella. La spec es el activo. El código es la salida.
La definición de Thoughtworks: “Un paradigma de desarrollo que usa especificaciones de requisitos de software bien elaboradas como prompts, con la ayuda de agentes de IA, para generar código ejecutable.”
La mayoría de las implementaciones de SDD siguen tres etapas:
- Specify — Escribe lo que el sistema debe hacer. User stories, criterios de aceptación, requisitos no funcionales. Foco en el QUÉ, no en el CÓMO.
- Plan — Genera un plan de implementación técnica a partir de la spec. Arquitectura, modelos de datos, contratos API, desglose de tareas.
- Execute — La IA genera código a partir del plan. Tests primero, luego implementación.
Herramientas como GitHub spec-kit aportan estructura: un archivo spec.md con user stories, un plan.md con arquitectura, un tasks.md con tareas ordenadas. Amazon Kiro lo integra en el IDE: requirements, design, tasks, cada uno como documento markdown.
El ADN compartido
ATLAS + GOTCHA y SDD coinciden en lo fundamental. No es casualidad. Ambos frameworks existen porque el mismo problema era obvio para todos los que trabajaban con IA en producción.
1. Piensa antes de hacer prompt
Ambos frameworks dicen: no abras la herramienta de IA y escribas “constrúyeme un servicio de usuarios.” Piensa primero. Estructura tu pensamiento. Escríbelo.
En ATLAS, esto es el checklist de 5 fases: Architect → Trace → Link → Assemble → Stress-test.
En SDD, esto es la etapa Specify: user stories, criterios de aceptación, requisitos no funcionales.
Mismo principio. Diferente vocabulario. Ambos existen porque los prompts vagos producen código vago.
2. La spec es el activo, no el código
ATLAS + GOTCHA dice: guarda tus prompts GOTCHA en el repositorio. Actualízalos cuando cambien los requisitos. El prompt es la documentación (artículo 7, anti-gotcha #7).
SDD dice: la especificación es el artefacto principal. El código se genera a partir de ella y puede regenerarse.
La misma idea. Si pierdes el código, puedes regenerarlo desde la spec. Si pierdes la spec, empiezas de cero.
3. Formato estructurado en lugar de texto libre
GOTCHA usa 6 capas explícitas: Goals, Orchestration, Tools, Context, Heuristics, Args. Cada capa responde a una pregunta diferente. No las mezclas.
GitHub spec-kit usa archivos estructurados: spec.md (qué y por qué), plan.md (cómo), tasks.md (en qué orden). Cada archivo tiene una plantilla con secciones.
Ambos rechazan la idea de un prompt de un solo párrafo. Ambos separan las preocupaciones en secciones distintas con propósitos claros.
4. El humano decide, la IA ejecuta
Ambos frameworks mantienen al humano en el bucle. En ATLAS + GOTCHA, el humano rellena el checklist ATLAS y escribe el prompt GOTCHA. La IA genera código a partir de él. El humano revisa y ajusta (artículo 5, “What the AI Got Right and What We Adjusted”).
En SDD, el humano escribe la spec, revisa el plan y valida el código generado. La IA propone, el humano decide.
Ningún framework es “IA autónoma programando.” Ambos son colaboración estructurada.
El Mapeo
Así es como se corresponden las piezas:
| ATLAS + GOTCHA | SDD (spec-kit) | Qué hace |
|---|---|---|
| Architect (ATLAS) | spec.md — overview, user stories | Definir qué construir y los límites |
| Trace (ATLAS) | plan.md — flujo de datos, arquitectura | Mapear cómo se mueven los datos por el sistema |
| Link (ATLAS) | plan.md — contratos, modelos de datos | Definir integraciones e interfaces |
| Assemble (ATLAS) | tasks.md — lista de tareas ordenada | Decidir el orden de construcción |
| Stress-test (ATLAS) | spec.md — criterios de aceptación | Definir cómo validar |
| Goals (GOTCHA) | spec.md — user stories | Lo que la IA debe lograr |
| Orchestration (GOTCHA) | tasks.md — orden de tareas | Secuencia de trabajo |
| Tools (GOTCHA) | plan.md — tech stack | Frameworks y librerías |
| Context (GOTCHA) | Constitution / steering | Reglas de proyecto y entorno |
| Heuristics (GOTCHA) | Constitution — articles | Reglas DO/DON’T para la IA |
| Args (GOTCHA) | plan.md — config, env vars | Valores concretos y parámetros |
El mapeo no es 1:1. Los límites no encajan perfectamente. Pero cada pieza de información que ATLAS + GOTCHA captura tiene un lugar en SDD, y viceversa.
Las Diferencias Reales
1. Alcance: arquitectura vs. funcionalidades
ATLAS + GOTCHA empieza desde la arquitectura. La primera pregunta es “¿cuáles son los límites de este sistema?” El framework está diseñado para arquitectos que piensan en servicios, integraciones, flujos de datos y modos de fallo.
SDD empieza desde las funcionalidades. La primera pregunta es “¿qué necesita el usuario?” El framework está diseñado para equipos de producto que piensan en user stories, criterios de aceptación y valor de negocio.
Esta es la mayor diferencia. ATLAS pregunta “¿cómo funciona el sistema?” SDD pregunta “¿qué debería hacer el sistema?”
Ambos son puntos de partida válidos. Pero llevan a prompts diferentes. Un prompt ATLAS + GOTCHA para un servicio de notificaciones empieza con la arquitectura: “Event-driven .NET worker, Service Bus, 3 canales, circuit breaker en fallo de proveedor.” Una spec SDD empieza con el usuario: “Como cliente, quiero recibir un email cuando mi pedido sea confirmado.”
En la práctica, necesitas ambos. La user story te dice qué construir. La arquitectura te dice cómo construirlo para que sobreviva en producción.
2. Herramientas: framework vs. ecosistema
ATLAS + GOTCHA es un framework — una forma de pensar. Funciona con cualquier herramienta de IA. Puedes usarlo con Claude, GPT-5, Mistral, Copilot, Cursor o un archivo de texto plano. No hay CLI, no hay extensión de VS Code, no hay formato de archivo específico. La plantilla es un documento markdown que rellenas.
SDD se ha convertido en un ecosistema. GitHub lanza spec-kit con slash commands (/speckit.specify, /speckit.plan, /speckit.tasks). Amazon construyó Kiro como un IDE dedicado. OpenSpec es un framework open-source con soporte para más de 20 asistentes de código. Cada herramienta tiene su propio flujo, su propio formato de archivo, sus propias convenciones.
La ventaja de las herramientas: automatización. Spec-kit genera la estructura de archivos, aplica plantillas y conecta etapas automáticamente. No necesitas recordar el formato — la herramienta se encarga.
La ventaja de no tener herramientas: portabilidad. ATLAS + GOTCHA funciona en todas partes, con todo. Sin vendor lock-in. Sin herramientas que instalar. El conocimiento está en tu cabeza, no en un CLI.
3. El concepto de Constitution
SDD (concretamente spec-kit) introduce la idea de una constitution — un conjunto de principios inmutables que la IA debe seguir siempre. Cosas como “siempre prefiere librerías antes que código custom” o “toda funcionalidad debe estar expuesta a través de CLI” o “nada de implementación sin tests.”
ATLAS + GOTCHA tiene Heuristics — las reglas DO/DON’T. Pero las Heuristics son por prompt, no a nivel de proyecto. Las escribes para cada tarea.
La constitution es una buena idea. Son Heuristics a nivel de proyecto que aplican a cada prompt, cada tarea, cada archivo generado. En términos de ATLAS + GOTCHA, podrías crear un “project GOTCHA” con las Heuristics y el Context que nunca cambian, e incluirlo en cada GOTCHA de tarea.
Si ya usas ATLAS + GOTCHA, añadir una constitution a nivel de proyecto es fácil. Crea un GOTCHA-PROJECT.md con tu Context y Heuristics permanentes. Inclúyelo por referencia en cada prompt de tarea. Eso es básicamente lo que hace una constitution.
4. Filosofía de regeneración
SDD, especialmente en el nivel “spec-as-source”, trata el código como totalmente regenerable. Cambia la spec, regenera el código. La spec es la fuente de verdad, el código es la salida del build — como un binario compilado.
ATLAS + GOTCHA no llega tan lejos. El prompt GOTCHA genera un primer borrador que el humano revisa y ajusta. Esos ajustes viven en el código, no en el prompt. Con el tiempo, el código diverge del prompt a medida que el humano lo mejora.
La filosofía de regeneración de SDD funciona bien para proyectos greenfield donde la spec está completa. Funciona peor para sistemas brownfield donde el código ha acumulado años de manejo de casos límite que ninguna spec captura.
5. Tres niveles de rigor
SDD define tres niveles:
- Spec-first — Escribe la spec, luego codifica siguiéndola (como TDD pero para requisitos)
- Spec-anchored — Spec y código co-evolucionan, pero la spec sigue siendo la referencia
- Spec-as-source — La spec ES el código fuente. Regenera todo a partir de ella.
ATLAS + GOTCHA no define niveles. Siempre es el mismo proceso: piensa (ATLAS), haz prompt (GOTCHA), revisa, ajusta. El rigor depende de la tarea — una funcionalidad pequeña recibe un GOTCHA ligero, un nuevo servicio recibe el checklist ATLAS completo.
Los niveles de SDD son útiles para la adopción organizacional. “Somos spec-first para funcionalidades nuevas, spec-anchored para servicios existentes.” Le da a los equipos un vocabulario para su madurez de proceso.
Cuándo Usar Cada Uno
| Situación | ATLAS + GOTCHA | SDD |
|---|---|---|
| Diseñar un sistema nuevo desde cero | Mejor — pensamiento architecture-first | Bien — feature-first, añade arquitectura en la fase plan |
| Añadir una funcionalidad a un sistema existente | Bien — rellena Context del sistema actual | Mejor — la spec encaja de forma natural en el flujo de producto |
| Tareas de infraestructura / DevOps | Mejor — la serie cubre Terraform, pipelines, K8s | Sin probar — SDD es sobre todo para código de aplicación |
| Equipo con herramientas de IA variadas | Mejor — funciona con todo, sin herramientas requeridas | Limitado — spec-kit es específico de GitHub, Kiro de Amazon |
| Equipo adoptando IA por primera vez | Bien — modelo mental simple, imprime y usa | Mejor — las herramientas guían el proceso paso a paso |
| Entorno regulado (audit trail) | Bien — prompts GOTCHA en el repo | Mejor — las specs son documentos formales, fáciles de auditar |
| Desarrollador en solitario | Mejor — ligero, sin overhead | Excesivo — el flujo de spec-kit está diseñado para equipos |
La respuesta honesta: no compiten. Resuelven el mismo problema desde ángulos diferentes. ATLAS + GOTCHA es un framework de pensamiento que produce prompts. SDD es un flujo de desarrollo que produce especificaciones. Ambos transforman intenciones vagas en instrucciones estructuradas para la IA.
Usarlos Juntos
Esta es la combinación que funciona:
-
Usa la etapa Specify de SDD con ATLAS — Escribe user stories (SDD), luego pásalas por el checklist ATLAS para añadir arquitectura, flujos de datos, integraciones y modos de fallo. La spec acierta con el “qué.” ATLAS añade el “cómo” y el “qué pasa si.”
-
Usa GOTCHA como formato del plan — En lugar de un
plan.mden texto libre, estructura el plan como un prompt GOTCHA. Goals de la spec. Orchestration del ATLAS Assemble. Tools del ATLAS Link. Context de la constitution del proyecto. Heuristics de la constitution + reglas específicas de la tarea. Args del ATLAS Stress-test. -
Usa el desglose de tareas de SDD para la ejecución — Después del prompt GOTCHA, divídelo en tareas ordenadas (el
tasks.mdde SDD). Cada tarea referencia la sección GOTCHA relevante. La IA ejecuta una tarea a la vez, en orden. -
Usa la constitution para el GOTCHA de proyecto — Crea un
GOTCHA-PROJECT.mdcon tus Heuristics y Context permanentes. Cada GOTCHA de tarea lo incluye por referencia.
El resultado: el flujo orientado a producto de SDD + el rigor arquitectónico de ATLAS + el formato de prompt estructurado de GOTCHA. Cada framework aporta lo que hace mejor.
User story (SDD Specify)
↓
ATLAS checklist (Architect → Trace → Link → Assemble → Stress-test)
↓
GOTCHA prompt (Goals → Orchestration → Tools → Context → Heuristics → Args)
+ Project Constitution (permanent Context + Heuristics)
↓
Task breakdown (SDD Tasks)
↓
AI generates code per task
↓
Human reviews and adjustsPlantilla: El Flujo Combinado
=== STEP 1: SPECIFY (SDD) ===
User story: As a [role], I want [capability] so that [benefit].
Acceptance criteria:
- GIVEN [context] WHEN [action] THEN [result]
- ...
Non-functional: [performance, security, compliance]
Out of scope: [what we're NOT building]
=== STEP 2: ATLAS (Architecture) ===
[A] ARCHITECT: boundaries, constraints, tech decisions
[T] TRACE: data flow from trigger to response
[L] LINK: integrations, protocols, failure modes
[A] ASSEMBLE: build order, patterns, quality rules
[S] STRESS-TEST: load, failure, security scenarios
=== STEP 3: GOTCHA (AI Prompt) ===
GOALS: (from user story + Architect)
ORCHESTRATION: (from Trace + Assemble)
TOOLS: (from Link)
CONTEXT: (from Link + project constitution)
HEURISTICS: (from Assemble + project constitution)
ARGS: (from Stress-test)
=== STEP 4: TASKS (SDD) ===
1. [task derived from GOTCHA Orchestration]
2. [task]
3. [task]
...Lo Que Aprendí
Escribir esta comparación me enseñó algo que no esperaba: ATLAS + GOTCHA ya estaba haciendo spec-driven development antes de que el término existiera. El prompt GOTCHA ES una especificación. El checklist ATLAS ES la fase de diseño. La sección “What We Adjusted” en los artículos 5 y 6 ES el paso de revisión.
La diferencia es que SDD le dio nombre a estas prácticas, construyó herramientas alrededor de ellas y consiguió que la industria convergiera en un vocabulario compartido. Eso importa. Una práctica sin nombre es más difícil de adoptar, más difícil de enseñar y más difícil de evolucionar.
ATLAS + GOTCHA aporta algo que SDD aún no tiene: pensamiento architecture-first. La mayoría de herramientas SDD empiezan desde funcionalidades y dejan que la arquitectura emerja en la fase de plan. ATLAS te obliga a pensar en flujos de datos, integraciones y modos de fallo antes de escribir una sola user story. Para sistemas enterprise — del tipo que yo construyo cada día — ese pensamiento arquitectónico es la diferencia entre un sistema que funciona en una demo y uno que funciona en producción.
¿El mejor enfoque? Usa ambos. Empieza con una user story (SDD). Pásala por ATLAS (arquitectura). Formatea el resultado como GOTCHA (prompt). Divídelo en tareas (SDD). Deja que la IA genere. Revisa y ajusta.
Pensamiento estructurado + prompts estructurados + ejecución estructurada. Eso es lo que funciona.
Una Nota de Precaución
La IA multiplica tu velocidad escribiendo código. Eso es real. Lo que antes tardaba un día ahora tarda una hora. Pero velocidad sin dirección es solo caos más rápido.
La fase de planificación — ATLAS, SDD Specify, como quieras llamarla — no es un overhead opcional. Es lo que hace que la velocidad sea útil. Si te la saltas, acabarás gastando el tiempo que ahorraste arreglando arquitecturas inventadas, revirtiendo suposiciones erróneas y depurando código que resuelve un problema que en realidad no tenías.
Lo he visto pasar. Un desarrollador genera 2.000 líneas de código en 30 minutos. Luego pasa tres días arreglándolo porque la IA adivinó el esquema de base de datos, se inventó un flujo de autenticación que nadie pidió y usó una librería que no existe en el proyecto. Productividad neta: negativa.
Los frameworks de este artículo — ATLAS, GOTCHA, SDD — existen porque la fase de planificación es más importante ahora que antes de la IA. No menos. Cuando escribías 50 líneas por hora, una decisión equivocada te costaba una tarde. Cuando la IA escribe 500 líneas por hora, una decisión equivocada te cuesta una semana de limpieza.
Usa la IA como la herramienta potente que es. Pero sabe exactamente lo que quieres antes de pedirle que lo construya. Los 15 minutos que inviertas pensando te ahorrarán días corrigiendo.
Esto No Es Waterfall
Antes de que alguien lea esto y piense “entonces volvemos al Big Design Up Front” — no. Esto no es waterfall. Nadie está escribiendo documentos de requisitos de 200 páginas ni pasando tres meses en una fase de análisis antes de escribir una línea de código.
ATLAS tarda 15 minutos. Un prompt GOTCHA tarda 10. Una spec SDD para una funcionalidad tarda 30. Eso es una hora de pensamiento estructurado — dentro de un sprint, no antes de él. Sigues iterando. Sigues entregando cada dos semanas. Sigues cambiando de dirección cuando el negocio lo necesita.
La diferencia con el agile clásico es el artefacto. Agile decía “software funcionando por encima de documentación exhaustiva.” Y durante años eso se convirtió en excusa para no documentar nada. Pero esa interpretación siempre fue un error — y ahora es un error fatal. La IA necesita instrucciones claras para generar código útil. Sin documentación, sin specs, sin prompts estructurados, la IA adivina. Y adivina mal.
La documentación es más importante ahora que antes de la IA. No menos. Un prompt GOTCHA no es una spec de 50 páginas. Es un contrato de una página entre tú y la IA — la estructura justa para obtener un resultado útil, nada más. Pero es documentación. Y sin ella, la velocidad de la IA trabaja en tu contra.
¿Quieres ser ágil? Perfecto. Lean funciona: elimina desperdicios, entrega valor, mejora continua. Eso encaja con todo lo que esta serie propone. Pero si usas Scrum, necesitas adaptar la filosofía. El manifiesto ágil se escribió en 2001, cuando los humanos escribían cada línea de código. En 2026, la IA escribe la mayoría del código — y la IA no funciona con post-its y conversaciones de pasillo. Necesita specs escritas, contexto explícito y reglas claras. No es volver a waterfall. Es actualizar lo que “ágil” significa cuando tu compañero de pair programming es una máquina.
Piénsalo así: no le dirías a un desarrollador nuevo “simplemente construye la funcionalidad, ya te apañarás” sin una breve conversación sobre el enfoque. ATLAS + GOTCHA es esa conversación — pero escrita, para que la IA (y tu yo del futuro) puedan consultarla.
Esto no reemplaza la iteración, ni los sprints, ni la entrega continua. Reemplaza el momento en que abres la herramienta de IA y escribes un prompt vago. Ese momento — entre “sé lo que quiero” y “la IA genera código” — es donde viven estos frameworks.
Si esta serie te ayuda, considera invitarme a un café.
Este es el artículo 9 de la serie ATLAS + GOTCHA. Anterior: Tu Hoja de Ruta de 90 Días.
Sources:
Loading comments...