MENU
En ocasiones, el desarrollo de código con agentes se parece más a una ruleta rusa que a otra cosa.
Le pides a tu agente que construya una aplicación. Y funciona.
Vuelves al día siguiente, le pides la siguiente pieza… y ya no encaja con lo anterior.
Ha asumido algo que no era.
Ha cambiado un fichero para arreglar algo y ha roto algo que antes funcionaba.
Y acabas en esa conversación infinita de... "no, esto no era así, arréglalo".
¿Te suena?
No es culpa del modelo. Y cambiar a uno más potente no te va a salvar (al menos, no para siempre).
Porque el problema es que nunca le dijiste, por escrito, qué querías exactamente.
Esa es la idea que recorre estas dos sesiones de 1h30 cada una de la Comunidad, en las que hablamos sobre Spec-Driven Development (SDD): un marco de trabajo para desarrollar con agentes de IA a partir de especificaciones, en vez de a golpe de prompt.
Y lo hacemos construyendo una aplicación desde cero.
En la primera sesión escribimos la especificación completa sin tocar una línea de código.
En la segunda, cerramos el círculo implementando, validando y nos solucionando algunos conflictos que van apareciendo entre lo que habíamos especificado y lo que la tecnología elegida nos deja hacer.
Los modelos de lenguaje escriben código sorprendentemente bien.
De ahí nació el vibe coding: pedirle a un agente lo que quieres y dejarle hacer.
Funciona muy bien… pero solo a veces.
Y ese "a veces" es el problema porque cuando el proyecto crece, aparecen siempre los mismos tres fallos:
Los tres tienen la misma raíz: el agente no tiene el contexto que sí tiene el equipo.
Y todo eso se traduce en una deuda cognitiva que asumes tú.
El agente escribe código muy rápido y tú acabas con una carga enorme de revisar qué ha hecho y si es lo que querías realmente.
La solución es tan simple como poco glamourosa: escribirlo.
Redactar un contrato lo bastante detallado como para que el agente no tenga que asumir nada.
Eso es una especificación: contexto para el agente, escrito, versionado y atado al proyecto.
SDD invierte el orden de trabajo:
Pondremos mucho esfuerzo previo antes de que se escriba una sola línea de código y todo gira en torno a cuatro preguntas:
En la sesión vemos el método para escribir esa especificación.
Todo parte de un documento base, la Constitución, formada por tres ficheros Markdown:
A partir de ahí, el trabajo es un bucle que se repite por cada característica:
Cada característica vive en su propia rama de git y la especificación se trata como si fuera código, como un fichero más.
Ese bucle lo recorremos al completo de forma práctica entre las dos sesiones.
Construimos una aplicación web que convierte audio en texto para creadores de contenido.
Partimos de lo que han pedido los distintos departamentos (marketing, producto, legal e IT), con sus requisitos y sus restricciones. A partir de ahí creamos los tres documentos de la Constitución y la planificación de la primera fase.
Sin escribir una sola línea de código. Que es justo el punto.
Y aquí está lo interesante: esta misma aplicación ya se construyó antes a base de vibe coding, aplicando buenas prácticas pero sin usar Spec-Driven Development.
Comparar ambos recorridos es la forma más clara de ver qué aporta SDD.
Puedes ver cómo creamos paso a paso una webapp de transcripción de audio a texto en Claude Code desde CERO. Y si quieres verlo con todo el detalles, la sesión de Claude Code lo lleva más lejos.
Si no programas a diario, empezar por ahí es el punto de partida natural de este recorrido.
🎥 La encontrarás a continuación.
La primera sesión termina con un plan impecable y muy poquito código.
La segunda es la prueba de fuego:
¿podrá un agente construir lo que queremos a partir de la especificación?
Lo veremos recorriendo el flujo de trabajo de SDD para desarrollar una característica entera.
Además, en esta segunda parte vemos que el método no depende de ninguna herramienta concreta ya que cambiamos de modelo a mitad del desarrollo sobre los mismos ficheros, e incluso probamos a conectar un modelo ejecutándose en local.
La especificación no se entera.
🎥 La encontrarás a continuación.
Si ya usas Claude Code, Codex, Cursor o similares pero sientes que en proyectos algo grandes acabas peleando más de lo que avanzas. Esto es para ti.
Si trabajas en equipo y te preocupa que cada uno desarrolle a su estilo con su propio agente y que luego nada encaje. Esto también es para ti.
Si no programas a diario, pero quieres entender cómo se está ordenando el desarrollo asistido por IA y qué metodología hay detrás. Esto sobre todo es para ti.
Entre la primera y la segunda sesión rehicimos la Constitución del proyecto:
Es un cambio deliberado y, en el fondo, la mejor demostración del método: cuando algo cambia, se cambia sobre plano y el código se reconstruye a partir de ahí.
Algunas de las preguntas que surgieron en directo:
Sirve para ambos. En un proyecto heredado se añade una fase previa de diagnóstico en la que el agente analiza la base de código existente para averiguar de dónde partes, y de ahí sale el documento de stack tecnológico. Tiene además una ventaja concreta de la que se habló en directo: evita que el agente relea el proyecto entero una y otra vez, con el gasto de tokens que eso supone.
Tratando la especificación como si fuera código: se versiona igual, viaja en ramas igual y, si dos personas tocan los mismos documentos, habrá conflictos que resolver antes de mergear, igual que con cualquier función. Y esos conflictos también conviene resolverlos pidiéndoselo al agente.
Sí, y es justo el punto de partida ideal. Los requisitos del cliente son la materia prima de la primera fase, la que alimenta la entrevista de la que sale la Constitución.
En esencia, sí. Es una metodología para ordenar los pasos y la información. Su valor crece cuanto más grande es el proyecto o el equipo, y cuando hay que traspasar o mantener el trabajo.
No. Ni aunque sea un detalle mínimo. Cualquier cambio mejor pídeselo al agente, porque lo que tú tocas en un documento puede tener implicaciones en otros sitios, y en cuanto hay código escrito a partir de esos documentos ya no eres capaz de ver todo lo que arrastra ese cambio.
No. En la segunda sesión se cambia de modelo a mitad del desarrollo, sobre los mismos ficheros y sin tocar nada, e incluso se conecta un modelo ejecutándose en local. La especificación es un contrato en texto plano, así que funciona igual con Claude, con Codex o con lo que uses.
No, y es un paso posterior. Lo que SDD te da es un plan partido en grupos de tareas independientes, que es justo lo que necesitas para poder repartirlos entre varios agentes (o entre varias personas) sin que colisionen. Primero la especificación, luego el reparto.