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 anets 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 esta sesión de 1h30 de la Comunidad, en la 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.
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 y que repasamos en la seisón al completo y de forma práctica.
Construiremos 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 y IT), con sus requisitos y sus restricciones y, 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.
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.
La sesión completa, con la demo en directo y el resto del archivo de sesiones de la Comunidad, está disponible para miembros.
🎥 La encontrarás a continuación.
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.