logongas

Herramientas de usuario

Herramientas del sitio

Ocultar Menú
Traza:
cursos:sdd:presentacion

Diferencias

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

Enlace a la vista de comparación

Próxima revisión		Revisión previa
cursos:sdd:presentacion [2026/11/02 11:59] – Nueva presentación de una hora: cómo se programa con IA claudecursos:sdd:presentacion [2026/11/02 15:04] (actual) – Añade patrones agénticos antes de guardarraíles deterministas claude
Línea 1: Línea 1:
 ====== Cómo se programa con IA ====== ====== Cómo se programa con IA ======
  
-Una hora para ver cómo se programa hoy con un agente: qué es, qué hay que darle y cómo se comprueba lo que hace. Todo con el mismo ejemplo, una API REST de pedidos en Spring Boot. Cada bloque enlaza con el tema del curso que lo desarrolla.+===== 1. Se programa en OpenCode, no en un IDE =====
  
-^ Minutos ^ Bloque ^ +El agente vive en la terminal y trabaja sobre la carpeta del proyecto. Tú le pides, él edita y lanza órdenes. Es de código abierto y habla con cualquier proveedor.
-|  5 | [[#lo_caro_ya_no_es_escribir_codigo|1. Lo caro ya no es escribir código]] | +
-|  10 | [[#el_agente|2. El agente]] | +
-|  10 | [[#el_contexto|3. El contexto]] | +
-|  10 | [[#especificar_antes_de_implementar|4. Especificar antes de implementar]] | +
-|  10 | [[#comprobar_lo_que_hace|5. Comprobar lo que hace]] | +
-|  10 | [[#demoexportar_los_pedidos|6. Demo: exportar los pedidos]] | +
-|  5 | [[#por_donde_empezar|7. Por dónde empezar]] |+
  
-----+[[cursos:sdd:03-opencode|OpenCode]]: instalarlo y conectar proveedores.
  
-===== 1. Lo caro ya no es escribir código =====+===== 2. OpenCode se mete dentro de Orca o herdr =====
  
-Escribir código ha dejado de ser lo caro. Lo caro es **decir bien qué hay que hacer** y **saber si lo que ha salido está bien**.+Son el «IDE» de hoy: ejecutan tus agentes, cada uno en su //worktree//, y avisan de cuál te necesita. Usa **Orca**, que además deja revisar y comentar el //diff//. **herdr** si quieres quedarte en la terminal.
  
-Un proyecto real hecho con agentes, en líneas sin blancos ni comentarios:+[[cursos:sdd:03-herdr#orcahacia_un_ide_de_agentes|herdr y Orca comparados]]: qué tiene cada uno.
  
-^ ^ Líneas ^ +===== 3. Precios: API o suscripción =====
-| Aplicación (''src/main'') |  33.681 | +
-| Tests (''src/test'') |  42.436 | +
-| Instrucciones para el agente (//skills//, agentes, ficheros de contexto) |  30.527 |+
  
-Hay más líneas de tests que de aplicación, y casi tantas de instrucciones como de aplicación. Ahí es donde se ha ido el trabajo, que ahora son tres cosas:+  * **API**: se paga por //token//. Para probar o para un uso puntual. 
 +  * **Suscripción**: pago fijo con límite de uso. Para trabajar a diario: sale mucho más barata.
  
-  * **Especificar**: decidir qué se hace. +Por API, en dólares por millón de //tokens// de entrada, en OpenRouter con el proveedor oficial (2 de noviembre de 2026):
-  * **Dar contexto**: que el agente tenga lo que necesita. +
-  * **Comprobar**: que lo que hizo sirve.+
  
-<note important>El agente escribe, pero la responsabilidad sigue siendo tuya. Si no sabes juzgar el código que sale, tampoco sabes programar con IA.</note>+^ Modelo ^  Entrada ^ 
 +| Claude Haiku 5.5 (hasta 100.000 //tokens// de entrada) |  0,10 | 
 +| DeepSeek V4.1 Flash |  0,15 | 
 +| Claude Haiku 5.5 (a partir de 100.000) |  0,50 | 
 +| GLM 5.3 |  1,40 | 
 +| Kimi K3.1 Pro |  2 | 
 +| Claude Sonnet 5.5 |  2 | 
 +| Claude Opus 5.5 |  4 | 
 +| Claude Fable 5.1 |  10 |
  
-----+Por suscripción, en dólares al mes:
  
-===== 2. El agente =====+^ Plan ^  Precio ^ Modelos ^ 
 +| OpenCode Go |  10 y 40 | Modelos abiertos: Kimi, DeepSeek, GLM... | 
 +| GLM Coding Plan |  18, 72 y 160 | GLM | 
 +| Kimi |  19, 39, 99 y 199 | Kimi | 
 +| Claude |  20, 100 y 200 | Haiku, Sonnet, Opus |
  
-El **modelo** recibe texto y genera texto. Tres rasgos que condicionan todo lo demás:+{{:cursos:sdd:precios-planes.jpeg?600}}
  
-  * **No tiene memoria**: cada petición empieza de cero. +[[https://openrouter.ai/models|OpenRouter]]: los precios actualizados de cada modelo y proveedor.
-  * **No es determinista**: la misma petición dos veces da dos códigos distintos. +
-  * **Su conocimiento tiene fecha**: no sabe nada de tu proyecto, y lo que no sabe se lo inventa con toda seguridad.+
  
-Un **agente** es ese modelo metido en un **bucle con herramientas**. Un chat te da texto; el agente actúa y ve las consecuencias: si el test falla, lee el error y corrige el código.+===== 4. Skills y MCP =====
  
-<uml> +  * **Skill**: cómo se hace una tarea en tu equipo. Solo ocupa contexto cuando la tarea encaja. 
-start +  * **MCP**: herramientas nuevas: el navegador, la base de datos, la documentación actual. Ocupa contexto siempre, así que conecta solo los que uses.
-:petición; +
-repeat +
-  :decidir el paso siguiente; +
-  :usar una herramienta; +
-  :ver el resultado; +
-backward:seguir; +
-repeat while (¿terminado?) is (no) not (sí) +
-:responder; +
-stop +
-</uml>+
  
-El programa que monta el bucle es [[cursos:sdd:03-claude-code|Claude Code]] u [[cursos:sdd:03-opencode|OpenCode]]. Los dos viven en la terminal y trabajan sobre la carpeta en la que se lanzan:+Empieza por las //skills//: son ficheros de texto.
  
-<sxh bash> +[[cursos:sdd:02-conceptos-basicos#que_usar_para_cada_problema|Qué usar para cada problema]]: el problema que tienes y la pieza que lo resuelve.
-cd pedidos +
-claude +
-</sxh>+
  
-Trabajan en dos modos, y se cambia con ''Mayús+Tab'' en Claude Code:+===== 5. El contexto =====
  
-  * **Plan**: lee, analiza y propone un plan sin editar nada. +Es todo lo que ve el modelo, y se le manda entero en cada turno. Cuanto más lleno, peor trabaja y más cuesta.
-  * **Build**: edita ficheros y lanza órdenes.+
  
-Una petición sirve cuando lleva **objetivo, restricciones y criterio de terminado**:+  * **No pases del 40 % de la ventana.** 
 +  * **Una tarea, una sesión**: al cambiar de tarea, ''/clear''. 
 +  * **Lo fijo, corto**: ''AGENTS.md'' se carga siempre.
  
-<sxh markdown> +[[cursos:sdd:02-conceptos-basicos#el_contexto|El contexto]]: qué entra y cómo se llena.
-Malo:  arregla este código+
  
-Bueno: arregla el NullPointerException de PedidoService.calcularTotal, +===== 6. Agentes =====
-       explica qué estaba mal, no cambies la firma pública del método +
-       y deja pasando los tests de PedidoServiceTest +
-</sxh>+
  
-Más información: [[cursos:sdd:02-conceptos-basicos|Conceptos básicos]] e [[cursos:sdd:04-ingenieria#ingenieria_de_prompts|Ingeniería de prompts]].+Un subagente hace un trozo del trabajo en **su propia ventana de contexto** y devuelve un resumen. Sirve para lo que leería demasiado o para revisar sin fiarse de quien implementó.
  
-----+La //skill// dice cómo se hace; el agente, quién lo hace y cuándo para. Casi todo son //skills//: en un proyecto real, 28.211 líneas de //skills// y 134 de agentes.
  
-===== 3. El contexto =====+[[cursos:sdd:07-agentes|Agentes]]: cómo se escribe uno.
  
-El contexto es **todo lo que ve el modelo** en una petición. Como no tiene memoria, en cada turno se le manda entero: las instrucciones, la conversación y **cada fichero que ha leído y cada salida de orden**.+===== 7. ¿Hace falta conocer el framework o el lenguaje? =====
  
-<note important>**No pases del 40 % de la ventana.** Cuanto más llena está, peor trabaja, mucho antes de llegar al tope. Una tarea, una sesión: al cambiar de tarea, ''/clear''.</note>+La IA los conoce mejor que tú: la sintaxis y la API las pone ella. El problema es que **hay que revisar el código**, y no puedes revisar lo que no entiendes. Hay que conocerlos lo suficiente para leerlos y juzgarlos, no para escribirlos de memoria.
  
-Lo que hay que repetirle en cada sesión se escribe en ''AGENTS.md'', en la raíz del repositorio. Lo leen todos los agentes y se carga entero en todas las sesiones, así que tiene que ser pequeño:+[[cursos:sdd:09-mcp#context7|Context7]]: la documentación actual de cada librería, dentro del agente.
  
-<sxh markdown;title:AGENTS.md> +===== 8. SDD: especificar antes de programar =====
-# Pedidos+
  
-API REST de pedidos. Compilar y probar: `./mvnw verify`. +«Hay que poder exportar los pedidos» esconde cinco decisiones, y el agente las toma solo y sin avisar. SDD las saca a documentos antes del código, y esos documentos son la entrada del agente. **Entre fase y fase, una persona aprueba.**
- +
-- Los importes son `BigDecimal` con escala 2; nunca `double`. +
-- Antes de crear cualquier clase, lee `.claude/skills/arquitectura/SKILL.md`. +
-</sxh> +
- +
-Para cada problema, una pieza: +
- +
-^ El problema ^ Lo que necesitas ^ +
-| «Tengo que repetirle lo mismo en cada sesión» | Una línea en ''AGENTS.md'' | +
-| «Cada vez lo hace distinto» | Una [[cursos:sdd:08-skills|skill]]: un ''SKILL.md'' que dice cómo se hace esa tarea en tu equipo | +
-| «Se inventa los datos» o «no puede consultarlo» | Un servidor [[cursos:sdd:09-mcp|MCP]]: herramientas nuevas | +
-| «Se llena el contexto» | Un [[cursos:sdd:07-agentes|subagente]]: trabaja en su propia ventana y devuelve un resumen | +
-| «No sé por dónde empieza» | Ninguna: falta especificación | +
- +
-<note tip>Empieza siempre por ''AGENTS.md'' y las //skills//: son ficheros de texto y arreglan la mitad de los problemas.</note> +
- +
-Más información: [[cursos:sdd:02-conceptos-basicos#el_contexto|El contexto]] e [[cursos:sdd:04-ingenieria#ingenieria_de_contexto|Ingeniería de contexto]]. +
- +
----- +
- +
-===== 4. Especificar antes de implementar ===== +
- +
-La petición, tal y como llega: +
- +
-<sxh markdown> +
-hay que poder exportar los pedidos +
-</sxh> +
- +
-Ahí hay cinco decisiones escondidas, y el agente las va a tomar por su cuenta sin avisar: +
- +
-  * ¿En qué formato? +
-  * ¿Qué pedidos: todos, los del usuario, los que su rol puede ver? +
-  * ¿Cuántos? Diez y diez millones no se resuelven igual. +
-  * ¿En el momento, o se genera y se avisa al terminar? +
-  * ¿Qué pasa si no hay ninguno? +
- +
-El resultado compila, pasa los tests y no es lo que pedías. Un error en los requisitos se corrige cambiando una frase; en el código, rehaciendo el trabajo y los tests. +
- +
-//Spec-driven development// (SDD) saca esas decisiones a un documento, antes del código. El trabajo se parte en fases, y **entre fase y fase hay una persona que aprueba**: +
- +
-<uml> +
-start +
-:petición; +
-repeat +
-  :requisitos: el QUÉ; +
-  :aprobación humana; +
-  :diseño: el CÓMO; +
-  :aprobación humana; +
-  :tareas: el plan; +
-  :implementación; +
-  :verificación; +
-backward:corregir la especificación; +
-repeat while (el código desmiente la spec) is (sí) not (no) +
-:entregado; +
-stop +
-</uml>+
  
 ^ Documento ^ Qué contesta ^ ^ Documento ^ Qué contesta ^
-| ''requirements.md'' | Qué tiene que pasar y cómo se comprueba | +| ''requirements.md'' | El QUÉ: qué tiene que pasar y cómo se comprueba | 
-| ''design.md'' | Cómo se va a hacer: arquitectura, modelo de datos, decisiones | +| ''design.md'' | El CÓMO: arquitectura, modelo de datos, decisiones | 
-| ''tasks.md'' | El plan: pasos pequeños, ordenados y verificables uno a uno | +| ''tasks.md'' | El plan: pasos pequeños y verificables |
- +
-Cada requisito se escribe para que se pueda comprobar:+
  
-<sxh markdown> +[[cursos:sdd:10-spec-driven-development|Spec-driven development]]: el flujo completo.
-Cuando un usuario solicita la exportación de pedidos, el sistema DEBERÁ +
-generar un fichero CSV con los pedidos visibles para su rol. +
-Si la consulta supera los 10.000 pedidos, el sistema DEBERÁ generarlo +
-en segundo plano y avisar por correo al terminar. +
-Si no hay ningún pedido, el sistema DEBERÁ informar de ello y no +
-generar ningún fichero. +
-</sxh>+
  
-  * **No es cascada**: se especifica una funcionalidad pequeña, no el sistema entero, y se vuelve atrás cuando hace falta. +==== ¿Realmente funciona? ====
-  * **Revisas otra cosa**: una página de requisitos en vez de dos mil líneas de //diff//. +
-  * **Si cabe en una frase sin ambigüedad, no se especifica**: un arreglo de una línea va directo.+
  
-<note warning>Las aprobaciones valen lo que valga la lectura. Aprobar los requisitos sin leerlos es peor que no tener puerta: da sensación de control sin el control.</note>+No como dogma. La prueba de Scott Logic: Spec Kit frente a su forma habitual, con incrementos pequeños y prompts sencillos:
  
-Más información: [[cursos:sdd:10-spec-driven-development|Spec-driven development]].+^ ^ Agente ^ Revisión humana ^ Markdown ^ Código ^ 
 +| Con Spec Kit | 33 min | 3,5 h | 2.577 líneas | 689 líneas | 
 +| Sin especificación | 8 min | 24 min | 0 | 1.000 líneas |
  
-----+Especifica lo que no cabe en una frase, y que la especificación sea corta: lo que vale es el diseño, no el volumen de //markdown//.
  
-===== 5. Comprobar lo que hace =====+[[https://blog.scottlogic.com/2025/11/26/putting-spec-kit-through-its-paces-radical-idea-or-reinvented-waterfall.html|Putting Spec Kit through its paces]]: ¿idea radical o cascada reinventada?
  
-El agente no es determinista y dice «listo» con la misma seguridad cuando está bien y cuando no. Lo que vale es lo que se comprueba, y **lo comprueba el propio agente dentro de su bucle**: escribe, lanza la comprobación, lee el resultado y corrige hasta que pasa.+===== 9. SDD centrado en la arquitectura =====
  
-^ Comprobación ^ Quién juzga ^ Qué pilla ^ +Variante de SDD: el documento principal no describe cada funcionalidad, sino la **estructura del sistema**: fronteras, interfaces, responsabilidades y decisiones técnicas. Tú defines la arquitectura y la IA la implementa.
-| Compilador y tests | Regla fija | Lo que se rompe y lo que no cumple la spec | +
-| [[cursos:sdd:15-herramientas-deterministas|SonarQube, Snyk]] | Regla fija | Duplicación, código sin test, dependencias vulnerables | +
-| Otro agente que revisa | Un modelo | Lo que no se puede escribir como regla. Se puede equivocar |+
  
-Primero lo determinista, que da siempre el mismo resultado. El modelo, para lo que queda.+  * ''VISION.md'' y ''ARCHITECTURE.md'' en el repositorio: el contexto de cada tarea. 
 +  * Tareas pequeñas, abarcables en una sola interacción. 
 +  * Cada resultado se valida con tests y contra la arquitectura.
  
-<note warning>El revisor tiene que ser **otro agente**, en otra sesión. Un modelo que revisa su propia salida tiende a aprobarla.</note>+Su punto débil: nadie escribe los criterios de aceptación de cada funcionalidad.
  
-<note important>Un agente al que le falla un test puede «arreglarlo» cambiando el test. En el //diff//, lo primero que se mira son los tests.</note>+[[cursos:sdd:10-spec-driven-development#sdd_centrado_en_la_arquitectura|SDD centrado en la arquitectura]]: la explicación completa.
  
-Cuando el agente se equivoca, no se corrige solo esa salida: **se cambia el sistema para que el error no vuelva a ocurrir**. Si usa ''double'' para un importe:+==== Tú haces la arquitectura, la IA escribe el código ====
  
-  - Se añade la regla a ''AGENTS.md''. +La IA es una máquina de implementar: funciona cuando ya has tomado las decisiones difíciles. Multiplica lo que sabes, no lo sustituye.
-  - Si lo vuelve a hacer, se escribe un test de arquitectura que falle: una instrucción se puede ignorar, un test en rojo no.+
  
-<note warning>El modo que no pregunta antes de ejecutar (''Auto'' en Claude Code) solo con todo commiteado, para poder volver atrás.</note>+[[https://meshintelligence.substack.com/p/the-architecture-first-approach|The Architecture-First Approach]]: visión, arquitectura, tareas pequeñas y una implementación cada vez.
  
-Más información: [[cursos:sdd:04-ingenieria#ingenieria_de_harneses|Ingeniería de harneses]] y [[cursos:sdd:05-patrones-agenticos#ejecutor-revisor|patrón Ejecutor-Revisor]].+==== El diseño detallado, antes que el código ====
  
-----+Si le dejas, decide él el alcance, los componentes y las interfaces. Se acuerda de lo abstracto a lo concreto: capacidades, componentes, interacciones y contratos. Hasta entonces, ni una línea de código.
  
-===== 6. Demo: exportar los pedidos =====+[[https://www.martinfowler.com/articles/reduce-friction-ai/design-first-collaboration.html|Design-First Collaboration]]: los cinco niveles de diseño.
  
-La funcionalidad del bloque 4, de principio a fin, con [[cursos:sdd:11-kiro|cc-sdd]]: el flujo de SDD empaquetado como //skills// para el agente que ya usas.+==== El prompt se puede ignorar, la arquitectura no ====
  
-  * Instalarlo en el proyecto, una sola vez: +Tú escribes el esqueleto (clases base, contratos, seguridad, gestión de errores) y la IA rellena los huecos. No puede saltarse lo que no controla.
-<sxh bash> +
-npx cc-sdd@latest --claude-skills --lang es +
-</sxh>+
  
-  * Crear la memoria del proyecto, una sola vez. Lee el repositorio y escribe el producto, el //stack// y las convenciones en ''.kiro/steering/'': +[[https://www.infoq.com/articles/skeleton-architecture|Skeleton Architecture]]: el esqueleto lo pones tú, el tejido la IA.
-<sxh bash> +
-/kiro-steering +
-</sxh>+
  
-  * Crear la especificación. El nombre de la carpeta lo genera él: +==== Una tarea pequeña cada vez ====
-<sxh bash> +
-/kiro-spec-init Exportar a CSV los pedidos que el rol del usuario puede ver, en segundo plano si son más de 10.000 +
-</sxh>+
  
-  * Requisitos. Se lee ''requirements.md'' y se corrige lo que no sea: +Se pide un trozo, se prueba y se sigue. Si sale mal, no le pidas que lo deshaga: vuelve al último punto bueno y empieza una sesión nueva con más límites.
-<sxh bash> +
-/kiro-spec-requirements exportar-pedidos +
-</sxh>+
  
-  * Diseño. ''-y'' significa «he leído los requisitos y me valen»: +[[https://replit.discourse.group/t/pair-programming-with-replits-ais/33|Pair programming con la IA]]: el ciclo de planificar, implementar, probar y volver atrás.
-<sxh bash> +
-/kiro-spec-design exportar-pedidos -y +
-</sxh>+
  
-  * Tareas. ''-y'' aprueba ahora el diseño: +===== 10. Patrones agénticos =====
-<sxh bash> +
-/kiro-spec-tasks exportar-pedidos -y +
-</sxh>+
  
-  * Implementación: +Le pides algo a la IA y lo hace mal. Le dices que lo revise y encuentra el error. ¿WTF? La IA es así y hay que vivir con ello. Programar con IA es saber trabajar con ella para que funcione bien, y para eso hay una serie de patrones:
-<sxh bash> +
-/kiro-impl exportar-pedidos +
-</sxh>+
  
-  * Revisión, en una sesión nueva (''/clear''), para que no se fíe de lo que hizo: +^ Patrón ^ En qué consiste ^ 
-<sxh markdown> +| Planificador-Ejecutor | Uno hace el plan y se revisa antes de tocar nada | 
-Compara el diff de esta rama con .kiro/specs/exportar-pedidos/requirements.md. +| Ejecutor-Revisor | Uno hace el trabajo y otro lo revisa con criterios claros | 
-Para cada requisito, di si está implementado y qué test lo cubre. +| Adversarios | Uno intenta romper lo que ha hecho el otro | 
-No arregles nada. +| Razonador-Refutador | Uno propone la causa de un fallo y otro intenta desmontarla | 
-</sxh>+| Best-of-N | Varios intentos, y se queda el mejor |
  
-----+Empieza por lo más simple: cada patrón añade coste y tiempo.
  
-===== 7. Por dónde empezar =====+[[cursos:sdd:05-patrones-agenticos|Patrones agénticos]]: todos, con su ejemplo.
  
-  - Instala [[cursos:sdd:03-claude-code|Claude Code]], o [[cursos:sdd:03-opencode|OpenCode]] si quieres empezar con modelos gratuitos. +===== 11. Guardarraíles deterministas =====
-  - Crea un ''AGENTS.md'' de diez líneas: cómo se compila, cómo se prueba y las reglas que no se deducen del código. +
-  - Coge una tarea pequeña y hazla en modo Plan: lee el plan antes de dejarle tocar nada. +
-  - Una tarea, una sesión. ''/clear'' entre tareas. +
-  - Cada vez que se equivoque en lo mismo, escríbelo en ''AGENTS.md''. +
-  - Cuando la tarea no quepa en una frase, especifica.+
  
-<note tip>**Empieza por lo más simple que pueda funcionar.** Un agente con buen contexto y buenos tests resuelve la mayoría de las tareas. Varios agentes coordinados y bucles desatendidos, solo cuando esto se quede corto.</note>+Como no se acaba de confiar en la IA, se añade software determinista: da siempre el mismo resultado. El agente lo lanza en su bucle y corrige hasta que pasa:
  
-Lo que no ha cabido en esta hora:+  * **JUnit**: que hace lo que tiene que hacer. 
 +  * **ArchUnit**: que respeta la arquitectura. 
 +  * **Métricas**: cobertura, complejidad ciclomática, CRAP.
  
-^ Tema ^ Para qué ^ +[[cursos:sdd:15-herramientas-deterministas|Herramientas deterministas]]: SonarQube, Snyk y cómo meterlas en el bucle.
-| [[cursos:sdd:08-skills|Skills]] y [[cursos:sdd:19-creando-skills|Estructura de un skill]] | Dejar escrito cómo se hace cada tarea en tu equipo | +
-| [[cursos:sdd:07-agentes|Agentes]] | Escribir subagentes propios | +
-| [[cursos:sdd:03-herdr|herdr]] y [[cursos:sdd:03-orca|Orca]] | Llevar varios agentes a la vez | +
-| [[cursos:sdd:05-patrones-agenticos|Patrones agénticos]] | Combinar agentes: revisores, adversarios, orquestadores | +
-| [[cursos:sdd:04-ingenieria#ingenieria_de_bucles|Ingeniería de bucles]] | Dejar a un agente trabajando solo |+
  
cursos/sdd/presentacion.1793617165.txt.gz · Última modificación: por claude