Hay una forma de trabajar con IA que se siente productiva y no lo es. Le escribes al modelo "hazme un formulario de registro", miras lo que devuelve, no te gusta, le dices "no, así no", vuelves a mirar, corriges otra vez. Avanzas a golpes. Se llama vibe coding: pedirle a la máquina a ver qué sale y negociar con el resultado. Funciona para un juguete. Se derrumba en cuanto hay algo real en juego.
El fallo no está en el modelo ni en tu prompt. Está en el orden. Empezaste por la ejecución sin haber escrito qué era "correcto". Sin ese contrato previo, cualquier salida es defendible y ninguna es verificable. En Qirava dejamos esa forma de trabajar y adoptamos otra: primero la especificación, después la ejecución. Se llama Spec-Driven Development, SDD.
01 · el giroLa especificación primero, la ejecución después
Spec-Driven Development significa exactamente lo que dice: el desarrollo lo conduce la especificación, no el impulso. Antes de que un agente o una persona toque nada, existe un documento que fija qué se quiere, para quién, con qué límites y cómo se sabrá que quedó bien. Ese documento no es papeleo: es la fuente de la verdad que gobierna todo lo que viene después.
La diferencia con el prompting básico es de raíz. El prompt básico describe una tarea suelta y espera una salida. La spec describe el resultado esperado y los criterios de aceptación, y luego la ejecución se mide contra ella. En el vibe coding, tú eres el criterio (lo que te guste pasa). En SDD, el criterio está escrito antes y es independiente de tu ánimo del día.
En el vibe coding, el criterio de "correcto" eres tú. En SDD, está escrito antes de empezar.
No es una idea nueva de la era de la IA. Amazon lleva más de dos décadas trabajando "hacia atrás" (working backwards): antes de construir un producto se escribe el comunicado de prensa y las preguntas frecuentes que tendría el día del lanzamiento [1]. Primero se redacta el resultado, y solo si ese resultado convence, se construye. SDD toma esa disciplina y la pone al frente del desarrollo asistido por modelos.
02 · el gobiernoLa spec gobierna a los agentes, y las compuertas frenan lo prematuro
En Qirava la spec no es un archivo que alguien lee y olvida. Es lo que gobierna a los agentes. Cada agente nace bajo gobierno: al arrancar carga una skill universal (qirava-llm-governance) más la skill de su rol. Nadie ejecuta "a su criterio".
Los roles son paquetes de skills con una estructura fija: una universal que todos comparten, una primaria propia del rol, secundarias de apoyo y una lista de skills prohibidas para ese rol. Así, natalia.marketing.ai escribe campañas pero no aprueba arquitectura; santiago.architect.ai define estructura pero no certifica calidad; sofia.qa-sprint.ai valida; martin.legal.ai, beatriz.ciso.ai y marcos.scrum.ai cubren lo suyo; y libaniel.ceo.human aprueba. Cada agente sabe qué puede hacer y qué tiene vedado antes de mover un dedo.
Pero escribir la spec no basta: hay que impedir que algo verde llegue lejos. Para eso están las compuertas de madurez. Nada avanza sin pasar la suya. Un elemento nace G0 (especificada). Solo si pasa validación llega a G1 (borrador). Solo con aprobación del CEO llega a G2 (operativa). Y lo que aspira a decidir de forma amplia sube a G3 (consejo). No hay atajos: cada compuerta es un filtro real.
Aquí hay un principio que evita el mayor riesgo del trabajo con agentes. Los borradores deliberan pero no simulan ejecución. Deliberar es proponer, evaluar y decidir. Ejecutar es hacer el cambio real. Un borrador en G1 puede razonar, comparar opciones y recomendar; lo que no puede es actuar como si el cambio ya estuviera hecho. Confundir las dos cosas es como aprobar un plano y creer que el edificio ya está construido.
03 · la mecánicaCómo se sostiene en el día a día: índice, skills y QA con regresión
Una spec sin una fuente de verdad se dispersa en versiones que se contradicen. Por eso el método se apoya en un DOCUMENT_INDEX: el índice documental que dice cuál es el documento válido de cada cosa. Las skills viven en un toolkit; el gobierno vive en un vault; y los proyectos las consumen por symlink, sin copiar ni bifurcar. Un solo lugar manda; el resto apunta a él.
La última pieza es la calidad. En SDD, QA no es apretar un botón hasta que "pase". Es un bucle con regresión profesional: se prueba, se registran hallazgos, se corrigen, y se vuelve a probar todo el conjunto, no solo lo que falló, hasta certificar. No se hacen retests a medida para que dé verde. Se certifica contra la spec o no se certifica. Como la spec fijó de antemano qué era "correcto", QA tiene un patrón contra el cual medir, y esa es justo la pieza que el vibe coding nunca tuvo.
Sin spec, QA no tiene contra qué medir. Con spec, "correcto" dejó de ser una opinión.
Junta las tres partes y se ve el cambio completo. La spec fija el resultado antes de empezar. El gobierno acota qué puede hacer cada agente y las compuertas frenan lo que no está maduro. El índice mantiene una sola verdad y QA certifica contra ella con regresión. Nada de eso existe cuando le pides a un modelo "a ver qué sale".
Por eso dejamos el vibe coding. No porque la IA sea mala escribiendo, sino porque un resultado sin especificación no se puede gobernar, ni verificar, ni repetir. La próxima vez que vayas a pedirle algo a un modelo, prueba a escribir primero, en dos líneas, qué sería estar terminado. Esa línea, no el prompt, es la que cambia lo que sale.
Fuentes
- Bryar, C. & Carr, B. (2021). Working Backwards: Insights, Stories, and Secrets from Inside Amazon. St. Martin's Press. (Método del comunicado de prensa y las PR-FAQ: escribir el resultado antes de construir el producto.)
- GitHub. Spec Kit: toolkit para Spec-Driven Development. Repositorio y documentación en github.com/github/spec-kit. (Enfoque de especificación ejecutable como fuente que guía la implementación asistida por IA.)
- Wiegers, K. & Beatty, J. (2013). Software Requirements, 3.ª ed. Microsoft Press. (Literatura de referencia sobre especificar requisitos y criterios de aceptación antes de construir.)