Después del vibe coding: spec-driven development

GSD y Superpowers — lo que necesitas cuando describir ya no basta

La semana pasada escribí sobre vibe coding: describes lo que quieres en lenguaje natural, el agente lo genera, tú validas. Lo llamé la Thermomix del software. La conclusión era que funciona, pero solo resuelve la mitad del problema: la velocidad. Deja la otra mitad intacta.

La otra mitad es la dirección. Qué estás construyendo exactamente, por qué esa decisión y no otra, cómo vas a saber que lo que el agente te devuelve es correcto. Todo eso sigue sin resolverse cuando la única herramienta que tienes es “hablar con la IA”.

En los últimos meses ha aparecido una respuesta concreta a ese hueco, y está empezando a consolidarse con un nombre: spec-driven development. La idea es vieja — escribir specs antes que código existe desde los setenta — pero lo que es nuevo es que ahora las specs no son para humanos. Son para el agente. Y cambian radicalmente lo que puedes construir con IA sin perder el control de lo que estás construyendo.

Qué significa “spec” ahora

Antes de entrar en herramientas concretas, conviene entender qué significa “spec” en este contexto, porque no es lo que significaba hace diez años.

Una spec tradicional era un documento muerto. Alguien lo escribía, alguien lo leía, alguien lo ignoraba cuando llegaba la hora de programar. Al final del proyecto el documento y el código no se parecían en nada, y todo el mundo había aprendido a convivir con esa divergencia como quien convive con el goteo del grifo del baño.

Una spec para un agente de IA es otra cosa. Es un artefacto vivo que el agente lee antes de actuar, actualiza cuando toma decisiones, y consulta para verificar que lo que ha hecho encaja con lo que se le pidió. No es documentación post-hoc: es el contrato de trabajo. Puede ser un plan de fases, un conjunto de criterios de aceptación, una descripción del comportamiento esperado, una lista de verificaciones. Todo junto normalmente.

La diferencia práctica es brutal. Con vibe coding puro le dices al agente “hazme un buscador” y te lo hace. Lo que no sabes es qué asunciones ha tomado, qué edge cases ha ignorado, qué ha decidido por ti sin preguntarte. Con spec-driven development le das al agente el mismo “hazme un buscador”, pero también le das un documento que dice “estos son los requisitos no funcionales, estos los casos que tiene que manejar, esta la forma de validar que funciona, y estas las decisiones que no puedes tomar sin consultarme”. El agente ya no es un genio caprichoso. Es un ingeniero con mandato.

Esto lleva cincuenta años intentándose

Antes de que nadie hablase de vibe coding, agentes o spec-driven, la industria del software ya tenía claro que escribir código sin especificar antes qué debía hacer era una forma elegante de construir castillos sobre arena. La historia intelectual es larga y los nombres son conocidos, aunque casi nadie los cita fuera de la academia.

En 1969, Tony Hoare publicó An Axiomatic Basis for Computer Programming. Su propuesta era incómoda y radical: cada fragmento de código debía poder describirse con una pre-condición (lo que es cierto antes de ejecutarlo) y una post-condición (lo que garantiza después). La spec no era un documento anexo. Era el programa. El código era solo una forma de implementarlo.

Tres años después, en 1972, David Parnas publicó On the Criteria To Be Used in Decomposing Systems into Modules. Introdujo la idea de que cada módulo de software debía ocultar sus decisiones internas y exponer solo un contrato: qué puede asumir el cliente del módulo, qué promete cumplir el módulo. Contrato primero, implementación después.

En 1976, Edsger Dijkstra llevó la idea al extremo con A Discipline of Programming. Su tesis: el programa se deriva de la especificación, no al revés. Primero formalizas qué quieres que haga. Luego demuestras, paso a paso, que tu código lo cumple. Ingeniería como matemática.

El giro decisivo lo dio Donald Knuth en 1984 con Literate Programming. Knuth no hablaba de pre-condiciones ni demostraciones formales. Hablaba de algo más humano: un programa es un documento dirigido a un lector, y el código está embebido en la prosa que lo explica, no al revés. Su frase famosa: los programas deben tratarse como obras de literatura dirigidas a seres humanos.

Dos años después, en 1986, Bertrand Meyer formalizó la idea en un lenguaje real con Design by Contract: invariantes, pre y post-condiciones como parte del código ejecutable de Eiffel, el primer y único lenguaje realmente Orientado a Objetos. No como documentación. Como contrato verificable en tiempo de ejecución.

Y en 1994, Leslie Lamport publicó TLA+, un lenguaje para especificar sistemas distribuidos antes de escribirlos. Amazon, Microsoft y Google lo usan hoy para verificar piezas críticas de su infraestructura.

¿Por qué entonces casi ninguna empresa aplica estas ideas en su día a día? Porque el coste siempre fue asimétrico. Escribir la spec primero era lento. Mantenerla sincronizada con el código era un trabajo extra que nadie pagaba. El software funcionaba sin ella, aunque mal. Así que la industria eligió la vía rápida y acumuló cincuenta años de deuda conceptual.

Lo que ha cambiado ahora es el lector. Knuth escribía para humanos que casi nunca leían los programas de otros. Hoy el agente sí los lee. Los lee siempre. Y si tu código, tu arquitectura y tus decisiones no son legibles para él, no puede trabajar. Lo que era una aspiración ética se ha convertido en un requisito funcional.

Spec-driven development no es una moda de 2026. Es la primera vez en cincuenta años que hay un incentivo económico real para hacer lo que Hoare, Parnas, Dijkstra, Knuth, Meyer y Lamport llevan diciéndonos desde los setenta.

GSD: el workflow como contrato

GSD son las siglas de Get Shit Done. Es un conjunto de comandos que se instala encima de Claude Code y que convierte cualquier trabajo no trivial en una secuencia estructurada de fases con artefactos versionados. Lo desarrolló un ingeniero llamado Dan Gooding y está ganando adopción en equipos que usan agentes de IA en proyectos serios.

La idea central es sencilla: antes de escribir una línea de código, el agente te obliga a pasar por cuatro etapas — discutir, planificar, ejecutar, verificar — y cada una deja un artefacto en disco que la siguiente lee. No hay atajos. Si intentas saltar directamente a “implementa esto”, GSD te detiene y te hace definir primero el qué, el cómo y los criterios de aceptación.

En la práctica, trabajas con una serie de comandos muy concretos. /gsd:discuss phase hace al agente preguntarte lo que necesita saber antes de planificar — qué asunciones está tomando, qué decisiones dependen de ti, qué riesgos ve. /gsd:plan-phase genera un PLAN.md con la descomposición en tareas, dependencias entre ellas, y los tests que definirán que está hecho. /gsd:execute-phase ejecuta ese plan con commits atómicos por tarea. /gsd:verify-work valida al final que lo que se ha construido cumple los criterios que se fijaron al principio.

El resultado es que tu carpeta de trabajo deja de ser un vertedero de código generado y se convierte en una estructura de carpetas tipo .planning/001-fase-auth/ con tres ficheros: RESEARCH.md (lo que el agente investigó antes de planificar), PLAN.md (lo que va a hacer), VERIFICATION.md (cómo demostramos que está hecho). Esto no es documentación. Es el contrato que el agente firma consigo mismo y que tú puedes leer, auditar y modificar en cualquier momento.

Lo potente de GSD es que te obliga a pensar arriba-abajo. Primero el roadmap del proyecto. Luego las fases. Luego los planes. Luego el código. Cuando lo usas durante un par de semanas notas algo incómodo y revelador: la mayor parte del valor no está en la ejecución con IA, está en la conversación estructurada que te fuerza a tener antes. El agente te obliga a concretar cosas que de otra forma habrías dejado ambiguas. Y esas cosas ambiguas son exactamente las que después reventaban en producción.

El coste es evidente: GSD es mucho más lento que vibe coding para tareas pequeñas. Si lo que quieres es un script de veinte líneas, usar GSD es matar moscas a cañonazos. Pero para cualquier proyecto que dure más de una sesión y tenga más de una decisión importante, la inversión se paga varias veces.

Superpowers: disciplina en cada decisión

Superpowers ataca el mismo problema desde el ángulo opuesto. Lo desarrolló Jesse Vincent, un ingeniero conocido en la comunidad de Claude Code, y su tesis es muy distinta a la de GSD: el problema no es que el agente no tenga un plan global, es que en cada microdecisión del día a día se salta el rigor que aplicaría cualquier ingeniero senior.

Un ejemplo concreto. Le pides al agente que arregle un bug. Sin Superpowers, el patrón habitual es: el agente lee el error, propone una hipótesis, modifica el código, dice “listo”. A veces funciona. Otras veces parchea un síntoma y deja la causa real intacta. Con Superpowers activada, el agente no puede responder hasta que invoque una skill llamada systematic-debugging. Esa skill e obliga a seguir unprocedimiento: reproducir el bug de forma determinista, formular hipótesis, aislarlas una a una, verificar el fix con un test antes de declarar victoria. No es una sugerencia. Es un gate obligatorio.

Superpowers es, en la práctica, una colección de unas quince skills que cubren momentos concretos en los que los agentes suelen pifiarla: brainstoring antes de diseñar una feature, test-driven-development antes de escibir código, verification-before-completion antes de declarar algo como terminado, receiving-code-review cuando el usuario le da feedback, dispatching-paralle-agents cuando hay trabajo independiente que se puede paralelizar. Cada skill s un procedimiento probado empaquetado en un fichero markdown qu el agente carga cuado elcontexto lo requiere.

La parte inteligente del diseño es que las skills se auto-invocan. No tienes que acordarte de decir “usa TDD ahora”. El agente detecta que va a escribir código nuevo y la skill se activa sola. Detecta que estás a punto de declarar una tarea como hecha y la skill de verificación le exige evidencia antes de dejarle hacerlo. Las skills son, en el fondo, contratos de comportamiento que el agente firma con su yo futuro: “cuando me toque hacer X, voy a seguir obligatoriamente Y pasos”.

Donde GSD es arriba-abajo (primero el plan, luego la ejecución), Superpowers es abajo-arriba (no importa qué estés haciendo, cuando hagas esto lo harás así). Donde GSD protege contra la falta de dirección, Superpowers protege contra la falta de disciplina. Y aquí está el punto: son dos problemas distintos que requieren dos soluciones distintas.

En mi experiencia, la skill más valiosa de Superpowers es la más aburrida de todas: verification-before-completion. El agente no puede decir “hecho” hasta que ha ejecutado el comando que demuestra que funciona y ha mostrado la salida. Parece obvio. En la práctica, evita el 80% de los “terminé” prematuros que provocan después una ronda entera de debugging innecesario.## La diferencia que importa

La primera reacción cuando ves GSD y Superpowers juntos es pensar que compiten. Las dos hablan de estructurar el trabajo con agentes. Las dos meten disciplina donde vibe coding la esquiva. Las dos generan artefactos y fuerzan procedimientos. Parecen dos respuestas al mismo problema. No lo son. Resuelven problemas distintos, y entenderlo es la diferencia entre elegir uno, elegir otro, o combinarlos.

GSD organiza el **proyecto**. Su unidad de trabajo es la fase, que dura horas o días, y su foco es asegurar que antes de ejecutar algo haya un contrato claro de qué se va a hacer, por qué, y cómo se va a validar. Es el equivalente moderno de la idea de Dijkstra: deriva el código de la especificación. Si tu problema es que los agentes se lanzan a construir sin saber bien qué están construyendo, GSD es tu respuesta.

Superpowers organiza la **decisión**. Su unidad de trabajo es cada interacción individual del agente, que dura segundos o minutos, y su foco es que en cada microdecisión el agente siga el procedimiento correcto. Es el equivalente moderno de la idea de Meyer: contratos ejecutables que se verifican en tiempo de ejecución. Si tu problema es que los agentes se saltan pasos que cualquier ingeniero senior daría por obligatorios, Superpowers es tu respuesta.

En términos prácticos, la diferencia se nota así. Un proyecto gestionado con GSD pero sin Superpowers acaba con planes y fases impecables, pero cada fase internamente tiene los mismos problemas de vibe coding — el agente se salta verificaciones, propone fixes sin hipótesis, declara cosas hechas sin evidencia. Un proyecto con Superpowers pero sin GSD tiene cada decisión bien tomada, pero el conjunto carece de dirección — el agente implementa bien cosas que quizá no tenía que implementar. Los dos fallan, por motivos opuestos.

Juntos, se complementan de manera casi perfecta. GSD define el qué y el por qué a nivel de proyecto. Superpowers garantiza el cómo a nivel de cada paso. El resultado es lo más cercano a trabajar con un ingeniero senior disciplinado que he visto hasta ahora — no porque el agente sea un ingeniero senior, sino porque la combinación de estructura y disciplina le impide actuar como un junior que se salta pasos.

Hay una lectura más profunda aquí que conviene no perder. GSD es la herencia directa de la escuela formal de Hoare, Dijkstra y Parnas: el rigor viene de especificar primero. Superpowers es la herencia directa de Knuth y Meyer: el rigor viene de construir las garantías dentro del propio acto de programar. Medio siglo después, los dos caminos siguen siendo válidos. Y siguen siendo complementarios.

El sistema de previsión que estamos construyendo así

Voy a aterrizar todo esto con el proyecto real en el que más lo estoy aplicando. En Mercadona Tech estamos construyendo un sistema de previsión de demanda a escala industrial: predecir cuánto se va a vender de cada producto, en cada centro, en cada franja horaria, para cada día. Más de doscientas mil series temporales reconciliadas en cinco niveles de agregación, con intervalos de confianza que tienen que tener garantías matemáticas de cobertura. No es un proyecto donde vibe coding pueda llevarte lejos. Una decisión mal tomada en una fase temprana contamina todas las posteriores, y muchas de las decisiones solo se ven con años de oficio.

Aquí GSD hace su trabajo. El proyecto vive en fases: exploración de datos, baselines, modelos candidatos, reconciliación jerárquica, calibración de intervalos, despliegue a producción. Cada fase tiene su plan, sus criterios de aceptación y su verificación. Los documentos que se generan no son reportes para enseñar a un jefe. Son el contrato que el siguiente paso del proyecto lee antes de ejecutar. Cuando un colaborador entra al proyecto, no tiene que preguntarme qué está pasando — lee la fase activa y lo sabe.

Aquí Superpowers hace el suyo. Las disciplinas de verificación impiden que el agente reporte una métrica sin haberla validado con backtesting riguroso. El procedimiento obligatorio de debugging aparece cada vez que un modelo degrada en una fracción del dataset y nos fuerza a aislar la causa antes de parchear. La skill de verificación-antes de-completar evita los falsos positivos clásicos de la ciencia de datos, donde algo parece funcionar porque se ha medido mal.

Sin GSD, un proyecto de esta envergadura se convierte rápido en treinta notebooks que nadie sabe cómo conectar. Sin Superpowers, publicas una métrica que parece excelente hasta que la realidad te corrige. Con ambos, la IA acelera cada fase sin renunciar al rigor que un sistema de este tamaño exige.

Las tres capas

Si hace una semana dejábamos vibe coding como la Thermomix del software —velocidad accesible para todo el mundo —, ahora podemos terminar de dibujar el cuadro completo. Construir con IA no es una técnica, son tres capas que se apoyan unas en otras.

La primera capa es la velocidad. Vibe coding. La capacidad de conversar con un agente y ver cómo el código aparece en segundos. Resuelve el problema que durante décadas fue el cuello de botella del desarrollo: la distancia entre idea y prototipo.

La segunda capa es la dirección. Spec-driven development en su encarnación moderna, con herramientas como GSD al frente. Resuelve un problema más sutil y más viejo: cómo garantizar que lo que el agente construye responde realmente a lo que hace falta, no a lo que el agente ha interpretado que hacía falta. Hoare lo vio en el sesenta y nueve. Dijkstra en el setenta y seis. Nosotros lo estamos aplicando por primera vez a escala gracias a que el coste de mantener specs vivas ha colapsado.

La tercera capa es la disciplina. Superpowers y el resto de frameworks que meten rigor en cada decisión individual del agente. Resuelve el problema de que un agente que en promedio lo hace bien puede hacerte daño en los pocos casos en los que se salta un paso crítico. Meyer lo formalizó en Eiffel en los ochenta. Hoy lo tenemos disponible como skills que el agente invoca solo.

Las tres juntas son mucho más que la suma de las tres por separado. Velocidad sin dirección te lleva rápido a un sitio que no era el que querías. Dirección sin disciplina te lleva al sitio correcto con un sistema que falla cuando más importa. Disciplina sin velocidad te deja atrás, fabricando calidad en un mercado que premia la iteración rápida. Y velocidad sin dirección ni disciplina es exactamente lo que los ingenieros senior temen cuando oyen hablar de vibe coding.

La pregunta que te deberías hacer no es si adoptar IA en tu proceso de desarrollo. Esa batalla ya está resuelta. La pregunta es si estás adoptando las tres capas o solo la primera. Porque la primera es la que sale gratis. Las otras dos son las que deciden si dentro de un año tendrás un sistema que se sostiene o una deuda técnica imposible de pagar.

Si en algún momento te descubres pensando “el agente lo hace rápido pero no me fío de lo que entrega”, lo que te falta no es más IA. Es spec y disciplina. Y ambas existen, están maduras, y llevan cincuenta años esperando su momento.