El Renacimiento de las Especificaciones en la Era de los Agentes IA
El desarrollo de software vive un momento de inflexión. Mientras los agentes de código como Claude Sonnet 4 o GitHub Copilot nos permiten generar código a velocidades antes impensables, nos enfrentamos a un problema familiar: cuando no podemos leer todo nuestro código base, no podemos gestionarlo eficazmente.
En los equipos de desarrollo de Barcelona y el resto de España, esto se traduce en una realidad incómoda: proyectos que crecen más rápido de lo que podemos asimilar, decisiones arquitectónicas enterradas en commits crípticos, y esa sensación persistente de que estamos construyendo sobre arena movediza.
Es hora de hablar de Spec-Driven Development, una metodología que está emergiendo como respuesta a lo que algunos ya llaman “la segunda crisis del software”.
Del “Vibe Coding” al Desarrollo Estructurado
Llamémosle por su nombre: llevamos años haciendo “vibe coding”. Ese desarrollo guiado por intuición, conversaciones de Slack, y un README que se actualiza “cuando tengamos tiempo”. Funcionaba cuando los equipos eran pequeños y el código cabía en la cabeza de una persona.
Pero los modelos de lenguaje han cambiado las reglas del juego. Podemos generar código tipo waterfall a velocidad de agile multiplicado por siete. El resultado es previsible: nos ahogamos en nuestro propio output.
Drew Breunig lo expresó perfectamente en su charla reciente en MLOps Community: “Nuestro problema solía ser que no podíamos mantener una base de código completa en la cabeza. Ahora ni siquiera podemos leer toda nuestra base de código”.
El Triángulo Spec-Tests-Code
La primera generación de spec-driven development lo planteaba como una ecuación lineal: Spec + Tests + Agent = Code. Pero esto es un error conceptual.
En realidad, es un triángulo de feedback:
- Spec → define qué tests escribir y qué código implementar
- Tests → validan el comportamiento del código
- Code → genera nuevas decisiones que mejoran la spec
Implementar código no es el final del proceso; es el momento donde aparecen decisiones implícitas que deben capturarse y retroalimentar la especificación. Como cualquier arquitecto senior sabe: el software no funciona realmente hasta que se encuentra con el mundo real, y una spec no funciona realmente hasta que se implementa.
Herramientas del 2026: La Nueva Generación
Este año estamos viendo emerger herramientas específicas para gestionar este triángulo:
Plumb: Manteniendo la Sincronización
Plumb es una CLI que se integra con Git y extrae decisiones automáticamente de los diffs de código y las trazas de conversación con agentes. Cada git commit se convierte en un checkpoint que:
- Identifica decisiones arquitectónicas tomadas
- Actualiza la spec para reflejar esas decisiones
- Reporta gaps de cobertura entre spec, tests y código
- Genera un log de decisiones enlazado al código
Es como tener un arquitecto senior revisando cada commit, pero automatizado.
El Stack Moderno de Documentación
Las startups españolas más avanzadas están adoptando patrones como:
- ADRs (Architecture Decision Records) versionados en Git
- Design docs como código, con links bidireccionales
- Conformance tests en YAML/JSON independientes del lenguaje
- Docs-as-code siguiendo el framework Diátaxis
Casos de Uso Reales: Lo Que Funciona y Lo Que No
Éxitos Documentados
Vercel lanzó just-bash: un entorno bash simulado escrito en TypeScript, generado enteramente desde specs y tests de conformidad. Pydantic hizo lo mismo con Monty, un intérprete Python en Rust.
Anthropic intentó algo más ambicioso: 16 instancias de Claude y $20.000 para construir un compilador de C desde una spec suite. Llegaron al 99% de tests pasando, pero se estancaron. La lección: a medida que crece la complejidad, las decisiones estructurales son más importantes que los fixes locales.
La Realidad en Equipos de Consultoría
En la consultoría técnica en Barcelona, donde los proyectos cambian rápidamente y los equipos son multidisciplinares, spec-driven development ofrece ventajas concretas:
- Onboarding acelerado: nuevos desarrolladores entienden el “por qué” no solo el “qué”
- Handoffs limpios: el conocimiento no se va con la persona
- Code reviews centrados en arquitectura, no solo en sintaxis
- Debt tracking explícito: las decisiones de compromiso están documentadas
Implementación Práctica: Por Dónde Empezar
1. Audit de Decisiones Implícitas
Antes de estructurar el futuro, captura el pasado. Revisa los últimos 20 commits de tu feature principal:
git log --oneline -20 --grep="fix\|refactor\|change"Cada uno de esos commits contiene decisiones arquitectónicas no documentadas. Extráelas y docúmentalas en ADRs retroactivos.
2. Design Docs Ligeros
No caigas en el trap del “design doc perfecto”. Usa un template mínimo:
- Context: Por qué esto necesita decisión
- Decision: Qué vas a hacer
- Consequences: Trade-offs que asumes
- Tests: Cómo validarás que funciona
3. Conformance Tests Agnósticos
Define comportamiento esperado en formato agnóstico al lenguaje (YAML/JSON). Esto permite:
- Tests independientes de la implementación
- Migración entre tecnologías
- Contribución distribuida (cada dev puede trabajar en un subset)
El Futuro de GitHub y las Especificaciones
GitHub debe evolucionar para la era de los agentes. Los equipos necesitamos:
- Markdown como ciudadano de primera clase, no solo código
- Links bidireccionales entre decisions, requirements, code y tests
- Query interface para entender intent, no solo leer código
- Decision tracking integrado en pull requests
Microsoft está dejando dinero sobre la mesa al no tratar las especificaciones con la misma seriedad que el código.
Conclusiones para CTOs y Tech Leads
Spec-driven development no es una moda pasajera. Es una respuesta necesaria a la aceleración del desarrollo impulsado por IA. Los equipos que lo adopten temprano tendrán ventaja competitiva significativa.
Para equipos en España, donde la consultoría técnica y las startups B2B dominan el ecosistema, esto significa:
- Mayor predictibilidad en entregas
- Handoffs entre proyectos más limpios
- Menos deuda técnica acumulada
- Code reviews que realmente agregan valor arquitectónico
La implementación debe ser gradual y pragmática. Empieza documentando decisiones existentes, introduce design docs ligeros, y experimenta con herramientas como Plumb en proyectos no críticos.
Hemos estado aquí antes. La respuesta a la primera crisis del software fue proceso. La respuesta a la segunda crisis del software también será proceso, pero proceso apalancado por IA para mantenerlo ligero y sostenible.
El “vibe coding” tuvo su momento. Es hora de volver a la ingeniería disciplinada.