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.

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.

Un proyecto real hecho con agentes, en líneas sin blancos ni comentarios:

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:

• Especificar: decidir qué se hace.
• Dar contexto: que el agente tenga lo que necesita.
• Comprobar: que lo que hizo sirve.

El modelo recibe texto y genera texto. Tres rasgos que condicionan todo lo demás:

• No tiene memoria: cada petición empieza de cero.
• 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.

El programa que monta el bucle es Claude Code u OpenCode. Los dos viven en la terminal y trabajan sobre la carpeta en la que se lanzan:

cd pedidos
claude

Trabajan en dos modos, y se cambia con Mayús+Tab en Claude Code:

• Plan: lee, analiza y propone un plan sin editar nada.
• Build: edita ficheros y lanza órdenes.

Una petición sirve cuando lleva objetivo, restricciones y criterio de terminado:

Malo:  arregla este código

Bueno: arregla el NullPointerException de PedidoService.calcularTotal,
       explica qué estaba mal, no cambies la firma pública del método
       y deja pasando los tests de PedidoServiceTest

Más información: Conceptos básicos e Ingeniería de prompts.

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.

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:

# Pedidos

API REST de pedidos. Compilar y probar: `./mvnw verify`.

- Los importes son `BigDecimal` con escala 2; nunca `double`.
- Antes de crear cualquier clase, lee `.claude/skills/arquitectura/SKILL.md`.

Para cada problema, una pieza:

Más información: El contexto e Ingeniería de contexto.

La petición, tal y como llega:

hay que poder exportar los pedidos

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:

Cada requisito se escribe para que se pueda comprobar:

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.

• No es cascada: se especifica una funcionalidad pequeña, no el sistema entero, y se vuelve atrás cuando hace falta.
• 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.

Más información: Spec-driven development.

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.

Primero lo determinista, que da siempre el mismo resultado. El modelo, para lo que queda.

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:

1. Se añade la regla a AGENTS.md.
2. Si lo vuelve a hacer, se escribe un test de arquitectura que falle: una instrucción se puede ignorar, un test en rojo no.

Más información: Ingeniería de harneses y patrón Ejecutor-Revisor.

La funcionalidad del bloque 4, de principio a fin, con cc-sdd: el flujo de SDD empaquetado como skills para el agente que ya usas.

• Instalarlo en el proyecto, una sola vez:

npx cc-sdd@latest --claude-skills --lang es

• Crear la memoria del proyecto, una sola vez. Lee el repositorio y escribe el producto, el stack y las convenciones en .kiro/steering/:

/kiro-steering

• Crear la especificación. El nombre de la carpeta lo genera él:

/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

• Requisitos. Se lee requirements.md y se corrige lo que no sea:

/kiro-spec-requirements exportar-pedidos

• Diseño. -y significa «he leído los requisitos y me valen»:

/kiro-spec-design exportar-pedidos -y

• Tareas. -y aprueba ahora el diseño:

/kiro-spec-tasks exportar-pedidos -y

• Implementación:

/kiro-impl exportar-pedidos

• Revisión, en una sesión nueva (/clear), para que no se fíe de lo que hizo:

Compara el diff de esta rama con .kiro/specs/exportar-pedidos/requirements.md.
Para cada requisito, di si está implementado y qué test lo cubre.
No arregles nada.

1. Instala Claude Code, o OpenCode si quieres empezar con modelos gratuitos.
2. 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.
3. Coge una tarea pequeña y hazla en modo Plan: lee el plan antes de dejarle tocar nada.
4. Una tarea, una sesión. /clear entre tareas.
5. Cada vez que se equivoque en lo mismo, escríbelo en AGENTS.md.
6. Cuando la tarea no quepa en una frase, especifica.

Lo que no ha cabido en esta hora: