PulseFlow Tecnologia
← Insights
·6 min de lectura·brief-ejecutivo·spec-driven-development·vibe-coding·spec-kit
PulseFlow Tecnologia

Spec-driven development: la respuesta madura al vibe coding

Dos empresas que compiten directamente por desarrolladores - GitHub y Microsoft - llegaron a la misma conclusión sobre el problema más costoso del "vibe coding": describir un objetivo, recibir un bloque de código, y descubrir recién después que el resultado nunca consideró cómo el sistema debía interactuar con lo que ya existía. La respuesta que ambas documentan es el spec-driven development, y GitHub Spec Kit se convirtió en la implementación de referencia.

El diagnóstico: el código es vinculante, la spec no

Microsoft resume el argumento central de forma directa: "el código es un artefacto vinculante" - difícil de desacoplar una vez implementado —, mientras que las especificaciones permiten experimentación flexible antes de que algo se fije. La empresa describe el spec-driven development no como documentación exhaustiva o planificación en cascada, sino como "version control for your thinking" - hacer que las decisiones técnicas sean "explícitas, revisables y evolutivas", de la misma forma en que se versiona el código.

El escenario que ilustra el costo de no tener esto

Microsoft cita un escenario concreto: un sistema de notificaciones donde distintos miembros del equipo hicieron suposiciones contradictorias sobre cómo debía funcionar - divergencias que una spec bien hecha habría detectado antes de escribir una sola línea de código, no después, en producción. Es el mismo argumento detrás del contraste que traza GitHub entre vibe coding y spec-driven development: el vibe coding acepta el resultado del primer prompt; el spec-driven development fuerza "claridad sobre cómo debe interactuar con los sistemas existentes" antes de aceptar cualquier implementación.

Tres comandos, un flujo secuencial

GitHub Spec Kit - hoy con más de 118.000 estrellas - organiza esto en torno a comandos secuenciales: /specify define los requisitos funcionales (el "qué" y el "por qué"), /plan define las decisiones técnicas (el "cómo"), /tasks divide la especificación en unidades implementables. La herramienta en sí, Specify CLI, es agnóstica respecto al agente de IA usado - funciona con más de 30 agentes distintos, desde GitHub Copilot hasta Claude Code y Gemini.

Lo que permite la spec que el vibe coding no permite

Un detalle que destaca Microsoft y que rara vez aparece en discusiones sobre IA generativa en código: con la especificación como artefacto central, es posible explorar múltiples implementaciones a partir de la misma spec - por ejemplo, comparar un componente escrito en Rust contra uno escrito en Go, sin reescribir el requisito desde cero para cada intento. Eso es estructuralmente imposible en vibe coding, donde la especificación solo vive dentro del prompt de un único intento.

Por qué esta es la respuesta madura, no solo otra herramienta

GitHub y Microsoft no están inventando las specs - los architecture decision records (ADRs) y los requisitos formales ya existían antes de la IA generativa. Lo que cambia es la integración sistemática entre la spec y el flujo del agente: la especificación deja de ser un documento archivado y pasa a ser el artefacto que el propio agente usa para generar, y que el equipo usa para revisar, con trazabilidad entre el requisito original y el código final.

Fuentes