Llevas toda la mañana hablando con Claude para que te añada un sistema de inventario a tu nuevo juego. Te está generando código que funciona perfectamente, hasta que lo pruebas y ves que el movimiento del personaje ya no funciona como antes. Arreglas el movimiento, pero deja de abrirse el inventario. Ya no sabes cuantas iteraciones llevas y cuantos tokens has quemado, solo sabes que el juego está peor que al principio.
Prompts en cadena, sin contexto y sin una estructura clara. Eso es el vibe coding. Funciona bien con prototipos, MVPs, o scripts aislados, pero cuando el proyecto es más grande, la IA empieza a inventarse cosas, contradecirse a si misma, a alucinar, y a generar código que compila pero no encaja en el proyecto.
El Spec-Driven Development (SDD) propone algo distinto: antes de escribir un solo prompt de generación de código, escribes una especificación. No un documento formal de cincuenta páginas, sino un texto estructurado que describe qué debe hacer el sistema, cómo está organizado, qué nodos existen, qué señales emite y qué datos maneja. Ese documento es lo primero que le pasas a la IA. Y cambia completamente la calidad del output.
Por qué Godot es un caso especialmente interesante
La mayoría de ejemplos de SDD que circulan hablan de React, APIs REST o Python. Godot es diferente por un motivo concreto: GDScript está mucho menos representado en los datos de entrenamiento de los modelos que JavaScript o Python. Eso significa que la IA alucina más. Inventa métodos que no existen, usa sintaxis de Godot 3 cuando estás en Godot 4, o genera código válido en Python pero inválido en GDScript.
Con vibe coding eso se convierte en un ciclo de correcciones interminable. Con SDD, le das a la IA el contexto que le falta: la versión exacta de Godot, los nombres reales de los nodos, la estructura de señales que ya tienes. En lugar de que la IA asuma, le estás dando los hechos.
El mismo problema, dos enfoques
Imagina que quieres añadir un sistema de inventario básico: el jugador puede recoger objetos, verlos en un panel y usarlos.
Con vibe coding, el prompt es algo así: "Añade un sistema de inventario al personaje del jugador. Tiene que poder recoger objetos y mostrarlos en pantalla." La IA genera un script que probablemente funcione en aislamiento. Pero asumirá nombres de nodos (Player, HUD, ItemSlot) que quizá no coincidan con los tuyos, usará señales que igual ya tienes definidas de otra forma, y si tu Player.gd ya tiene lógica de movimiento y de salud, es probable que el nuevo código pise alguna variable.
Con SDD, antes de pedir código escribes algo así:
Sistema: Inventario del jugador
Godot 4.3 — GDScript
Nodo raíz del jugador: CharacterBody2D ("PlayerCharacter")
Scripts existentes: player_movement.gd, player_stats.gd
Nuevo componente: InventoryComponent (Node, hijo de PlayerCharacter)
Responsabilidad: almacenar y gestionar ítems recogidos
Datos: Array[InventoryItem] donde InventoryItem es un Resource
con {id: String, name: String, quantity: int}
Señales que debe emitir:
- item_added(item: InventoryItem)
- item_removed(item: InventoryItem)
- inventory_full()
Límite: máximo 20 ítems
No debe tocar player_movement.gd ni player_stats.gd
UI: Panel separado (InventoryUI, CanvasLayer) que escucha las señales
Con ese contexto, la IA sabe exactamente en qué árbol de nodos trabajar, qué puede tocar y qué no, cómo nombrar las señales y qué estructura de datos usar. El output no solo es más correcto — es integrable directamente en tu proyecto.
Qué incluir en una spec para Godot
No hace falta que sea exhaustiva, pero sí que cubra los puntos donde la IA suele equivocarse:
- Versión de Godot y si usas C# o GDScript
- Nombre exacto y tipo de los nodos implicados
- Scripts existentes que no deben modificarse
- Señales que ya existen y las nuevas que se necesitan
- Estructura de datos (Resources, Dictionaries, clases personalizadas)
- Lo que el sistema no debe hacer — los límites son tan importantes como las funciones
No necesitas especificar la implementación interna: eso es trabajo de la IA. Necesitas especificar la interfaz: cómo se conecta con el resto del proyecto.
¿SDD es más lento?
La objeción habitual es que escribir la spec lleva tiempo. Sí, escribir esas veinte líneas de contexto lleva quizá diez minutos. Pero compara eso con el ciclo de correcciones del vibe coding: tres prompts para arreglar lo que rompió el primero, otros dos para recuperar lo que funcionaba antes, y al final código que no confías del todo en que esté bien.
SDD no es más lento. Es más predecible. Y en un proyecto de cierta envergadura, la predictibilidad vale mucho más que la velocidad inicial.
Hay algo más: la spec que escribes para la IA es también documentación de tu propio proyecto. Cuando vuelvas a ese sistema en tres meses, tendrás un documento que explica exactamente cómo funciona y cómo se integra. Con vibe coding eso no lo tienes.
La habilidad que importa
El vibe coding democratiza la generación de código, pero no democratiza la arquitectura. Saber qué especificar, a qué nivel de detalle y qué límites establecer sigue siendo una habilidad que requiere criterio técnico. La IA ejecuta bien cuando tiene contexto claro. Tu trabajo como desarrollador es dárselo.
El Spec-Driven Development no es una técnica nueva — es el hábito de pensar antes de actuar, adaptado a la era de los modelos de lenguaje. Y resulta que ese hábito, bien aplicado en Godot, marca la diferencia entre un prototipo que escala y uno que se convierte en deuda técnica desde el primer commit.