Diferencias

Muestra las diferencias entre dos versiones de la página.

--- cursos:sdd:18-spec-driven-development [2026/11/05 22:22] – ↷ El nombre de la página cambió de cursos:sdd:17-spec-driven-development a cursos:sdd:18-spec-driven-development claude
+++ cursos:sdd:18-spec-driven-development [2026/11/05 22:23] (actual) – Renumera el tema y sus referencias tras añadir el tema 7 (AGENTS.md) claude
@@ Línea 1: / Línea 1: @@
-====== 17. Spec-driven development ======
+====== 18. Spec-driven development ======
 //Spec-driven development// (SDD) es escribir **qué** tiene que hacer el software, y en qué consiste estar hecho, **antes** de que se escriba el código, y dejarlo escrito en un documento que vive en el repositorio y del que se deriva todo lo demás.
@@ Línea 119: / Línea 119: @@
 ===== 4. Por qué encaja tan bien con los agentes =====
-  * **Es ingeniería de contexto escrita y versionada.** La especificación es exactamente el contexto que quieres que el agente tenga, en un fichero que se revisa en el //pull request// en vez de en un //prompt// que se pierde ([[cursos:sdd:10-ingenieria#ingenieria_de_contexto|Ingeniería de contexto]]).
+  * **Es ingeniería de contexto escrita y versionada.** La especificación es exactamente el contexto que quieres que el agente tenga, en un fichero que se revisa en el //pull request// en vez de en un //prompt// que se pierde ([[cursos:sdd:11-ingenieria#ingenieria_de_contexto|Ingeniería de contexto]]).
-  * **Da un criterio de terminado comprobable**, que es el requisito sin el cual un bucle no puede funcionar: un objetivo demostrable y un verificador ([[cursos:sdd:10-ingenieria#ingenieria_de_bucles|Ingeniería de bucles]]).
+  * **Da un criterio de terminado comprobable**, que es el requisito sin el cual un bucle no puede funcionar: un objetivo demostrable y un verificador ([[cursos:sdd:11-ingenieria#ingenieria_de_bucles|Ingeniería de bucles]]).
-  * **Es el [[cursos:sdd:11-patrones-agenticos#pipeline_prompt_chain|pipeline]] con [[cursos:sdd:11-patrones-agenticos#human-in-the-loop_hitl|human-in-the-loop]]**, aplicado al desarrollo: pasos fijos, puerta entre paso y paso, y la persona en la puerta y no en cada línea.
+  * **Es el [[cursos:sdd:12-patrones-agenticos#pipeline_prompt_chain|pipeline]] con [[cursos:sdd:12-patrones-agenticos#human-in-the-loop_hitl|human-in-the-loop]]**, aplicado al desarrollo: pasos fijos, puerta entre paso y paso, y la persona en la puerta y no en cada línea.
   * **Cambia lo que revisas.** En teoría, una página de requisitos en vez de dos mil líneas de //diff// a las que todo el mundo acaba dando al botón verde.
   * **Las tareas trocean el trabajo en piezas que caben.** Cada tarea es un encargo pequeño y acotado, que es justamente donde un agente acierta; el encargo grande y vago es donde se pierde.
@@ Línea 130: / Línea 130: @@
   * **Falsa sensación de control.** Tener la especificación no significa que el agente la cumpla. Böckeler vio a menudo que no seguía todas las instrucciones, y otras veces que se pasaba de celo con una de ellas.
   * **Duplicados.** En su prueba con Spec Kit, el análisis previo describía clases que ya existían. El agente tomó esas descripciones como especificación nueva y las generó otra vez.
-  * **Una instrucción no es un guardarraíl.** La especificación es texto y el agente se la puede saltar, igual que cualquier otra instrucción (ver [[cursos:sdd:10-ingenieria#ingenieria_de_harneses|las capas del harnés]]). Que sea más larga no la hace más obligatoria.
+  * **Una instrucción no es un guardarraíl.** La especificación es texto y el agente se la puede saltar, igual que cualquier otra instrucción (ver [[cursos:sdd:11-ingenieria#ingenieria_de_harneses|las capas del harnés]]). Que sea más larga no la hace más obligatoria.
   * **La misma especificación no da el mismo código.** Böckeler lo comprobó con Tessl generando varias veces desde la misma especificación. Sirve para no perder la intención, no para regenerar el sistema.
@@ Línea 200: / Línea 200: @@
 </sxh>
-Esa forma de escribir —//cuando// pasa esto, el sistema //deberá// hacer esto otro— es el formato **EARS**, y no es un capricho de estilo: obliga a nombrar la condición que dispara cada comportamiento, que es exactamente donde se esconden los casos que nadie había pensado. Se ve en detalle en [[cursos:sdd:18-kiro#formato_ears|Kiro]].
+Esa forma de escribir —//cuando// pasa esto, el sistema //deberá// hacer esto otro— es el formato **EARS**, y no es un capricho de estilo: obliga a nombrar la condición que dispara cada comportamiento, que es exactamente donde se esconden los casos que nadie había pensado. Se ve en detalle en [[cursos:sdd:19-kiro#formato_ears|Kiro]].
 ==== Dónde se queda corto ====
@@ Línea 289: / Línea 289: @@
 | El diseño se decide funcionalidad a funcionalidad | La arquitectura se decide antes, y la decide una persona |
 | Demasiado //markdown// que revisar | Dos documentos que cambian poco. Lo que se revisa cada vez es el código de un //issue// |
-| El agente se salta las instrucciones | Tarea pequeña y validación contra la arquitectura. Las fronteras se comprueban con una herramienta, como ArchUnit (tema 13), no confiando en que el agente las lea |
+| El agente se salta las instrucciones | Tarea pequeña y validación contra la arquitectura. Las fronteras se comprueban con una herramienta, como ArchUnit (tema 14), no confiando en que el agente las lea |
 | La especificación deriva | La deriva se revisa de forma explícita, y Grabowski propone automatizarlo para que **bloquee el merge** |
@@ Línea 318: / Línea 318: @@
   * **Sí a especificar antes, pero con el peso en la arquitectura**: ''VISION.md'' y ''ARCHITECTURE.md'' los escribe la persona, cada cambio es un //issue// pequeño y lo que implementa la IA se valida con tests y contra la arquitectura.
-Cómo se hace SDD con [[cursos:sdd:18-kiro|Kiro]] es el tema 18.
+Cómo se hace SDD con [[cursos:sdd:19-kiro|Kiro]] es el tema 19.
 ===== Más información =====