📰 Informe Diario de YouTube

Qué dice

proyecto con muchas specs; en una feature vieja sale un bug. Sin rastro de qué se pidió y por qué, depurar es arqueología.

Qué dice

cuanto más código produce la IA, menos lo revisas y menos lo controlas; el resultado no es el que tú escribirías. Eso deriva en fallos de seguridad, código inestable y programas que no pueden evolucionar.

Qué dice

hay decenas de frameworks de SDD y la comunidad está confusa sobre cuál usar. Adoptar uno sin entender el flujo te deja "copiando y pegando comandos" sin criterio.

Qué dice

hay que añadir algo al sistema —un carril nuevo, tocar el juez de tier, un refactor— y la tentación es abrir el editor y pedirle a la IA "hazlo". Eso produce código indeterminista, sin requisitos contra los que validar, y a las semanas "se rompe todo".

Qué dice

El trabajo repetitivo de SDD es pegar el mismo prompt en cada fase. Una

Matices y límites

requiere haber corrido el flujo puro al menos una vez; empaquetar sin entender reproduce el problema del framework a ciegas ([[sdd-no-casarse-con-frameworks-el-metodo-se-queda]]).

Solidez

experiencia-repetida

Qué dice

Programar lanzando prompts "a lo loco" produce código indeterminista: si le pides 10 veces lo mismo, responde 10 cosas distintas, porque el modelo contesta por probabilidad. La especificación —un documento en Markdown con contexto, historia de usuario, requisitos funcionales, casos límite, fuera de alcance y criterios de finalización— fija el *qué* y el *por qué*, y deja que el código sea solo el *cómo*. Eso mueve el resultado de "lo que a la IA le dio la gana" a "lo más determinista que seas capaz". La spec no es documentar por documentar: si genera un código que no puedes validar, no sirve.

Matices y límites

aplica al

Solidez

experiencia-repetida

Qué dice

El desarrollo profesional lleva 60 años con el mismo ciclo: planificar (qué problema, para quién, si merece la pena) → analizar requisitos → diseñar (cómo se construye) → implementar → testear → desplegar → mantener (bucle de features y bugs). Idealmente **3 fases antes de tocar código**. SDD toma ese ciclo y apoya cada fase en IA: | Clásico | SDD | |---|---| | Planificación | Constitución (`constitution.md`) | | Análisis de requisitos | Especificación + Clarificación (`spec.md`) | | Diseño | Plan técnico (`plan.md`) | | Desglose del trabajo | Tareas (`tasks.md`) | | Implementación | La IA programa, tú diriges | | Testing / QA | Validación de la spec, requisito por requisito | | Mantenimiento | Bucle: nueva spec, se repite todo salvo la constitución |

Matices y límites

el paralelismo es didáctico; en la práctica las fases se solapan y se itera (clarificación puede volver a spec, plan puede volver a clarificar).

Solidez

experiencia-repetida

Qué dice

El modo plan hace que el agente

Matices y límites

en el video Brais

Solidez

experiencia-repetida

Qué dice

Cuando surgió SDD aparecieron decenas de frameworks (Spec Kit de GitHub, BMAD, OpenSpec, Specify/RPI, Kiro como editor…). Todos hacen por debajo exactamente lo que Brais enseña a mano: prompts y skills que automatizan las fases (`/plan`, `/tasks`, etc.). Si adoptas uno **sin entender el flujo**, te conviertes en "una máquina de copiar y pegar que no sabe lo que hace" — justo lo contrario de lo que SDD busca. Lo que se ha vuelto estándar de la industria es **SDD como flujo**, no SDD-con-tal-framework: de los frameworks, ninguno se ha impuesto; hay empresas que usan uno, otras otro, otras lo abandonan.

Matices y límites

Brais no está en contra de los frameworks — *"que quieres acabar utilizando uno, fantástico"* — siempre que primero entiendas el flujo puro y decidas con criterio. Kiro/BMAD tiran más a spec-first; Spec Kit/OpenSpec más a spec-anchored.

Solidez

experiencia-repetida

Qué dice

EARS (Easy Approach to Requirements Syntax) es un molde de frases para escribir requisitos con poca ambigüedad. Patrones que menciona: -

Matices y límites

`confianza: media` — el video nombra EARS y da ejemplos pero no entra a fondo (remite a "los apuntes" del repo). Es un estándar real de ingeniería de requisitos, no un invento del curso.

Solidez

experiencia-repetida

Qué dice

El prompt de generación de tareas pide: *"tareas pequeñas, máximo 20-30 minutos cada una, en orden de dependencia, cada una con los requisitos funcionales que cubre y una línea 'Hecho cuando…' verificable, con checkboxes"*. En la corrida real el agente descompuso la spec + plan en

Matices y límites

el número de tareas depende del modelo y del effort (14 vs. 8 para el mismo proyecto). No es una métrica objetivo, es un tope de tamaño.

Solidez

experiencia-repetida

Qué dice

El prompt de implementación pide explícitamente el orden TDD: *"escribe primero los tests, luego el código. Ejecuta los tests, muéstrame el resultado"*. La validación posterior de la spec se apoya en esos tests que ya se escribieron durante la implementación, más un recorrido requisito por requisito. *"No tiene ningún sentido que el agente escriba código si no tenemos una forma de comprobarlo."*

Matices y límites

en el video Brais "da por buenos" los tests sin leerlos por tiempo, y lo marca como lo que NO se debe hacer en producción — el humano tiene que revisar también los tests que genera la IA.

Solidez

experiencia-repetida

Qué dice

Las tres formas responden a la misma pregunta —¿qué pasa con la especificación una vez el código está implementado?—: 1.

Matices y límites

es una taxonomía conceptual, no reglas rígidas — *"cada equipo lo redefine para su proyecto; en programación no hay verdades universales"*.

Solidez

experiencia-repetida

Qué dice

El vibe coding (programar "por vibras", lanzando prompts) tiene un lugar legítimo: prototipos desechables, pruebas de concepto, explorar una librería, herramientas de un solo uso o proyectos de fin de semana que van a vivir poco. Ahí no hace falta diseñar ni especificar. Pero para software profesional se rompe: sin requisitos no existe "lo correcto", solo "lo que la IA quiso hacer"; el código nunca es el que tú escribirías; la seguridad y la deuda técnica se disparan; a un mes de desarrollo, "todo se acaba rompiendo". Y no escala a equipos, empresas ni clientes. El punto más duro: tú, como vibecoder, eres una pieza prescindible del puzzle, porque escribir prompts "no tiene ningún valor" cuando se habla de software profesional; además, no aprendes en el proceso.

Matices y límites

es la opinión de alguien que vende un curso de SDD (descontar sesgo, regla 6 de `_CRITERIO.md`). El argumento de fondo —sin requisitos no hay "correcto"— es sólido; el "no tiene ningún valor" es retórico.

Solidez

opinion-sin-evidencia

Qué se dice / qué se ve

- Dice: "voy a renombrar la carpeta que ya tiene el proyecto hecho […] para que sea old-habits-cli y vamos a hacerla nueva sobre una carpeta". El proyecto: un CLI en Python para registrar hábitos de estudio y ver la racha de días consecutivos. Solo biblioteca estándar + pytest. - Se ve: El árbol del proyecto: habits-cli/ con docs/, AGENTS.md, y samples/ (que trae AGENTS.md, prompts.md, sdd.excalidraw, spec.md como plantillas). Claude Code abierto en plan mode, modelo Opus 5 (1M context), effort high. - Por qué: empezar en limpio obliga a que cada artefacto se genere por el flujo, no por copy-p

Qué se dice / qué se ve

- Dice — prompt exacto [64:08]: "Vamos a crear la constitución de un proyecto, un cliente en Python para registrar hábitos de estudio y calcular rachas. Es un proyecto educativo que debe mantener un desarrollador junior. Propónme un doc/constitution.md con seis principios innegociables, cortos, verificables, que cubran: simplicidad del stack, relación entre el spec y el código, separación entre lógica e interfaz, política de test, persistencia de datos, e idioma del código y los mensajes. Máximo 15 líneas. Espera mi aprobación." - Se ve: El prompt pegado en Claude Code con plan mode on ("shift

Qué se dice / qué se ve

- Dice — prompt exacto [71:24]: "No escribas código en ningún momento. Vamos a redactar la especificación de la primera funcionalidad de habits-cli. Lee docs/constitution.md, las normas principales que tiene que cumplir cualquier especificación. Te doy la idea inicial: un CLI con tres comandos — crear un hábito, marcarlo como hecho y listar los hábitos. Tu trabajo: hazme preguntas de una en una para eliminar ambigüedades, casos límite, comportamientos con errores que queden fuera del MVP. Máximo seis preguntas. Con mis respuestas genera dentro de la carpeta specs/001-habits-mvp/spec.md con est

Qué se dice / qué se ve

- Dice — prompt exacto [86:44]: "Lee el constitution, lee la especificación @spec.md y no escribas código. Genera plan.md con la estructura de módulos, el modelo de datos JSON, el algoritmo de cálculo, los comandos, las salidas y las decisiones técnicas." - Se ve: El árbol ya muestra specs/001-habits-mvp/ con plan.md y spec.md. El plan define: carpeta habits/ con storage, core, cli; modelo de datos; algoritmo de racha; decisiones técnicas; estrategia de test. - Por qué: es el puente de "qué" (spec, alto nivel) a "cómo" (código). El plan también se puede clarificar/retocar. Aquí decides tú, la

Qué se dice / qué se ve

- Dice — prompt exacto [90:53]: "A partir del spec y del plan genera el fichero tasks.md con tareas pequeñas, máximo de 20-30 minutos cada una, en orden de dependencia, cada una con los requisitos funcionales que cubre y una línea 'Hecho cuando…' verificable. Utiliza checkboxes." - Se ve: El agente lee spec.md, plan.md, constitution.md y AGENTS.md, y antes de escribir avisa de un hueco detectado: "plan.md nombra habits.json pero no fija dónde vive. Asumo el directorio de trabajo actual." Propone el desglose (Fase 0: esqueleto; Fase 1: almacenamiento; …) — en la corrida "inteligente" salieron 1

Qué se dice / qué se ve

- Dice — prompt exacto [102:46]: "Recorre toda la especificación requisito por requisito, del RF-1 al RF-11. Para cada uno indica qué cubre, el resultado de ejecutarlo, y si algún requisito funcional no está cubierto o falla, dilo claramente. Después comprueba los criterios de finalización y da un veredicto: ¿la spec está cumplida?" - Se ve: Recap: el repo mouredev/hello-sdd — "Curso de Spec-Driven Development (SDD) desde cero", Python 100%, con el proyecto terminado y todos los prompts. - Por qué: "no tiene sentido que el agente escriba código si no tienes forma de comprobarlo". Si el veredic