Diferencias

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

--- cursos:sdd:12-patrones-agenticos [2026/11/05 22:22] – ↷ Enlaces adaptados debido a una operación de mover claude
+++ cursos:sdd:12-patrones-agenticos [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: @@
-====== 11. Patrones agénticos ======
+====== 12. Patrones agénticos ======
 Un patrón agéntico es una forma conocida de **conectar varias llamadas al modelo** para resolver algo que una sola llamada no resuelve bien. En el tema anterior vimos que el grafo es el mapa y el bucle es el camino; los patrones de aquí son los mapas que ya se sabe que funcionan.
-<note tip>Cada patrón de esta página se le pide al agente **con texto**, y ese texto se deja escrito como una //skill// del proyecto (tema 8) para no reescribirlo cada vez. Los ejemplos de cada sección son eso: lo que hay que poner. El primero lleva la cabecera completa del ''SKILL.md''; en el resto va solo el cuerpo, que es lo que cambia.</note>
+<note tip>Cada patrón de esta página se le pide al agente **con texto**, y ese texto se deja escrito como una //skill// del proyecto (tema 9) para no reescribirlo cada vez. Los ejemplos de cada sección son eso: lo que hay que poner. El primero lleva la cabecera completa del ''SKILL.md''; en el resto va solo el cuerpo, que es lo que cambia.</note>
 <note important>**Empieza por lo más simple que pueda funcionar.** Una llamada bien planteada con buen contexto resuelve la mayoría de las tareas. Cada patrón añade latencia, coste y sitios donde fallar, así que solo se sube de patrón cuando el anterior se queda corto de verdad, no porque quede mejor en el diagrama.</note>
@@ Línea 41: / Línea 41: @@
 </uml>
-Es el patrón del //spec-driven development//: requisitos → diseño → tareas → código, con una aprobación en cada salto (tema 17). Cada paso ve un problema más pequeño y mejor acotado que el original, y por eso lo hace mejor.
+Es el patrón del //spec-driven development//: requisitos → diseño → tareas → código, con una aprobación en cada salto (tema 18). Cada paso ve un problema más pequeño y mejor acotado que el original, y por eso lo hace mejor.
   * **A favor**: cada paso es simple, verificable y depurable por separado.
@@ Línea 229: / Línea 229: @@
 </uml>
-Es la capa 5 del harnés (tema 10) convertida en patrón. Funciona cuando se cumplen las dos condiciones:
+Es la capa 5 del harnés (tema 11) convertida en patrón. Funciona cuando se cumplen las dos condiciones:
   - **Hay criterios claros** contra los que evaluar. Sin eso el revisor opina, y opinar no converge.
@@ Línea 274: / Línea 274: @@
   * **Contra la especificación**: buscar el requisito ambiguo, el caso que no se contempló, la contradicción entre dos apartados. Sale mucho más barato aquí que en producción.
-  * **Contra la implementación**: generar los tests que la rompen, no los que la confirman. Emparejado con el //mutation testing// del tema 12, que mide exactamente eso.
+  * **Contra la implementación**: generar los tests que la rompen, no los que la confirman. Emparejado con el //mutation testing// del tema 13, que mide exactamente eso.
   * **Contra la seguridad**: el papel de //red team//.
@@ Línea 501: / Línea 501: @@
 Los patrones **se combinan**, y casi siempre se usan combinados. Las dos combinaciones que aparecen una y otra vez en desarrollo con IA:
-  * **Planificador → HITL → Pipeline → Ejecutor-Revisor**: se planifica, una persona aprueba el plan, se ejecuta por fases y cada fase pasa por revisión. Es, punto por punto, lo que hace [[cursos:sdd:19-kiro|Kiro]] (tema 18).
+  * **Planificador → HITL → Pipeline → Ejecutor-Revisor**: se planifica, una persona aprueba el plan, se ejecuta por fases y cada fase pasa por revisión. Es, punto por punto, lo que hace [[cursos:sdd:19-kiro|Kiro]] (tema 19).
   * **Orquestador → trabajadores → Adversario**: se reparte el trabajo grande y al final un agente intenta romper el resultado unificado.