"Si el spec está bien, el código estará bien. Si el código está mal, primero arregla el spec."
Hay un dato que circula por los pasillos de los equipos que llevan más de un año metiendo agentes de IA en producción y que debería incomodarnos a todos los que vivimos del código seguro:
Entre un 12% y un 65% del código generado por LLMs contiene vulnerabilidades clasificables como CWE. Inyecciones SQL (CWE-89), credenciales hardcodeadas (CWE-798), deserialización insegura (CWE-502), criptografía rota (CWE-327), XSS (CWE-79), buffer overflows (CWE-120/787)... el catálogo completo del OWASP repintado por un modelo entrenado con todo el código mediocre que GitHub ha tragado durante quince años.
Y aun así, seguimos prompteando como si esto fuera un chat de WhatsApp.
Hay una disciplina que está cambiando esto silenciosamente desde finales de 2025. No es nueva — sus raíces están en métodos formales, BDD y diseño API-first — pero por primera vez la infraestructura de IA ha madurado lo suficiente como para que funcione a velocidad de producto. Se llama Spec-Driven Development, y si estás construyendo software con agentes (Claude Code, Cursor, Copilot, Kiro, Codex), conviene entender por qué este es probablemente el cambio metodológico más importante desde TDD
El problema: vibe coding no escala (y la seguridad lo paga primero)
Llamémoslo por su nombre: la mayoría de equipos que usan agentes de IA están haciendo vibe coding. Promptean, reciben output, parchean errores, repiten. Es un bucle que degrada en calidad conforme crece la complejidad del codebase. Produce tres patologías concretas:
1. Drift de intención. El agente produce código plausible que se aleja de lo que realmente querías. No falla los tests unitarios, pero viola patrones arquitectónicos, rompe contratos de API, o introduce anti-patrones de seguridad que solo afloran en producción.
2. Output no verificable. Sin criterios de aceptación explícitos, no hay forma de saber si el código del agente está "bien". Las revisiones se eternizan. El PR de 200 líneas se convierte en un thread de 40 comentarios.
3. Decay arquitectónico. Cada feature nueva se construye sobre suposiciones implícitas que el siguiente prompt no conoce. El sistema se vuelve un Frankenstein. Para febrero de 2026, más de 110.000 issues introducidos por IA habían sobrevivido en repositorios de producción.
El punto crítico para ciberseguridad: los LLMs replican el código vulnerable con el que fueron entrenados. Si pides "una función AES en Python", hay una probabilidad alarmante de que recibas modo ECB con padding de ceros y claves hardcodeadas — porque eso es lo que abunda en StackOverflow. Estudios sobre Copilot reportan ~40% de completions inseguros en escenarios reales.
El problema no es la IA. Es la ausencia de un framework disciplinado para comunicar la intención al agente. Y aquí es donde entra SDD.
Qué es Spec-Driven Development (de verdad)
Definición operativa: SDD es una metodología en la que una especificación ejecutable, versionada en Git, es la única fuente de verdad. El código es un derivado. Si cambian los requisitos, editas el spec y regeneras lo afectado.
Esto suena obvio. No lo es. La diferencia con specs tradicionales es radical:
| Spec tradicional | Spec ejecutable (SDD) |
|---|---|
| La lee un humano | La ejecuta una máquina como gate de validación |
| Documenta intención | Es la intención, autoritativa |
| Se desincroniza del código | El código se regenera desde ella |
| Word/Confluence | Markdown versionado en Git |
| Opcional | Obligatoria — sin spec, no hay código |
La frase que ha hecho fortuna entre los equipos serios es: "el spec es el prompt". Pero un prompt versionado, revisable, con acceptance criteria, constraints técnicos, decisiones arquitectónicas y — esto es clave — restricciones de seguridad explícitas mapeadas a CWEs.
No es TDD. No es BDD. No es waterfall. Es el eslabón que faltaba entre la intención humana y la ejecución por máquina.
Por qué 2026 es el año en que esto explota
Tres fuerzas convergieron:
a) La generación de código por IA escaló — y sus vulnerabilidades también. Si el output del agente es 10x más rápido, los gates de validación tienen que ser ejecutables, no PRs revisados por humanos cansados.
b) Los agentes se volvieron lo bastante buenos como para seguir specs largos. Modelos con context windows grandes y razonamiento extendido pueden procesar specs de 5.000 palabras sin perder coherencia. Hace dos años, esto era impensable.
c) Aparecieron herramientas que formalizan el workflow. GitHub Spec Kit (open source, MIT), AWS Kiro, BMAD-METHOD, OpenSpec, Tessl, Google Antigravity, y harnesses específicos para Claude Code como claude-kiro o cc-sdd. El ecosistema está cubierto.
El caso comercial es brutal: AWS documentó internamente reducciones de features de 40 horas a menos de 8 horas de tiempo humano cuando se autoraban como specs primero. GitHub reporta que con Spec Kit los equipos hacen aproximadamente un orden de magnitud menos ciclos de "regenerar desde cero".
El workflow canónico: cuatro fases
Casi todas las implementaciones serias siguen una variante de esta secuencia:
Fase 1: Constitution (los principios inmutables)
Un fichero — típicamente constitution.md o .cursorrules — con las reglas no negociables del proyecto: estándares de código, política de testing, manejo de errores, restricciones de seguridad obligatorias. Cada sesión del agente empieza leyendo esto.
Ejemplo de constitución para un proyecto Python:
# Constitution: Proyecto Flavia (data intelligence)
## Stack
- Python 3.12+, FastAPI, async-first
- PostgreSQL 16 + pgvector, Redis 7, MinIO
- Pydantic v2 con strict mode obligatorio
- Tipado estricto (mypy --strict)
## Seguridad (no negociable)
- Sanitización de inputs: TODA entrada externa pasa por validators Pydantic
- Secrets: SOLO via env vars o vault. Prohibido literal en código (CWE-798)
- SQL: SOLO queries parametrizadas. Prohibido f-string en SQL (CWE-89)
- Crypto: cryptography library, AES-GCM, nunca ECB (CWE-327)
- Logs: nunca logear PII, tokens, ni cuerpos completos de request
- Deserialización: nunca pickle de fuentes externas (CWE-502)
## Estilo
- Funciones <50 líneas, complejidad ciclomática <10
- Docstrings Google style obligatorios en API pública
- Tests pytest con cobertura mínima 85% en módulos coreEste fichero no se toca a la ligera. Es el higher-order control plane: la IA ejecuta, los humanos legislan.
Fase 2: Spec (qué hay que construir)
Para cada feature, un fichero spec.md con notación EARS (Easy Approach to Requirements Syntax):
WHEN [condición] THE SYSTEM SHALL [comportamiento esperado]Cada requisito en EARS es directamente convertible a un test case. Cero ambigüedad.
Ejemplo para un endpoint de autenticación:
# Spec: Endpoint POST /auth/login
## Acceptance criteria (EARS)
- WHEN el body contiene email y password válidos
THE SYSTEM SHALL devolver 200 con {access_token, refresh_token, expires_in}
- WHEN el email no existe en la BBDD
THE SYSTEM SHALL devolver 401 con mensaje genérico (NO revelar existencia)
- WHEN el password es incorrecto
THE SYSTEM SHALL devolver 401 con el mismo mensaje genérico (anti user enumeration)
- WHEN se reciben >5 intentos fallidos en 60s desde la misma IP
THE SYSTEM SHALL devolver 429 y registrar evento en SIEM
## Constraints técnicos
- JWT: HS256 con secret de >=256 bits desde env var
- Refresh token: opaque, almacenado en Redis con TTL=7d
- Password hashing: argon2id (no bcrypt, no PBKDF2)
- Rate limiting: slowapi con backend Redis
## Non-goals
- No implementar OAuth/OIDC en esta iteración
- No implementar MFA (feature separada)
## Security checklist (CWE mapeadas)
- [ ] CWE-307: Brute force mitigado via rate limit
- [ ] CWE-204: Respuestas idénticas en error cases
- [ ] CWE-522: Password hashing con argon2id
- [ ] CWE-798: Secrets desde env, nunca hardcodedNon-goals explícitos. Lo que NO se construye importa tanto como lo que sí. Previene el over-engineering del agente y el scope creep.
Fase 3: Plan (cómo se va a construir)
Modo "Plan" o "Architect" del agente. La IA propone el approach técnico antes de escribir una sola línea ejecutable. Tú revisas: ¿hay fallos arquitectónicos? ¿riesgos de seguridad no contemplados? ¿alineamiento con la constitution?
Solo cuando apruebas, pasa a la siguiente fase. Este gate de aprobación humana es lo que diferencia SDD del autopilot.
Fase 4: Tasks + Implementation
El plan se descompone en tareas atómicas. El agente las ejecuta una a una. Cada tarea referencia un acceptance criterion del spec. Cuando todas pasan y los tests verdes coinciden con los EARS, la feature está hecha.
SDD como instrumento de ciberseguridad: el ángulo que casi nadie cuenta
Aquí es donde la cosa se pone interesante para los que nos dedicamos a esto.
El paper "Constitutional SDD" (arXiv, feb 2026) formaliza algo que llevábamos meses oliendo: embeber restricciones de seguridad con mappings CWE explícitos dentro de la constitución del proyecto. Cuando lo haces, el agente literalmente no puede escribir el patrón vulnerable sin saltarse un gate visible.
Esto te da, en la práctica, cinco controles compuestos que antes eran imposibles sin SAST + tooling pesado:
1. Prevención en origen. El agente conoce las CWE prohibidas antes de generar. No genera cursor.execute(f"SELECT ... {user_input}") porque la constitution lo prohíbe explícitamente con referencia a CWE-89.
2. Trazabilidad regulatoria. Cada decisión queda en Git: spec → plan aprobado → commit. Para auditorías NIS2, ENS, o procesos de certificación ETSI EN 303 645, esto es oro. Tienes el rastro completo de por qué se tomó cada decisión.
3. Acceptance criteria como tests de seguridad. Cada EARS en el spec es un test. Los tests de seguridad dejan de ser un artefacto separado y son parte del contrato funcional.
4. Reproducibilidad de la threat model. El threat modeling deja de vivir en un Visio olvidado. Vive en threat-model.md junto al spec, y cualquier cambio de spec dispara una revisión.
5. Gates de cumplimiento como código. Extensiones tipo Architecture Guard te permiten meter chequeos pre-merge: "ningún endpoint puede ir a producción sin acceptance criteria de rate limiting", "todo manejo de PII debe referenciar el spec de GDPR".
Si estás haciendo pentesting o consultoría de desarrollo seguro, SDD es la primera metodología que te da puntos de inspección de seguridad a nivel proceso, no solo a nivel código. Audit-friendly por construcción.
Anti-patrones: cómo SDD se rompe
No es magia. Estos son los modos de fallo que ya hemos visto:
1. "Big-bang spec". El spec mastodonte de 50 páginas que nadie va a leer. ThoughtWorks lo marcó como anti-patrón. Regla: si el spec no se revisa en <5 minutos, partelo.
2. Spec divorciado del código. Escribes el spec, generas, y nunca vuelves al spec. En cuanto edites el código a mano sin actualizar el spec, vuelves al vibe coding con pasos extra.
3. Specs vagos disfrazados de formales. "El sistema debe ser seguro" no es un acceptance criterion. EARS o muerte.
4. Olvidar los non-goals. Sin "lo que NO hacemos", el agente reinventa autenticación, añade cachés que no pediste, mete dependencias innecesarias.
5. Saltarse el gate humano del Plan. Si dejas que el agente vaya directo de spec a código sin revisión del plan, has comprado un coche sin probar los frenos.
6. Constitution-rot. La constitution se escribe el día 1 y nadie la actualiza. Tiene que vivir. Cada incidente, cada lección aprendida, cada nueva CWE relevante debería actualizarla.
Cuándo NO usar SDD
Hay que ser honestos. SDD tiene overhead. No lo apliques a:
- Scripts one-shot de menos de 100 líneas que vas a tirar mañana
- Spikes técnicos exploratorios donde el objetivo es descubrir, no entregar
- Prototipos pre-product/market-fit donde la velocidad importa más que la corrección
- Hot-fixes de incidentes en producción (el spec lo escribes después, en el post-mortem)
Pero para cualquier sistema que vaya a tocar datos sensibles, atravesar un boundary regulatorio, o vivir más de seis meses en producción: SDD paga su overhead con creces.
Empieza esta semana: un protocolo en 5 pasos
- Crea tu
constitution.md. No la copies de internet. Es la destilación de los principios que ya defiendes en code reviews. Incluye 10-15 reglas de seguridad mapeadas a CWE. - Elige una feature pequeña que tengas que construir esta semana. No la más importante. Una bien delimitada, idealmente con superficie de seguridad clara.
- Escribe el spec en EARS antes de tocar el editor. Acceptance criteria, non-goals, constraints técnicos, checklist de seguridad. Timebox: 30 minutos.
- Pásale el spec a tu agente (Claude Code con Spec Kit, o el harness que prefieras). Pídele un plan. Revísalo como si fuera un PR. No apruebes en automático.
- Deja que ejecute. Compara el output contra el spec, no contra tu intuición. Si algo no cuadra, arregla primero el spec, luego regenera.
Hazlo tres veces. La cuarta ya no vas a querer volver atrás.
El cierre
El cambio de fondo es éste: estamos pasando de la era del programador como autor a la del programador como editor y legislador. El agente escribe. Tú decides qué se escribe, bajo qué reglas, contra qué criterios. SDD es el lenguaje contractual de esa nueva relación.
Y para los que llevamos años en ciberseguridad, hay una buena noticia escondida: la disciplina que el sector lleva pidiendo desde hace décadas — "specifica antes de codear, modela amenazas, mapea controles a estándares" — por fin tiene un vehículo que los desarrolladores adoptan voluntariamente. No porque se lo impongamos, sino porque va más rápido.
El vibe coding fue divertido. Pero los frameworks dejan de ser opcionales cuando el coste de un fallo es una brecha de datos, una sanción de NIS2, o un servicio crítico caído.
El spec es el contrato. El contrato es la seguridad. Y la seguridad, esta vez, viene incluida en la velocidad.
Referencias y lecturas recomendadas
- arXiv 2026: "Spec-Driven Development: From Code to Contract in the Age of AI" (feb 2026)
- arXiv 2026: "Constitutional SDD" (feb 2026) — mappings CWE en specs
- GitHub Spec Kit: github.com/github/spec-kit (MIT, v0.1.12+)
- InfoQ (enero 2026): análisis sobre specs ejecutables como control plane
- ThoughtWorks Technology Radar Vol. 33: SDD en "Assess"
- CWEval (Columbia): benchmark de seguridad en código generado por LLM
- DeepLearning.AI: curso "Spec-Driven Development with Coding Agents