SDD vs Context Engineering: cuándo usar cada uno (y cuándo usarlos juntos)

Este artículo cierra una serie de tres. Los anteriores cubren qué es Spec Driven Development y qué es Context Engineering. Si llegas aquí sin leerlos, la comparación que sigue va a ser menos útil.

Si ya los has leído, la pregunta que probablemente tienes es: ¿cuándo uso uno, cuándo uso el otro, y qué pasa cuando los combino? Aquí va la respuesta.

La diferencia de fondo #

SDD y Context Engineering no operan en la misma capa.

Spec Driven Development responde a la pregunta: ¿qué debe construirse y bajo qué reglas? Su activo central es la especificación. Su objetivo es estabilizar la intención antes de que empiece la ejecución.

Context Engineering responde a la pregunta: ¿qué necesita ver el agente para actuar bien? Su activo central es el paquete de contexto. Su objetivo es estabilizar el entorno cognitivo del agente en el momento de ejecutar.

En otras palabras: SDD decide cuál es la fuente de verdad. Context Engineering decide qué señales recibe el agente para no perderse al actuar sobre esa fuente de verdad.

Son preguntas distintas. La respuesta a una no reemplaza a la otra.

El artículo de GitHub sobre Spec Kit no presenta ambas ideas como alternativas excluyentes. Anticipa expresamente que las prácticas de spec-driven development se combinarán con context engineering para construir capacidades más avanzadas. Es una relación de complemento, no de competencia.

Tabla comparativa #

El ejemplo práctico: añadir JWT a una API REST #

El mismo problema abordado desde las dos capas. No para elegir una, sino para ver qué aporta cada una.

Con SDD: definir antes de implementar #

Siguiendo el ciclo de cuatro fases de Spec Kit:

Fase 1 — Specify

Feature: JWT Authentication
Sistema: REST API (Node.js + Express)
Constraints:
  - Tokens stateless, expiran en 24 h
  - No almacenar contraseñas en texto plano; usar bcrypt
  - Rate limiting en el endpoint de login (máx. 5 intentos/min)
  - httpOnly cookie para el token de refresco
Rules:
  - Toda ruta protegida debe validar el token antes de ejecutarse
  - El token de acceso no debe contener datos sensibles

Fase 2 — Plan

Routes:
  POST /auth/login     -> AuthController.login
  POST /auth/refresh   -> AuthController.refresh
  POST /auth/logout    -> AuthController.logout
Components:
  AuthController, TokenService, UserRepository
Storage:
  refresh_token en httpOnly cookie
  access_token en memoria del cliente

Fase 3 — Tasks

Task 1: UserRepository — persistencia y hash de contraseñas
Task 2: TokenService — generación y validación de JWT
Task 3: AuthController — lógica de endpoints
Task 4: Middleware de autorización para rutas protegidas
Task 5: Rate limiter en POST /auth/login

Fase 4 — Implement: el agente genera cada tarea usando la spec y el plan como guardrails. Se revisa tras cada tarea, no al final del bloque completo.

El valor de SDD aquí es que antes de pedir una sola línea de código, se han fijado las restricciones de seguridad, la arquitectura y el orden de trabajo. El agente opera con guardrails. Los checkpoints humanos son sobre tareas acotadas, no sobre miles de líneas.

Con Context Engineering: preparar el contexto antes de pedir #

No se parte de una spec formal. Lo que se prepara deliberadamente es el paquete de señales que va a recibir el agente.

Ese paquete incluye:

• la estructura actual de rutas del repositorio,
• ejemplos del middleware existente (el patrón que ya usa el equipo),
• el ADR o docs/security.md con restricciones de seguridad documentadas,
• los tests de integración que ya existen como referencia,
• el issue abierto con el comportamiento esperado,
• y los últimos logs o resultados de tests fallidos si los hay.

El encargo al agente quedaría así:

Añade autenticación JWT a la API. Antes de editar nada, revisa /routes,
/middleware, /tests/auth y docs/security.md. Sigue el patrón actual de
Express, mantén compatibilidad con la convención de respuestas del proyecto,
y valida con la suite de autenticación existente. Si falta información,
prioriza las restricciones documentadas en docs/security.md sobre los
ejemplos más antiguos del código.

El valor de Context Engineering aquí es que el agente recibe las señales correctas para actuar sobre un sistema vivo. No improvisa desde cero; se ancla en el estado real del repositorio.

Qué pasa cuando se combinan #

La spec formal del enfoque SDD se convierte en parte del paquete de contexto. El agente no solo recibe la spec, sino también los tests existentes, el ADR de seguridad y los ejemplos de middleware. Cada fase del ciclo SDD se ejecuta con el contexto operativo relevante ya preparado.

No es redundante. Son las dos capas trabajando juntas: la especificación gobierna la intención, el contexto operativo gobierna la ejecución.

Qué proyectos encajan mejor con cada enfoque #

Proyectos donde SDD aporta más #

El GitHub Blog documenta tres escenarios donde SDD resulta especialmente efectivo:

Proyectos desde cero: una spec inicial evita que el agente construya genérico sin considerar las restricciones reales. Sin spec, el agente hace lo que cree que probablemente quieres; con spec, hace lo que le dijiste.

Trabajo incremental sobre sistemas con arquitectura clara: la spec fuerza claridad sobre cómo encaja la nueva funcionalidad.

Modernización de legado: captura la lógica de negocio esencial antes de reimplementar, sin arrastrar deuda técnica accidental.

Entornos con equipos grandes o múltiples repositorios: la especificación como fuente de verdad mejora la consistencia entre equipos.

Proyectos donde Context Engineering aporta más valor inmediato #

• Repositorios grandes con documentación dispersa: el principal problema es seleccionar qué información debe ver el agente, no escribir una spec formal desde cero.
• Feature work sobre código vivo: hay más valor en anclar al agente en el estado real del repositorio que en construir documentación previa.
• Equipos con conocimiento implícito: convenciones, patrones y decisiones que viven en el código más que en documentos.
• Agentes multi-paso: flujos donde el agente necesita herramientas, memoria y validación intermedia, y donde las rutas predefinidas de SDD no son lo suficientemente flexibles.

Los límites de cada capa #

SDD no evita por sí solo que el agente falle si el contexto operativo es pobre. Una spec perfecta en un repositorio con convenciones implícitas, sin ejemplos representativos y con documentación dispersa no garantiza buen resultado. El problema, en ese caso, no está en la spec.

Context Engineering no sustituye la claridad de una buena especificación cuando hay restricciones fuertes, decisiones arquitectónicas importantes o necesidad de validación explícita. Un contexto rico pero sin intención clara puede producir código técnicamente correcto que resuelve el problema equivocado.

Anthropic lo articula bien en Building effective agents cuando distingue entre workflows (rutas predefinidas con checkpoints claros) y agents (sistemas donde el modelo dirige dinámicamente el proceso y el uso de herramientas). SDD encaja mejor con el primer patrón. Context Engineering se vuelve crítico en el segundo. Esa distinción de taxonomía ayuda a entender cuándo aplicar cada capa.

El veredicto #

No hay un ganador. Hay dos capas que resuelven problemas distintos.

La especificación gobierna la intención. El contexto gobierna la ejecución. Un sistema con IA que funciona bien en proyectos serios necesita los dos.

La pregunta útil no es “¿uso SDD o Context Engineering?”. La pregunta útil es:

• ¿Tengo la intención suficientemente clara para convertirla en una spec formal?
• ¿Tengo el contexto operativo preparado para que el agente ejecute bien?

Si la respuesta a la primera es sí, empieza por SDD y construye el contexto encima. Si aplica la segunda pero no la primera, empieza por el contexto. Si ninguna de las dos, el problema no es qué herramienta elegir: es que todavía no tienes claro qué quieres construir. Y para eso no hay metodología que ayude.

Fuentes: GitHub Blog — Spec Kit, Azure Verified Modules — SDD, Anthropic Engineering — Building effective agents, Simon Willison — Context engineering, Wikipedia — Spec-driven development, Leigh Griffin & Ray Carroll — Spec Driven Development (InfoQ)