Contenido del curso
Robustez y calidad en specs ejecutables
- 5

Crea la Constitución de tu proyecto con Spec Kit
07:15 min - 6

Diseña la Spec de tu proyecto
14:52 min - 7

Cómo leer una spec: Metodologías Given-When-Then y EARS
04:59 min - 8

Comando Clarify: Casos borde, ambigüedades y supuestos
07:44 min - 9

Comando Plan: de la Spec al código
04:15 min - 10

Comando Task: tareas con orden lógico
03:45 min - 11

Comando Implement: Tu app cobra vida
04:07 min
Auditoría de specs y entrega profesional
Por qué el Vibe Coding no es escalable
Resumen
Si quieres convertir tus ideas en productos de software escalables y mantenibles, Spec-driven Development es la metodología que necesitas dominar. La pregunta clave que la explica es sencilla: ¿dónde reside la fuente de verdad de tu aplicación? La respuesta cambia todo, y aquí es donde el vibe coding empieza a mostrar sus límites.
¿Dónde reside la fuente de verdad en tu proyecto de software?
En el desarrollo tradicional y en el vibe coding, la fuente de verdad vive en el código. Si quieres entender cómo funciona una aplicación, te vas al repositorio y empiezas a leer los scripts de Python o de JavaScript para descifrar la lógica detrás de ella. A lo mucho, tienes un README como soporte [00:29].
Antes de la inteligencia artificial generativa y de los harnesses agénticos que usamos hoy, el código era casi lo único que importaba. La documentación quedaba como algo opcional, ese PDF que escribías una sola vez porque el jefe lo pidió, por normativa o por buenas prácticas [00:40].
¿Qué es la fuente de verdad en un proyecto de software? Es el lugar donde reside la información autoritativa sobre cómo debe funcionar tu aplicación. En el desarrollo tradicional es el código; en Spec-driven Development son las especificaciones.
¿Qué es Spec-driven Development y cómo cambia el código?
Con la inteligencia artificial generativa ocurre un giro importante. El código se vuelve un commodity, algo casi desechable, y lo más importante pasan a ser las especificaciones [01:30]. Esos documentos técnicos indican qué debe hacer y qué no debe hacer tu aplicación, y el código termina siendo un subproducto de ellas.
En Spec-driven Development la documentación deja de ser un documento estático. Se convierte en un artefacto vivo que da órdenes y lineamientos a la inteligencia artificial encargada de desarrollar ese código [00:55].
¿Qué diferencia hay entre vibe coding y Spec-driven Development? En el vibe coding la fuente de verdad es el código y la documentación es opcional. En Spec-driven Development las especificaciones mandan y el código se genera a partir de ellas.
¿Por qué el vibe coding no escala? El problema del spec drift
Para verlo en concreto, imagina una aplicación web que reserva canchas de pádel. Eliges una cancha de la lista, seleccionas la fecha y escoges el horario de una grilla de 24 horas [02:50]. El detalle es que las canchas solo deberían estar disponibles de 7:00 a 22:00, pero la grilla te permite reservar incluso a la 1:00 o a las 2:00 de la madrugada.
Aquí entra Claude Code, el harness agéntico que corre por detrás agentes especializados en desarrollo de software con acceso a tu repositorio [03:35]. Con un simple prompt le pides que modifique la grilla para que vaya de 7:00 a 22:00, y el cambio queda hecho en la aplicación al instante.
¿Y aquí viene lo interesante? Al revisar la documentación aparece la contradicción:
- La historia de usuario número dos dice que el usuario revisa una grilla de horarios de 24 horas [04:24].
- El functional requirement número siete indica que el sistema debe mostrar una grilla de 24 horas dividida en bloques de una hora [04:40].
- El código y la aplicación, en cambio, ya solo permiten reservas de 7:00 a 22:00.
Ese desfase entre lo que dice la documentación y lo que hace el código tiene nombre.
¿Qué es el spec drift? Es cuando la documentación y el código dejan de coincidir y pasas de tener una fuente de verdad a tener dos. El problema es que con dos fuentes contradictorias, en realidad no tienes ninguna.
¿Por qué dos fuentes de verdad rompen tu proyecto?
El vibe coding solo se interesa por modificar el código cuando le pides un cambio o una nueva funcionalidad [05:15]. Ignora la documentación, y así la especificación termina diciendo una cosa mientras la aplicación hace otra muy distinta.
Cuando eso pasa, la inteligencia artificial se encuentra con instrucciones contradictorias: lo que afirma el código frente a lo que afirma la especificación. El vibe coding no está mal, solo está limitado [06:00]. Por eso no escala.
El objetivo real es tener el control total de tu aplicación: entenderla de principio a fin, poder irte a dormir tranquilo sabiendo que mañana puedes explicarle a cualquier persona cómo funciona [02:15]. Eso es justo lo que el vibe coding no te garantiza.
¿Ya te ha pasado que la IA modifica tu código pero deja tu documentación desactualizada? Cuéntame en los comentarios cómo lo has resuelto.