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, 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 iniciar 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 && ./arrancar.sh

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
./arrancar.sh

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. Dos scripts y nada más: ./arrancar.sh y ./parar.sh.

Abre Claude Code en el worktree y pasa al modo plan:

Quiero implementar el issue #12. Antes de proponer nada, pregúntame lo que no esté
claro. El resultado es solo el fichero planes/12-alta-clientes.md.

El agente lee el proyecto, hace dos preguntas (¿el NIF es único?, ¿el email es obligatorio?) y propone el plan. Lorenzo lo lee, cambia una cosa y lo aprueba. Queda guardado en planes/12-alta-clientes.md:

# Alta de clientes (#12)

## Base de datos
V3__clientes.sql: tabla clientes (id, nombre, nif único, email).

## Backend
ClienteController, ClienteService, Cliente, ClienteRepository, ClienteJpaEntity...

## Frontend
Componente cliente-form en /clientes/nuevo, con validación de NIF y email.

## 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.

Leer y corregir ese plan 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.

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

Ejecuta @planes/12-alta-clientes.md

El agente 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 guardadas. Al acabar, ejecuta mvn test: compila y los tests de arquitectura comprueban que cada clase está en su capa. Lorenzo mientras tanto no escribe código: revisa lo que va saliendo.

Como el backend ha cambiado, lo reconstruye:

./arrancar.sh

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

La otra forma: con Kiro. El alta de clientes es un CRUD, y los CRUD tienen una estructura fija que el agente no puede saltarse. Para eso hay una segunda forma de hacer los pasos 2 y 3, con cc-sdd (Kiro), que en vez de un plan en una página genera requisitos, diseño y tareas, cada uno aprobado por Lorenzo, y que lee antes la arquitectura del proyecto para que el CRUD salga igual que todos los demás:

/kiro-spec-init CRUD de clientes: nombre (obligatorio), nif (único, obligatorio), email
/kiro-spec-requirements
/kiro-spec-design -y
/kiro-spec-tasks -y
/kiro-impl

El criterio para elegir es siempre el mismo: estructura fija donde el agente no se puede salir de las reglas, Kiro; todo lo demás, el modo plan. Las dos formas están en el tema 4 y en el tema 5.

Los tests también los escribe el agente, a partir del plan:

/crear-test-unitarios ClienteService
/crear-test-api Cliente
/crear-test-e2e planes/12-alta-clientes.md

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 skill ejecuta los suyos y los deja pasando. Lorenzo los vuelve a lanzar él mismo, para verlo, con los tres comandos de tests del proyecto:

mvn test
npm run test:api
npm run test:e2e

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. ./arrancar.sh y listo.

Antes de cerrar, una revisión de calidad del paquete nuevo:

/revisar-calidad backend/src/main/java/com/tienda/clientes

El informe trae dos hallazgos mejorables y ninguno grave; Lorenzo pide corregir uno y sigue:

/git-flow commit

El agente mira los cambios y los agrupa en tres commits con sentido (feat(#12): migración y entidad de clientes, feat(#12): formulario de alta…). Luego:

/git-flow finalizar

Antes de fusionar, el agente revisa el código contra el plan y las convenciones: encuentra una cosa mejorable y nada grave, así que sigue. 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 los tres tests otra vez: CI en verde en develop. Si algún día sale en rojo, /revisar-ci le dice qué. Lorenzo no ha tocado la web.

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

El viernes, con tres issues cerrados en develop:

/git-flow publicar

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, /revisar-ci 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;
• 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 el plan), comprobar que es lo que quería (los tests y el navegador) y dar el visto bueno (leer la revisión y fusionar). Programar con esta arquitectura es eso: pensar y comprobar, y que el resto se ejecute solo.

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.

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

Las skills (/git-flow, /crear-test-api…) 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, pasar los tests) 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: los scripts del proyecto son de bash y funcionan 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 y cómo se maneja OpenCode está contado en el curso de programación con IA: Skills, Agentes y MCP y OpenCode. 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 el modo plan.

• 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.