Vibe coding vs. SDD (Spec Driven Development): dos formas de trabajar con IA

Desde que los asistentes de código basados en modelos de lenguaje se volvieron parte del trabajo diario, aparecieron dos formas muy distintas de usarlos. Una consiste en pedir, mirar el resultado, ajustar y volver a pedir: es rápida, divertida y muy útil para explorar. La otra consiste en escribir primero qué debe hacer el sistema, con precisión, y recién después generar o implementar el código. La primera se conoce como vibe coding; la segunda, como SDD (Spec Driven Development, desarrollo guiado por especificaciones).

La discusión suele plantearse como una pelea: ¿es el vibe coding el fin del rigor, o es el SDD una forma elegante de frenar al equipo? Ninguna de las dos posturas ayuda. Son enfoques con costos y beneficios distintos, y la decisión correcta depende del tipo de problema, de cuánto tiempo va a vivir el código y de quién va a pagar las consecuencias si algo falla.

Qué es el vibe coding, en la práctica

El vibe coding es un ciclo corto de conversación con la herramienta: se describe una intención en lenguaje natural, el asistente propone código, se ejecuta, se observa el comportamiento y se corrige sobre la marcha. El criterio de aceptación es inmediato y sensorial: funciona o no funciona, se ve bien o no se ve bien.

Su gran ventaja es la velocidad de aprendizaje. Permite tener algo andando en minutos, probar una idea antes de comprometerse con una arquitectura y descubrir requisitos que nadie había pensado hasta ver la primera versión. Para prototipos, pruebas de concepto, herramientas internas de un solo uso o scripts de automatización, es difícilmente superable.

Sus límites aparecen cuando el código tiene que durar. En un flujo puramente conversacional es fácil que se pierdan decisiones: por qué se eligió cierta estructura, qué casos borde se consideraron, qué se dejó afuera a propósito. El resultado es un sistema que funciona hoy y que nadie puede explicar mañana, con dependencias que se acumulan sin revisión y pruebas que se escriben después, si se escriben.

Qué es el SDD y por qué vuelve al centro la especificación

El desarrollo guiado por especificaciones invierte el orden. Antes de escribir código se redacta una especificación: qué problema se resuelve, qué entradas y salidas existen, qué reglas de negocio aplican, qué comportamientos son obligatorios y cuáles quedan explícitamente fuera de alcance. Esa especificación es el contrato, y el código —escrito a mano o generado con ayuda de un asistente— es una implementación de ese contrato.

La novedad es que, con modelos de lenguaje capaces de leer un documento extenso, la especificación deja de ser un trámite y se vuelve una herramienta operativa: se le entrega al asistente como contexto, y a partir de ella se generan borradores de implementación, pruebas y documentación. El documento pasa a ser la fuente de verdad, y el código, una consecuencia revisable.

El costo es evidente: escribir bien una especificación lleva tiempo y exige pensar antes de teclear. Ese esfuerzo se recupera cuando el proyecto es grande, cuando participan varias personas, cuando hay requisitos regulatorios o cuando el sistema va a mantenerse durante años.

Las diferencias que realmente importan

Más allá de la anécdota, los dos enfoques se separan en ejes concretos:

• Punto de partida. En vibe coding se parte de una intención vaga y se refina con el resultado a la vista. En SDD se parte de un acuerdo escrito y se baja a la implementación.
• Criterio de éxito. En vibe coding el criterio es la demostración: se ve funcionando. En SDD el criterio es el cumplimiento de la especificación, verificable con pruebas.
• Manejo del cambio. En vibe coding el cambio es barato al principio y caro después, porque nadie sabe qué se rompió. En SDD el cambio se negocia en el documento y luego se propaga.
• Trazabilidad. En SDD cada requisito se puede rastrear hasta su implementación y su prueba. En vibe coding esa cadena suele no existir.
• Revisión de código. En vibe coding se revisa un diff que apareció de golpe. En SDD se revisa una implementación contra un contrato conocido de antemano.
• Conocimiento del equipo. En vibe coding el conocimiento queda en la cabeza de quien conversó con el asistente. En SDD queda en un documento que cualquiera puede leer.

Errores comunes al adoptar cualquiera de los dos

Del lado del vibe coding, el error más frecuente es no poner límites. Se empieza con un prototipo y, sin ninguna decisión explícita, ese prototipo termina en producción atendiendo usuarios reales. También es común aceptar código que nadie entiende porque «anda», y descubrir meses después que incluye dependencias innecesarias o supuestos que ya no se cumplen.

Del lado del SDD, el riesgo es el opuesto: convertir la especificación en un fin en sí mismo. Documentos larguísimos que nadie lee, aprobaciones que tardan más que la implementación y una sensación de burocracia que empuja al equipo a volver al atajo. Una especificación útil es la más corta que elimina ambigüedad, no la más completa posible.

Hay un tercer error, quizá el más caro: elegir el enfoque por moda. Aplicar SDD a un script de una tarde es desperdicio; hacer vibe coding sobre el módulo que gestiona facturación es una apuesta que rara vez sale bien.

Cómo combinarlos sin romper el proyecto

En la práctica, los equipos que mejor conviven con estas herramientas no eligen un bando: usan un enfoque graduado según el riesgo y la vida útil del código.

• Explorar con vibe coding. Cuando todavía no está claro qué se quiere construir, conviene prototipar rápido, sin compromiso, en una rama aparte y con la expectativa explícita de tirar ese código.
• Fijar la especificación antes de consolidar. Cuando la idea madura, se escribe qué debe hacer el sistema y qué no. Ese documento es el punto de partida de la versión que sí va a mantenerse.
• Generar y revisar contra el contrato. Con la especificación como contexto, se produce la implementación y se revisa requisito por requisito, no solo «a ojo».
• Automatizar la verificación. Cada regla de la especificación debería tener al menos una prueba que la cubra. Sin eso, el documento es una promesa sin respaldo.
• Dejar registro de las decisiones. Las decisiones que no están en la especificación ni en el código se pierden. Anotarlas cuesta poco y ahorra discusiones repetidas.

Un criterio simple para decidir: si el código va a vivir más de lo que tardó en escribirse, o si un error tendría consecuencias para terceros, conviene la especificación. Si es desechable y el objetivo es aprender, conviene la conversación libre.

Cierre

El vibe coding y el SDD no compiten por el mismo lugar. Uno es una herramienta de exploración; el otro, un mecanismo de control para sistemas que importan. El problema no es usar asistentes para escribir código, sino hacerlo sin decidir antes cuánto rigor necesita el proyecto. La pregunta útil no es «¿cuál es mejor?», sino «¿qué pasa si esto falla y quién lo va a mantener?». La respuesta a esa pregunta indica el camino.