Este módulo no enseña a programar en Java ni en Angular: eso ya lo hacéis en otros módulos. Enseña todo lo que rodea a programar cuando se trabaja con un agente de IA: el repositorio, las ramas, los contenedores, la especificación, los tests, el despliegue y las skills que hacen que todo eso se ejecute solo.

En la 1ª evaluación cada alumno monta su fábrica: un repositorio preparado para trabajar así. En la 2ª evaluación la usa para hacer el proyecto (ver las aplicaciones de la 2ª evaluación).

Para saber a dónde se llega, lo mejor es ver cómo se trabaja cuando la fábrica ya está montada. No hace falta entender ahora cada pieza: cada una se explica en su tema. Fíjate sobre todo en lo poco que hace el alumno y en lo que no hace.

Lorenzo está haciendo una tienda. Hoy le toca el issue #12, «Alta de clientes», que está en el tablero de GitHub en Todo.

En la carpeta del repositorio abre Claude Code y escribe:

/git-flow start 12

En unos segundos el agente responde:

Issue #12: Alta de clientes
Rama lorenzo-12-alta-clientes creada desde develop.
Worktree en ../tienda-wt-12-alta-clientes, con sus puertos en .env
Para arrancar la aplicación: cd ../tienda-wt-12-alta-clientes && ./app.sh start

Tiene una carpeta nueva con una copia del proyecto y una rama solo para este issue. Entra en ella y arranca su aplicación:

cd ../tienda-wt-12-alta-clientes
./app.sh start

Aplicación en http://localhost:4212

Base de datos, backend y frontend, en Docker, con datos de prueba, en un puerto que no choca con nada. Si por la tarde empieza el #13, tendrá otra carpeta y otra aplicación en otro puerto, y las dos conviven. Un script y nada más: ./app.sh start, stop, status y logs.

Abre Claude Code en el worktree y pide la especificación del issue:

/sdd spec create

El agente sabe qué issue es por el nombre de la rama. Lee el issue, hace dos preguntas (¿el NIF es único?, ¿el email es obligatorio?) y escribe tres ficheros en .kiro/specs/12-alta-clientes/: requisitos, diseño y tareas. Y se para. El de requisitos acaba así:

## Criterios de aceptación
- Al guardar un cliente válido aparece en el listado.
- Si el NIF ya existe, el formulario muestra «NIF repetido» y no se crea.
- Si falta el nombre, el botón Guardar no hace nada y el campo se marca.

Y el de tareas, así:

- [ ] 1. Migración V3__clientes.sql y datos de prueba R__clientes.sql
- [ ] 2. Backend: Cliente, ClienteRepository, ClienteService, ClienteController, DTO y mapper
- [ ] 3. Frontend: componente cliente-form en /clientes/nuevo con validación de NIF y email

Leer y corregir esos ficheros es el trabajo importante del día. Arreglar una frase aquí cuesta un minuto; arreglar el código que sale de una frase mal escrita cuesta una tarde. Lorenzo añade un criterio que faltaba al de requisitos y vuelve a lanzar /sdd spec create: el diseño y las tareas se rehacen con el cambio. El diseño sale igual que el de los demás CRUD de la tienda, porque el agente lee antes la arquitectura del proyecto.

Conversación nueva (/clear) y una sola orden:

/sdd spec impl

El agente va tarea a tarea: escribe la migración, las clases del backend en sus capas, el componente de Angular y los datos de prueba, siguiendo las convenciones del proyecto que tiene escritas. Después de cada tarea pasa los tests unitarios y de arquitectura y la marca como hecha en el fichero de tareas. Lorenzo mientras tanto no escribe código: revisa lo que va saliendo.

Como el backend ha cambiado, lo reconstruye:

./app.sh start

El mismo script: reconstruye lo que ha cambiado y lo vuelve a levantar. El frontend ni eso: se recarga solo al guardar.

Los tests también los escribe el agente, a partir de la spec:

/test unit create ClienteService
/test api create Cliente
/test e2e create

Salen los tests unitarios del servicio (uno por comportamiento), los de la API (cada endpoint, con sus errores) y los de extremo a extremo, uno por criterio de aceptación. Cada uno se ejecuta al crearlo y se deja pasando. Lorenzo los vuelve a lanzar él mismo, uno a uno, para verlo:

/test unit run
/test api run
/test e2e run

Todo en verde. Después abre http://localhost:4212, da de alta un cliente, prueba un NIF repetido. El mensaje de error no le gusta y lo pide en la misma conversación. ./app.sh start y listo. Pero el cambio del mensaje rompe el test E2E que comprobaba el texto antiguo:

/test e2e repair

El agente mira por qué falla: el test está desactualizado por un cambio intencionado del código, así que actualiza el test. Si hubiera sido un error del código, habría arreglado el código y no el test. Y si no lo tuviera claro, no tocaría nada y preguntaría.

Antes de cerrar, el agente revisa su propio trabajo:

/developer code review
/developer test review

La primera compara el código con la spec y con las reglas de calidad del proyecto; la segunda, los tests con los criterios de aceptación. Ninguna toca nada: escriben lo que encuentran en review.md, junto a la spec, y las correcciones las añaden como tareas nuevas. Hoy salen dos cosas mejorables y un criterio de aceptación que solo se probaba a medias. Lorenzo lee, está de acuerdo, y las tareas nuevas se hacen como las demás:

/sdd spec impl

Luego los commits y el cierre:

/git-flow commit
/git-flow finish

commit mira los cambios y los agrupa en tres commits con sentido (feat(#12): migración y entidad de clientes, feat(#12): formulario de alta…). finish comprueba antes de hacer nada: que no queda ninguna tarea pendiente, que review.md no tiene hallazgos abiertos y que todos los tests pasan. Si falta algo, lo dice y no hace nada. Como está todo, fusiona la rama en develop, hace push, para la aplicación, borra la base de datos del worktree y borra el worktree. En GitHub, el issue #12 se cierra solo y el tablero lo pasa a Done. Con el push, GitHub compila y pasa todos los tests otra vez: CI en verde en develop. Si algún día sale en rojo, /developer ci review le dice qué. Lorenzo no ha tocado la web.

Por la tarde empieza el #13 igual. No le da tiempo a terminarlo: ./app.sh stop y se va. Mañana ./app.sh start y la aplicación está como la dejó, con sus datos.

El viernes, con tres issues cerrados en develop:

/git-flow publish

develop pasa a main. GitHub pasa la misma CI que en develop y, si está en verde, despliega en el servidor. Cinco minutos después la tienda está actualizada en http://lorenzo.proyectosdaw.cip.fpmislata.com. Si algo falla, /developer ci review le dice qué, igual que en develop.

Esto es lo que vende la fábrica. En todo el día Lorenzo no ha:

• escrito un comando de git: ni branch, ni worktree, ni merge, ni push;
• buscado un puerto libre ni tocado un docker compose;
• escrito una clase de Java ni un componente de Angular;
• escrito un test, ni arreglado uno que se rompió;
• revisado a mano que el código sigue las convenciones del proyecto;
• cerrado un issue ni movido una tarjeta en el tablero;
• entrado al servidor.

Lo que sí ha hecho es lo que solo puede hacer él: decidir qué se construye (el issue y la spec), comprobar que es lo que quería (los tests y el navegador) y dar el visto bueno (leer la revisión y cerrar). Programar con esta arquitectura es eso: pensar y comprobar, y que el resto se ejecute solo. Y hay una regla que lo hace posible: ningún comando se queda esperando a Lorenzo. Los que generan trabajo lo dejan en ficheros del repositorio (la spec, las tareas, la revisión); los que hacen algo irreversible solo comprueban que esos ficheros están como tienen que estar. Lorenzo decide entre comandos, no dentro de ellos.

Lo de arriba, resumido. Es lo que se repite con cada issue: al finalizar uno se empieza el siguiente, y solo de vez en cuando, cuando hay una versión que sacar, se publica.

Todo lo que ha escrito Lorenzo tiene la misma forma: familia, sustantivo y verbo, como docker container ls o gh issue create. Cinco familias, pocos verbos, y los mismos verbos significan lo mismo en todas:

Lo que empieza por / es una skill del agente; lo que acaba en .sh es un script. Quien sabe que existe /test e2e run deduce /test e2e create y /test api repair sin haberlos visto. Esa es la idea: no hay que memorizar una lista, hay que saber la gramática.

Para que ese día de trabajo sea posible, en la 1ª evaluación se construye cada pieza, en este orden:

Las skills son las instrucciones que le dicen al agente cómo se hace cada cosa en este proyecto. Las escribe el alumno durante el trimestre, con ayuda del propio agente, y son lo que convierte una lista de pasos en una sola orden. Lo que no necesita inteligencia (arrancar, parar, ver los logs) no es una skill: es un script.

Todo esto tiene que estar instalado y funcionando antes del tema 2:

• git y gh (la CLI de GitHub) autenticado: gh auth status debe decir que estás conectado. En Windows, Git se instala con las opciones del tema 2, que traen bash: el script del proyecto es de bash y funciona igual en los tres sistemas.
• Docker con Docker Compose: docker compose version.
• JDK 25 y Maven: mvn -v.
• Node (para npx y Angular): node -v.
• Claude Code u OpenCode, con una cuenta que aguante un trimestre generando código. Los apuntes explican todo con Claude Code y señalan lo que cambia en OpenCode.

Qué es una skill, un agente o un MCP, cómo se maneja OpenCode y qué es cc-sdd (Kiro) está contado en el curso de programación con IA: Skills, Agentes y MCP, OpenCode y Kiro. Claude Code está en Proyecto 8.

• Comprueba que tienes todas las herramientas: git, gh auth status, docker compose version, mvn -v, node -v y Claude Code u OpenCode arrancando.
• Lee qué es una skill y qué es Kiro.

• Crea en GitHub el repositorio de tu proyecto, vacío, con README y .gitignore. Es el que se usa en todo el módulo.
• Clónalo y pide al agente que genere en backend/ un Spring Boot con Maven y Java 25, sin JPA (la base de datos llega en el tema 3), con un GET /api/hola que devuelva un texto, y en frontend/ un Angular que lo llame y lo muestre.
• Arranca los dos a mano, mvn spring-boot:run y ng serve, y comprueba en el navegador que el texto aparece.
• Haz commit y push. En este tema los commits se hacen a mano: /git-flow llega en el siguiente.