Primer curso de IA para desarrolladores con experiencia

Formación práctica para integrar IA en tu flujo real de trabajo: IDE, terminal, Git, PRs, prompts útiles, revisión de código generado y criterios claros para usarla o descartarla.

⏱️ 7-8 horas orientadas a práctica
👥 Desarrolladores con experiencia
🎯 Nivel: primer uso práctico para desarrolladores senior
No es un curso para aprender “qué modelo está de moda”. Es un curso para aprender a trabajar mejor con IA sin bajar el nivel técnico, sin perder criterio y sin llenar el repositorio de código que nadie entiende.
i

Antes de Empezar: Vocabulario Mínimo

Una introducción corta para que el resto del día tenga contexto y nombres claros

La idea básica es sencilla: un modelo genera texto o código a partir del contexto que le das; el editor o la terminal son la superficie donde trabajas; y algunas herramientas añaden un agente que puede leer ficheros, ejecutar comandos y proponerte cambios más amplios. No hace falta entenderlo en profundidad para usarlo bien, pero sí conviene saber qué pieza hace qué.

Desarrollador da contexto revisa y decide Editor / Terminal chat, diff, comandos y revisión inmediata Modelo / Agente genera, resume, propone pero no valida por ti Repo / Tests / Git / PR la verdad está aquí: diff, build, tests y review MCP = conector de contexto
Término Idea ligera Cómo aparece en tu día a día
Modelo El motor que genera texto, sugerencias o código Chat, autocompletado, análisis y borradores
Contexto Todo lo que el modelo ve para responder Archivos abiertos, instrucciones del proyecto, errores, diff
Prompt La instrucción que le das Objetivo, restricciones, referencias y definición de terminado
Asistente en IDE Ayuda integrada en el editor Autocompletado, chat, explicación y generación local
Agente Un asistente con más autonomía y acceso a herramientas Lee repo, ejecuta comandos, propone cambios multiarchivo
MCP Un protocolo para conectar contexto externo Tickets, BD, repos, logs o documentación sin copiar y pegar todo

¿Qué es MCP y por qué importa?

MCP (Model Context Protocol) es un estándar abierto que permite conectar herramientas de IA con fuentes de contexto: bases de datos, sistemas de tickets, repositorios privados, logs de aplicaciones, etc. Sin MCP, tendrías que copiar y pegar manualmente todo el contexto. Con MCP, el asistente lo trae automáticamente.

Ventaja práctica

Si tu equipo usa Jira, Slack, Grafana, Confluence o bases de datos privadas, MCP permite que Claude (o cualquier herramienta compatible) acceda a ellas sin exponer datos sensibles fuera de tu infraestructura.

Escenario Sin MCP (manual) Con MCP (automático)
Investigar un bug desde Jira Copiar issue → pegar en chat → pedir que revise logs en otra ventana MCP trae issue + últimos logs + historial de cambios automáticamente
Generar código basado en BD existente Hacer screenshot del schema de BD, pegarlo como imagen MCP accede a BD y proporciona schema completo y actualizado
Revisar cambios según SLA actual Copiar SLA document del Confluence, incrustar en prompt MCP conecta a Confluence, trae documento actualizado al momento

📌 Estado actual (2026)

MCP es soportado nativamente por Claude, está en roadmap de GitHub Copilot, y es adoptado por empresas con requisitos de seguridad y privacidad altos. Para el primer curso puedes mencionarlo como "el futuro de contexto seguro", pero la mayoría de usuarios aún no lo usan day-to-day.

Módulo 1: Fundamentos Operativos para Trabajar con IA

📚 Objetivos de Aprendizaje
  • Entender qué tareas acelera la IA y en cuáles añade más riesgo que valor
  • Distinguir entre autocompletado, chat contextual y agentes con acceso al repositorio
  • Aprender a dar contexto útil sin escribir prompts kilométricos
  • Detectar rápido errores típicos: APIs inventadas, edge cases olvidados y sobreingeniería
  • Trabajar con una regla práctica: prompt, diff, tests, revisión y decisión

1.1 Qué aporta realmente la IA a un desarrollador con experiencia

Para esta audiencia la IA no sustituye criterio técnico. Lo que hace bien es acelerar trabajo mecánico, ofrecer primeros borradores razonables y ayudarte a explorar opciones sin partir de cero. Lo que sigue siendo tuyo es el diseño, la validación y la responsabilidad sobre el cambio.

Situación Qué suele aportar Riesgo principal Regla práctica
Boilerplate y wiring Te ahorra tecleo y acelera el primer borrador Copiar patrones incorrectos del proyecto Dale un archivo de referencia y revisa el diff completo
Tests unitarios Cubre casos base con rapidez Happy path sin casos límite reales Pide explícitamente errores, vacíos y validaciones
Lectura de código legacy Resume, explica y propone mapas del flujo Conclusiones convincentes pero falsas Úsala para orientarte, no para cerrar la investigación
Refactorización mecánica Renombrados, extracción de métodos, limpieza repetitiva Romper contratos implícitos Haz cambios pequeños y ejecuta tests a cada paso
Decisiones delicadas Sirve para explorar alternativas y trade-offs Tomar la primera propuesta como diseño final Pide opciones, no autoridad

💡 Idea central

Trata la IA como un colaborador rápido pero poco fiable: produce mucho, se equivoca con seguridad y necesita restricciones claras. Si tu proceso no incluye revisión, pruebas y diff, el problema no es el prompt: es el flujo de trabajo.

1.2 Tres modos de uso que debes distinguir

No todas las herramientas hacen lo mismo. La decisión útil no es “qué marca uso”, sino qué grado de autonomía le doy y cuánta superficie del cambio le dejo tocar.

Modo Cuándo usarlo Ventaja Qué revisar
Autocompletado Mientras ya estás escribiendo y sabes hacia dónde vas Reduce fricción y acelera código repetitivo Nombres, tipos, imports y convenciones del proyecto
Chat contextual Para entender código, pedir tests o acotar una tarea Buena relación entre control y velocidad Que no invente APIs ni suponga archivos que no existen
Agente con repo Para cambios multiarchivo, refactors o tareas con terminal Puede ejecutar un flujo completo con menos intervención Scope del cambio, comandos ejecutados, diff, tests y efectos colaterales

1.3 Qué contexto necesita para ayudarte de verdad

Los mejores resultados no salen de prompts “creativos”, sino de contexto útil. Para código casi siempre bastan cinco piezas: objetivo, restricciones, archivos de referencia, definición de terminado y qué no debe tocar.

❌ Prompt pobre
Hazme el endpoint de exportación.
✅ Prompt útil
En este proyecto, con el stack y las convenciones actuales, añade un endpoint GET /api/orders/export. - Sigue el patrón de OrderController.java y OrderService.java - Devuelve un DTO, no expongas entidades JPA - No cambies contratos existentes ni nombres públicos - Añade tests del caso feliz, lista vacía y error de validación - Si falta contexto, propón primero un plan breve antes de tocar código - Mantén la solución simple y legible; evita introducir nuevas dependencias

📋 Regla rápida de contexto

  • Objetivo: Qué cambio quieres y para qué sirve
  • Restricciones: Stack, convenciones, arquitectura, límites de seguridad
  • Referencias: Qué archivos o ejemplos debe imitar
  • Definición de terminado: Tests, comportamiento esperado, casos límite
  • Límites: Qué no debe modificar ni asumir

1.4 Fallos frecuentes que debes detectar pronto

Los errores de la IA no suelen ser exóticos. Son muy parecidos a los de un desarrollador junior con mucha velocidad y poca memoria de contexto.

Fallo Señal de alarma Respuesta correcta
APIs inventadas Usa métodos, clases o flags que no existen en tu stack Abre archivos reales, pega la firma y exige ajustarse a ellos
Arregla el test en vez del código La build pasa pero la lógica sigue mal Indica explícitamente que el test es correcto y que debe corregir la implementación
Sobreingeniería Cuatro clases nuevas para resolver algo simple Pide la solución más simple posible y rechaza abstracciones prematuras
Olvida restricciones Vuelve a usar patrones que ya prohibiste Repite las reglas clave y muévelas a un archivo de instrucciones del proyecto
Confianza injustificada Afirma compatibilidades o features sin comprobarlas Para versiones, APIs y precios: verificar siempre en documentación oficial

1.5 Cuándo usar IA y cuándo no

✅ Úsala

  • Para primeros borradores de código repetitivo
  • Para generar tests, fixtures y datos de ejemplo
  • Para explorar refactors mecánicos o renombrados
  • Para resumir código legacy antes de leerlo en detalle
  • Para revisar diffs, detectar huecos y proponer checklists

⛔ Párate y decide antes

  • Si el problema ni siquiera está bien formulado
  • Si afecta a seguridad, auth, criptografía o datos sensibles
  • Si el cambio es pequeño y ya sabes hacerlo más rápido tú
  • Si llevas varias iteraciones y la herramienta no converge
  • Si no podrías defender el cambio en una review sin la IA delante

📋 Regla práctica para empezar como equipo

  • Primero: úsala en tareas acotadas y reversibles
  • Siempre: branch propia, diff limpio y tests ejecutados
  • Obligatorio: el autor humano revisa todo antes del commit
  • Si hay duda: reduce el alcance o vuelve a hacerlo manualmente
2

Elegir Herramienta sin Casarte con una Marca

45 minutos

Lo importante no es la marca: es el patrón de trabajo

El ecosistema cambia muy deprisa. Por eso aquí no vamos a memorizar un ranking de productos, sino a distinguir qué categoría encaja mejor según la tarea, el riesgo y el nivel de autonomía que quieres conceder.

Categoría Úsala cuando Ventaja real Qué vigilar
Autocompletado en IDE Ya sabes la solución y quieres menos fricción al escribir Velocidad y continuidad de flujo Aceptar sugerencias erróneas por inercia
Chat contextual Necesitas entender código, pedir tests o explorar una solución Buen equilibrio entre control y productividad Contexto insuficiente o respuestas demasiado confiadas
Agente en IDE Quieres cambios guiados sin salir del editor Menos saltos entre conversación y código Que el cambio toque más ficheros de lo esperado
Agente en terminal/desktop La tarea implica archivos, comandos, tests y diff Más contexto operativo y mejor encaje con Git Perder trazabilidad si no revisas comandos y resultados
Ejecución remota o cloud Necesitas aislamiento, trabajo asíncrono o paralelizar Escala mejor en tareas largas o repetibles Menos control inmediato y más dependencia del setup

💡 Estrategia recomendada

La secuencia que suele funcionar mejor en equipos de desarrollo es esta:

  • Primero: autocompletado y chat para trabajo que ya sabes evaluar
  • Después: agentes locales para tareas multiarchivo con tests y diff
  • Más tarde: automatización o ejecución remota cuando ya existan guardrails
  • Siempre: elige por flujo de trabajo, no por la marca del momento

Setup mínimo útil

No intentes desplegar todo el mercado el primer día. Deja lista una categoría, úsala en trabajo real y amplía solo cuando ya entiendas sus límites.

Setup base de una herramienta IA bash
# 1. Instalar la extensión o cliente
#    → IDE o aplicación de escritorio

# 2. Iniciar sesión y abrir un proyecto real
#    → Mejor un proyecto pequeño o una rama de pruebas

# 3. Añadir contexto útil
#    → Instrucciones del proyecto
#    → Archivos de referencia
#    → Restricciones técnicas

# 4. Ejecutar un primer ciclo completo
#    → Generación
#    → Diff
#    → Tests
#    → Revisión humana

Ese patrón es mucho más estable que cualquier nombre de plan o comando: activar → contextualizar → probar en pequeño → revisar → medir.

🎯 Consejo para Java/Spring developers

Antes de pedir generación, enseña un patrón real del proyecto. La herramienta mejora más por contexto correcto que por cambiar de proveedor.

Usa OrderController.java y OrderService.java como referencia. Genera el nuevo endpoint siguiendo ese patrón, sin exponer entidades y añadiendo tests.

Eso obliga al asistente a parecerse a tu base de código, no a un ejemplo genérico.

Ejemplos orientativos, no exhaustivos

Asistente integrado en IDE

Útil cuando el equipo quiere quedarse dentro del editor para autocompletado, chat contextual y cambios pequeños. Aquí importa más la calidad del contexto y del diff que la marca concreta.

Agente con terminal y repositorio

Encaja mejor cuando la tarea exige leer varios archivos, ejecutar comandos, lanzar tests y preparar una PR revisable. La diferencia real está en el grado de control operativo.

Si quieres enseñar nombres concretos en clase, limita esta parte a uno o dos ejemplos como soporte visual y vuelve enseguida al criterio de elección.

Ejemplo práctico: generar un endpoint con Copilot

Aquí mostramos cómo pedir a Copilot que genere un endpoint nuevo siguiendo patrones existentes.

OrderController.java (Patrón existente) java
@RestController
@RequestMapping("/api/orders")
public class OrderController {
    
    @Autowired private OrderService orderService;
    
    @GetMapping("/{id}")
    public ResponseEntity getOrder(@PathVariable Long id) {
        OrderDTO order = orderService.getOrderById(id);
        return ResponseEntity.ok(order);
    }
    
    @PostMapping
    public ResponseEntity createOrder(@RequestBody CreateOrderRequest request) {
        OrderDTO created = orderService.createOrder(request);
        return ResponseEntity.status(HttpStatus.CREATED).body(created);
    }
}
✅ Buen prompt para Copilot
Siguiendo el patrón de OrderController: - Añade un GET /api/orders/pending que devuelve List - Usa OrderService.getPendingOrders() - Añade paginación con PageRequest - Devuelve un ResponseEntity con status OK - No cambies métodos existentes
Resultado que genera Copilot java
@GetMapping("/pending")
public ResponseEntity> getPendingOrders(
        @RequestParam(defaultValue = "0") int page,
        @RequestParam(defaultValue = "20") int size) {
    PageRequest pageable = PageRequest.of(page, size);
    Page pending = orderService.getPendingOrders(pageable);
    return ResponseEntity.ok(pending);
}

✓ Lo que salió bien

  • Respetó el patrón de anotaciones y tipos de retorno
  • Usó correctamente ResponseEntity
  • Añadió paginación con PageRequest (estándar Spring)
  • No cambió métodos existentes

Matriz de decisión: qué elegir según la tarea

Tu necesidad Categoría recomendada Criterio de elección
Autocompletado mientras escribo Autocompletado en IDE Prioriza integración natural con tu editor y baja fricción
Entender un módulo o pedir tests Chat contextual Necesitas control fino y capacidad de iterar rápido
Hacer cambios automáticos en proyecto Agente local o en terminal La tarea toca varios archivos y requiere comandos, diff y pruebas
Refactorizar código existente Chat contextual o agente local Depende de si quieres propuesta guiada o ejecución supervisada
Escribir tests Chat contextual Pide explícitamente casos de error, vacíos y edge cases
Depurar problema complejo Terminal/desktop con acceso a logs y repo Necesitas combinar conversación, comandos y lectura de varios archivos

📌 Nota editorial

Modelos, planes, comandos concretos y precios cambian con frecuencia. Antes de impartir el curso conviene revisar la documentación oficial de las herramientas citadas. El objetivo aquí es enseñar criterios transferibles, no una comparativa congelada.

3

IA dentro del IDE: contexto corto, iteración rápida

75 minutos

Este módulo puede impartirse con Copilot, Continue u otra herramienta equivalente. El aprendizaje no depende del producto: depende de usar el editor como superficie principal de trabajo, con contexto local, iteraciones cortas y revisión inmediata.

Qué aporta de verdad dentro del editor

Situación Cuándo aporta Qué revisar siempre
Autocompletado Boilerplate, wiring, tests base, cambios mecánicos Imports, nombres, tipos y APIs inventadas
Chat contextual Entender código, proponer un cambio pequeño, pedir explicación Que la respuesta se apoye en archivos reales del proyecto
Edición guiada Cambios acotados en uno o pocos ficheros Alcance del diff y casos límite no cubiertos

Flujo mínimo útil en IDE

1. Abrir contexto real

Abre controller, service, tests y cualquier DTO o entidad de referencia. Si hay una convención del proyecto, ponla a la vista.

2. Pedir un cambio pequeño y verificable

Una sola intención por iteración. Mejor un endpoint o un test que una “feature completa”.

3. Revisar el diff antes de confiar

Busca acoplamiento nuevo, decisiones ocultas, validaciones ausentes y efectos laterales no pedidos.

4. Ejecutar y corregir

Compila, ejecuta tests y devuelve feedback preciso. El editor acelera el ciclo, no sustituye la verificación.

Guía paso a paso: primera hora con Copilot

Objetivo: Tener Copilot funcionando en VSCode con contexto de tu proyecto.

Tiempo: 15-20 minutos

Paso 1: Instalar extensión (2 min)

Abre VS Code → Extensiones (Ctrl+Shift+X) → busca "GitHub Copilot" → instala oficial de GitHub. Reinicia VSCode.

Paso 2: Autenticar (3 min)

Abre Command Palette (Ctrl+Shift+P) → "Copilot: Sign In" → se abrirá un navegador → autoriza tu cuenta de GitHub → vuelve a VSCode.

Paso 3: Abrir tu proyecto (1 min)

File → Open Folder → elige tu proyecto Spring Boot. Copilot ahora ve la estructura.

Paso 4: Crear archivo de instrucciones (5 min)

En la raíz del proyecto, crea .copilot-instructions.md con el contexto técnico (ver sección siguiente). Copilot lo leerá automáticamente.

Paso 5: Prueba en pequeño (5 min)

Abre un Controller existente → crea una nueva línea en blanco → empieza a escribir una ruta → Copilot debería sugerir. Prueba también el chat lateral (Ctrl+Shift+I o icono de chat).

.copilot-instructions.md markdown
# Instrucciones para Copilot

## Stack
- Java 17 + Spring Boot 3.5
- JPA + Hibernate
- MockMvc para tests

## Convenciones de este proyecto
- Controllers: sufijo Controller, en paquete `com.company.api.controller`
- Services: sufijo Service, en paquete `com.company.business.service`
- Entities: en paquete `com.company.persistence.entity`
- DTOs: sufijo DTO, usados en responses de endpoints

## Patrones esperados
- DTOs siempre en responses, nunca expongas entidades JPA
- Tests unitarios usan @SpringBootTest con MockMvc
- Métodos privados innecesarios; mantener público solo lo que es necesario

## Qué NO cambiar
- No modificar archivos de configuración (application.properties)
- No tocar la estructura del build.gradle
- No cambiar nombres de métodos públicos existentes

## Definición de terminado para cada tarea
- Código compila sin warnings
- Tests pasan (ejecuta `./gradlew test`)
- Cambios aparecen en un diff limpio, sin reformateo accidental

💡 Pro tip

Este archivo es transferible a cualquier miembro del equipo. Cada uno copia el proyecto, instala Copilot, y automáticamente todos usan las mismas restricciones y patrones.

Archivo de instrucciones del proyecto

No importa tanto el nombre del fichero como su función: darle al asistente un marco estable de arquitectura, restricciones y definición de terminado.

Instrucciones del proyecto markdown
# Contexto del proyecto
- Stack: Java 17 + Spring Boot + JPA
- Capas: Controller -> Service -> Repository
- No exponer entidades JPA fuera del dominio
- Inyección por constructor
- Logs sin datos sensibles

# Cómo pedir cambios
- Sigue los patrones de OrderController y OrderService
- Si falta contexto, pregunta antes de inventar
- Genera tests para errores y casos límite

# Definición de terminado
- Diff revisable
- Tests ejecutados
- Sin helpers no usados
- Sin cambios fuera de alcance

Qué no debe ser el centro de este módulo

Atajos, botones concretos, comandos de chat, nombres de plan y pantallas del proveedor envejecen rápido. Si enseñas un producto concreto, úsalo solo como soporte visual del flujo, no como temario principal.

3.X — Sesión Real en IDE: De Ticket a Commit

El objetivo es ver el ciclo completo con un caso único y consistente. Aquí usamos el dominio de pedidos para que el patrón luego conecte con el taller central.

🎫 Contexto: el ticket

BACK-412 — Añadir endpoint GET /api/orders/pending-review que devuelva pedidos pendientes de revisión con antigüedad mayor al umbral configurable. Incluir tests.

Iteración 1 — El primer prompt (demasiado vago)

❌ Prompt inicial — demasiado vago
hazme el endpoint de pedidos pendientes de revisión

El asistente generó algo aparentemente correcto, pero ignoró convenciones del proyecto: devolvía la entidad Order directamente, dejó el umbral hardcodeado y no cubrió los casos de error.

Iteración 2 — Prompt mejorado con contexto

✅ Prompt con contexto
En nuestro OrderController añade el endpoint GET /api/orders/pending-review que: - Acepta un query param "days" (Integer, default 7) - Delega en OrderService.findPendingReview(days) - Devuelve List<OrderPendingReviewResponse> en lugar de entidades - Usa inyección por constructor, sin @Autowired - Lanza IllegalArgumentException si days es cero o negativo Mira OrderController.java, OrderService.java y los tests existentes para seguir el patrón real del proyecto.
OrderController.java — borrador generado Java
@GetMapping("/pending-review")
public ResponseEntity<List<OrderPendingReviewResponse>> getPendingReview(
        @RequestParam(defaultValue = "7") Integer days) {
    if (days < 0) {
        throw new IllegalArgumentException("Days must be positive");
    }
    return ResponseEntity.ok(orderService.findPendingReview(days));
}
⚠️

Bug sutil que la IA no detectó: la condición days < 0 deja pasar days = 0, que incumple la regla de negocio. La validación correcta es days <= 0. Los casos límite siguen siendo trabajo tuyo.

Iteración 3 — Pedir los tests adecuados

✅ Prompt para tests
Genera tests para OrderService.findPendingReview() y para el controller. Cubre: caso feliz, lista vacía, days=0, days negativo y validación de que no se exponen entidades JPA en la respuesta. Sigue el patrón de OrderServiceTest existente.
Clave del módulo

Dentro del IDE la IA rinde mejor cuando el alcance es corto y el feedback es inmediato. Si el cambio ya requiere varios comandos, muchos ficheros o aislamiento en ramas, ya no estás en un patrón de IDE puro: estás entrando en agentes y terminal.

VSCode como base: las tres herramientas principales

VSCode es el IDE de referencia para este módulo porque concentra la mayor parte del ecosistema. Las mecánicas son transferibles a JetBrains, Neovim o cualquier editor con extensiones equivalentes. Aquí comparamos las tres opciones que más se usan en equipos Java/Spring.

GitHub Copilot en VSCode

La integración más madura en el IDE. Autocompletado inline, panel de chat con contexto del editor y Agent Mode para tareas multiarchivo. Funciona dentro del editor sin salir al terminal.

Modos de uso en VSCode

⌨️
Autocompletado Inline

Sugiere código mientras escribes. Tab acepta, Alt+] alterna sugerencias. Útil para boilerplate, getters, builders y wiring de Spring.

💬
Copilot Chat

Panel lateral con contexto del fichero activo. Comandos: /explain, /fix, /tests, /doc. Usa @workspace para contexto del proyecto.

🤖
Agent Mode

Modo autónomo para tareas que implican varios ficheros. El agente propone un plan, edita ficheros y ejecuta comandos. Supervisa cada paso antes de confirmar.

📋
Inline Edit (Ctrl+I)

Edición directa sobre el código seleccionado. Muestra diff antes de aplicar. Ideal para refactors pequeños, renombres y extracciones de método.

Archivo de instrucciones del proyecto

Copilot lee .github/copilot-instructions.md automáticamente. Sin él, no sabe nada de tus convenciones. Con él, el autocompletado y el chat se alinean al estilo real del proyecto.

.github/copilot-instructions.md markdown
# Instrucciones para GitHub Copilot

## Stack y arquitectura
- Java 17 + Spring Boot 3.5 + JPA
- Capas: Controller → Service → Repository
- DTOs como records de Java 17

## Convenciones
- Inyección SIEMPRE por constructor
- No exponer entidades JPA en respuestas de API
- Tests con JUnit 5 + Mockito, sin @SpringBootTest salvo integración
- Logs con SLF4J, sin datos personales ni tokens

## Al generar código
- Sigue el patrón de OrderController y OrderService
- Si falta contexto, pregunta antes de inventar
- Genera siempre el test unitario junto al código

Skills de Copilot (Enterprise)

En Copilot Enterprise puedes definir Skills: paquetes de instrucciones + ejemplos de código que el equipo comparte. Un Skill de "Revisión de Seguridad" o "Generador de Tests Spring" aplica el mismo criterio a todos los desarrolladores del equipo sin que cada uno configure su prompt desde cero.

💡

Valor real de los Skills: estandarizar cómo el equipo usa la IA, no solo cómo escribe código. Si tienes 10 developers, un Skill bien definido multiplica el criterio del más experto.

Copilot Coding Agent (cloud)

Desde GitHub.com puedes asignar issues a Copilot como si fuera un colaborador del repositorio. El agente trabaja en un sandbox aislado, abre una PR con sus cambios y la notifica al equipo. El equipo revisa la PR como cualquier otra. Revisar disponibilidad antes de impartir

⚠️

La PR del agente no es una entrega: es un borrador de punto de partida. La revisión humana del diff es obligatoria antes de mergear.

Claude Code en VSCode / Terminal

Claude Code es principalmente un agente de terminal, pero se integra en VSCode vía extensión. Su punto diferencial es el contexto largo (1M tokens), el archivo CLAUDE.md como memoria persistente y un sistema de Skills y Hooks para automatizar flujos repetidos.

Características propias de Claude Code

📄
CLAUDE.md — Memoria del proyecto

Fichero de contexto persistente que lee en cada sesión. Arquitectura, reglas, convenciones y definición de terminado. Mantenlo bajo 200 líneas para que siga siendo efectivo.

🧠
Ultrathink

Activa razonamiento extendido para problemas complejos. Usa /think o /ultrathink. Útil para diseño de arquitectura, refactors con muchas dependencias o debugging difícil.

🔁
/loop — Tareas recurrentes

Permite definir una tarea que se repite automáticamente. Útil para pipelines de validación, generación de snapshots o revisiones programadas sobre nuevos commits.

🎤
/voice — Voz a prompt

Push-to-talk para dictar prompts. Soporta más de 15 idiomas. Útil cuando ya tienes las manos ocupadas en el teclado o prefieres explorar el problema verbalmente antes de escribir.

Skills en Claude Code

Un Skill es un fichero SKILL.md que define un flujo de trabajo reutilizable: instrucciones paso a paso, contexto necesario y criterio de validación. Claude lo lee y lo ejecuta de forma consistente en cada sesión.

skills/code-review/SKILL.md markdown
# Skill: Code Review de PR

## Objetivo
Revisar el diff de una PR antes de pedir revisión humana.

## Pasos
1. Lee el diff completo con `git diff main`
2. Busca: entidades JPA expuestas, NPE potenciales, SQL concatenado, logs con datos sensibles
3. Verifica que hay tests para casos feliz, borde y error
4. Genera un resumen de riesgos en formato:
   - 🔴 Crítico: [descripción]
   - 🟡 Atención: [descripción]
   - ✅ OK: [descripción]

## Reglas
- No modifiques código sin pedirlo explícitamente
- Si algo no está claro, señálalo como "revisar con el equipo"

Hooks — automatización con control

Los Hooks ejecutan comandos antes o después de que Claude use una herramienta. PreToolUse puede interceptar y pedir confirmación; PostToolUse puede ejecutar linters, tests o formatters automáticamente tras cada edición.

.claude/settings.json — Hook PostToolUse JSON
{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [{
          "type": "command",
          "command": "mvn spotless:apply && mvn test -q"
        }]
      }
    ]
  }
}

Con este hook, cada vez que Claude edite un fichero Java, se aplica el formatter y se ejecutan los tests automáticamente. El agente ve el output y corrige antes de continuar.

Otras herramientas e integraciones

Además de Copilot y Claude Code, existen opciones más especializadas. La elección depende de tu stack, tu equipo y tus restricciones (coste, privacidad, ecosistema).

Opciones complementarias

🔌
Continue.dev

Extensión de VS Code open source que integra múltiples backends (Copilot, Claude, local). Útil si quieres cambiar de proveedor sin cambiar de IDE.

Modelos locales (Ollama)

Ejecuta modelos pequeños en tu máquina sin conexión a internet. Trade-off: menos poder a cambio de privacidad total y sin costes por tokens.

🌐
APIs genéricas (OpenAI, Anthropic)

Si necesitas control fino sobre prompts, modelos o contexto, puedes usar las APIs directamente en scripts o herramientas custom.

💡 Consejo práctico

En tu primer curso, enfócate en una sola herramienta (recomendamos Copilot o Claude Code). Las habilidades de prompt engineering, revisión de código y gestión de contexto son transferibles a cualquier otra.

Comparativa de las tres herramientas en el IDE

Comparativa IDE: GitHub Copilot vs Claude Code vs Codex GitHub Copilot Claude Code OpenAI Codex Patrón común Autocompletado IDE Chat contextual Agent Mode Contexto proyecto Skills / Flujos Paralelo / Worktrees Cloud / Sandbox ✅ Nativo (Tab) ✅ @workspace ✅ Multiarchivo copilot-instructions.md Skills (Enterprise) — / Worktrees limitado ✅ Coding Agent Extensión VSCode ✅ Contexto largo 1M ✅ Terminal + Repo CLAUDE.md (persistente) SKILL.md + Hooks ✅ Subagentes — (local) CLI + App escritorio ✅ Chat API ✅ App + Cloud Skills + Automations Automations recurrentes ✅ Multi-worktree ✅ Codex Cloud Acepta / descarta Contexto = resultado Revisa cada paso Archivo persistente Reutilizable Aislar y comparar PR = revisión humana
4

Agentes Locales con Repositorio y Terminal

75 minutos

Piensa en este módulo como un patrón de trabajo, no como una herramienta concreta. Un agente local compensa cuando necesita leer varios archivos, ejecutar comandos, lanzar tests y dejar un diff que puedas revisar con el mismo rigor que una PR normal.

Estructura de carpetas recomendada para Agentes

Si vas a trabajar con agentes (más autonomía), asegúrate de que el proyecto tiene una estructura clara para que el agente entienda los límites.

Estructura típica para agentes bash
proyecto/
├── .agent-instructions.md      # Instrucciones para el agente
├── SKILL.md                      # Skills reutilizables
├── README.md                     # Documentación general
├── src/
│   ├── main/
│   │   └── java/com/company/
│   │       ├── api/
│   │       │   ├── controller/   # Controllers (REST endpoints)
│   │       │   └── dto/          # DTOs (request/response)
│   │       ├── business/
│   │       │   └── service/      # Services (lógica)
│   │       └── persistence/
│   │           ├── entity/       # Entidades JPA
│   │           └── repository/   # Repositories
│   └── test/
│       └── java/com/company/     # Tests espejo de main
├── build.gradle                  # Build config
└── .gitignore

💡 Para el agente

Cuando des una tarea al agente, referencia esta estructura explícitamente: "Añade una nueva clase Service en src/main/java/com/company/business/service/. Añade sus tests en src/test/java/com/company/business/service/"

Cuándo merece la pena pasar del IDE a un agente local

Tarea Por qué encaja Guardrail mínimo
Cambio multiarchivo Necesita seguir referencias, tocar tests y comprobar varios puntos del repositorio Acotar alcance y revisar el diff completo
Depuración con logs y terminal Combina lectura de código, ejecución y análisis de errores No aceptar el primer diagnóstico sin contrastarlo
Preparación de PR Puede resumir cambios, riesgos y pruebas ejecutadas Revisión humana del código y del texto final
Ciclo del Agente Local 1. Contexto CLAUDE.md + ficheros ref. 2. Tarea Prompt acotado y verificable 3. Ejecución Edita · Ejecuta · Informa 4. Revisión humana Diff · Tests · Riesgos Iteración si el resultado no es correcto

Contrato de trabajo seguro

  • Define el alcance: qué puede tocar y qué no
  • Da contexto persistente: arquitectura, reglas y validación
  • Supervisa comandos y diffs: la trazabilidad es obligatoria
  • Cierra con tests: build, pruebas y resumen de riesgos

Archivo de contexto del agente

Llámalo AGENT.md, CLAUDE.md o como encaje en tu herramienta. Lo importante es que concentre las reglas que no quieres repetir en cada conversación.

Archivo de contexto del agente markdown
# Proyecto
- Stack: Java 17 + Spring Boot + JPA
- Dominio principal: Orders
- Capas: Controller -> Service -> Repository

# Reglas
- No exponer entidades JPA en respuestas
- Inyección por constructor
- Nada de logs con datos sensibles
- No cambiar configuración sin pedirlo

# Validación
- Ejecuta tests relevantes
- Resume qué has cambiado
- Señala riesgos y supuestos
- Si falta contexto, no inventes

Qué sí conviene enseñar aquí

  • Cómo acotar tareas: un cambio revisable, no una feature difusa
  • Cómo dar contexto: reglas del proyecto y archivos de referencia
  • Cómo validar: comandos, diff, tests y resumen de riesgos

Qué no debe dominar este módulo

Comandos concretos, diagramas del proveedor, funciones premium, subagentes propietarios, hooks y automatismos específicos cambian demasiado rápido. Para clase basta con entender el patrón: contexto persistente, tarea acotada, ejecución supervisada y validación explícita.

4.X — MCP: conectando el agente con contexto útil

MCP (Model Context Protocol) permite conectar el agente con fuentes externas sin pegar manualmente tickets, logs, documentación o metadatos de repositorio en cada prompt.

Sin MCP

Tú copias y pegas tickets, logs, schema o decisiones del equipo cada vez que arrancas una tarea.

El contexto es parcial, repetitivo y fácil de perder por el camino.

Con MCP

El agente puede consultar esas fuentes de manera controlada y traer solo lo relevante para la tarea.

Tú sigues validando el resultado, pero reduces fricción y omisiones de contexto.

Conectores que suelen aportar más

Fuente conectadaQué aportaRiesgo a vigilar
Issue trackerCriterios de aceptación, historial del ticket, decisiones previasAsumir que el ticket está completo cuando no lo está
Repositorio y PRsPatrones reales, discusiones técnicas y contexto del cambioCopiar decisiones antiguas ya obsoletas
Logs y erroresSíntomas operativos y trazas de falloExponer datos sensibles o sobrediagnosticar
BD o documentaciónSchema, contratos, restricciones y notas del sistemaUsar fuentes desactualizadas sin verificar
ℹ️

Las credenciales nunca van en texto plano. Secretos y tokens deben ir fuera del prompt y fuera del repositorio, usando variables de entorno o el mecanismo seguro equivalente de la herramienta que uses.

Subagentes: delegar subtareas a agentes especializados

Los subagentes son una evolución del agente único: en lugar de un agente que lo hace todo, defines un agente coordinador que delega subtareas a agentes especializados. Cada subagente trabaja en paralelo, con su propio contexto y objetivo. El coordinador integra los resultados.

Arquitectura de Subagentes Agente Coordinador Recibe la tarea · divide · integra Agente Seguridad Analiza vulnerabilidades Agente Tests Genera casos de prueba Agente Docs Actualiza documentación Agente Rendimiento Detecta cuellos de botella Informe consolidado → revisión humana

Cuándo usar subagentes en tu trabajo diario

Caso de usoSubagentes que lanzarLo que supervisa el developer
Revisión de PR compleja Seguridad · Rendimiento · Cobertura de tests Informe consolidado antes del merge
Refactor de módulo grande Análisis de dependencias · Generación de tests · Actualización de docs Diff por capa y lista de riesgos
Debug en producción Análisis de logs · Revisión de código · Propuesta de fix Causa raíz y fix antes de aplicar
Migración de dependencias Inventario de usos · Borrador de cambios · Verificación de tests Alcance real del cambio y riesgos
⚠️

Subagentes ≠ más rapidez automática. Cada subagente tiene su propio contexto y puede llegar a conclusiones divergentes. El coordinador (tú, o el agente principal) necesita integrar esos resultados con criterio. Los subagentes amplían el alcance de lo que puedes revisar, no eliminan la revisión.

Skills: flujos de trabajo reutilizables entre sesiones

Un Skill es un fichero de texto que describe un flujo de trabajo completo: qué contexto necesita, qué pasos sigue y cómo valida el resultado. El agente lo lee al principio de la sesión y lo aplica de forma consistente. Sirve para que el equipo comparta criterio, no solo código.

Anatomía de un Skill útil

skills/pr-review/SKILL.md markdown
# Skill: Preparar PR para revisión

## Cuándo usarlo
Antes de pedir review a un compañero. Corre este Skill
y corrige lo que encuentre antes de abrir la PR.

## Contexto necesario
- Acceso al repositorio y al diff completo (git diff main)
- Stack: Java 17 + Spring Boot + JPA

## Pasos
1. Lee el diff con `git diff main --stat` para ver el alcance
2. Para cada fichero modificado, busca:
   a. Entidades JPA expuestas en DTOs o respuestas REST
   b. Validaciones ausentes (nulos, rangos, formatos)
   c. SQL construido por concatenación
   d. Logs con datos sensibles (PII, tokens, passwords)
3. Comprueba cobertura: ¿hay test para caso feliz, borde y error?
4. Genera resumen estructurado:
   🔴 Crítico (bloquea merge): ...
   🟡 Importante (corregir antes de merge): ...
   🔵 Sugerencia (puede ir en ticket): ...
   ✅ Sin issues detectados en: ...

## Criterio de salida
- Resumen entregado
- Ningún item 🔴 sin respuesta
- Riesgos señalados explícitamente aunque no sean bloqueantes
♻️
Reutilizable entre proyectos

El Skill describe el patrón, no el proyecto. Con pequeños ajustes en "contexto necesario" funciona en cualquier repositorio Java.

🤝
Compartible con el equipo

Commiteado en el repositorio, todos los developers usan el mismo criterio de revisión. La calidad no depende de quién ejecuta el agente.

🔄
Versionable y mejorable

Con cada PR puedes mejorar el Skill basándote en los fallos que encontró o los que se le escaparon. Mejora iterativa como cualquier otro código.

📏
Mantén la 200-línea limit

Un Skill largo se vuelve ambiguo. Si supera las 200 líneas, sepáralo en dos Skills con responsabilidades distintas.

Subagentes: delegación dentro de la tarea

Un subagente es un asistente más pequeño y especializado que se ejecuta como parte de una tarea mayor. Es útil para paralelizar trabajo, dividir responsabilidades o explorar opciones sin ejecutar todo en serie.

Escenario 1: Refactor paralelo

Quieres refactorizar una clase grande de 500 líneas. En lugar de hacer todo de una vez, delegas: un subagente extrae métodos privados, otro reorganiza dependencias, otro actualiza tests. Luego integras todos los cambios.

Escenario 2: Exploración de soluciones

Necesitas tres enfoques diferentes para resolver un problema de performance. Lanzas tres subagentes en paralelo (cada uno con su contexto y restricciones), comparas resultados, y eliges el mejor.

Escenario 3: Validación distribuida

Un subagente genera código, otro lo revisa contra el style guide, otro comprueba casos límite, otro verifica compatibilidad con versiones antiguas. Cada uno reporta sus hallazgos.

⚠️ Cuándo NO usar subagentes

5

Prompts y Revisión para Código

Cómo pedir, revisar y corregir código generado sin perder criterio técnico

⏱ 60 min

Este módulo no va de escribir prompts “bonitos”, sino de escribir instrucciones que reduzcan ambigüedad y generen salidas revisables. El prompt bueno no es el más largo: es el que deja claro el objetivo, el contexto y las restricciones.

Checklist: cómo revisar un diff generado por IA

El diff es tu línea de defensa final. Incluso si el prompt fue perfecto, siempre revisa completamente el cambio propuesto.

  • Alcance: ¿toca solo los archivos que pediste? ¿Hay cambios sorpresa?
  • Imports: ¿Todos los imports existen? ¿Hay duplicados?
  • Nombres: ¿Respeta la convención del proyecto? (camelCase, suffixes, etc.)
  • Tipos: ¿Los tipos de retorno y parámetros son correctos?
  • Errores obvios: ¿Hay referencias nulas sin null checks? ¿Casting sin validación?
  • Tests: ¿Se añadieron tests? ¿Cubren happy path y casos límite?
  • Documentación: ¿Hay JavaDoc donde es necesario? ¿Los comentarios tienen sentido?
  • Performance: ¿O(n²) inesperado? ¿Queries sin índice? ¿Loops infinitos?
  • Seguridad: ¿Hay validación de input? ¿Se escapan strings para SQL?
  • Cambios indirectos: ¿Qué métodos ahora llaman a esto? ¿Algo se rompería?
  • ⚠️ Red flags comunes

    • Reticencia: "No estoy 100% seguro pero..." - rechaza e itera
    • Complejidad sorpresa: 3 clases nuevas para algo que debería ser 1 función
    • Cambios sin pedir: Se supone que iba a tocar FileA pero también modificó FileB y FileC
    • Contratos rotos: Cambió una firma pública sin actualizar los callsites
    • Test de mentiras: El test pasa porque verifican solo el happy path
    Automatización: pre-commit hooks

    Para no tener que recordar este checklist manualmente, considera una pre-commit hook que ejecute análisis estático (SpotBugs, Sonar, linters). Si el hook falla, rechaza el commit automáticamente.

    Framework CRISP: Desglose de un Prompt Efectivo

    CRISP es un recordatorio útil, no una ley. Sirve para no olvidar las piezas que más impacto tienen en calidad y revisabilidad.

    C Contexto Quién, qué stack, qué existe R Rol Experto en qué, para quién I Instrucción Una tarea concreta S Restricciones Qué no puede hacer P Patrón / Ejemplo Código o formato esperado
    Elemento Descripción Ejemplo
    Context Qué proyecto, tecnología, restricciones "Estoy en [stack actual], con [framework y versión si afectan] y estas restricciones"
    Role Quién eres en este prompt "Actúa como ingeniero backend senior y prioriza mantenibilidad"
    Instructions Qué exactamente necesitas "Genera una entidad Usuario y su DTO con validaciones coherentes"
    Specifications Detalles técnicos específicos "Usa las librerías del proyecto, respeta la arquitectura y evita helpers innecesarios"
    Polish Formato, estilo, preferencias "Documenta solo lo necesario y explica supuestos si faltan datos"

    Prompt Deficiente

    Malo:

    "Hazme un controlador"

    Falta: contexto, tecnología, especificaciones

    Prompt Excelente

    Bueno:

    "Como ingeniero backend en este proyecto, genera un controlador para gestionar usuarios. Usa el stack y las convenciones de los archivos adjuntos, valida la entrada, separa controller, service y repository, y señala cualquier supuesto antes de generar código."

    Claro, específico, contextualizado

    Patrones avanzados de prompting para código

    No son “trucos”. Son formas de trocear el trabajo para que la salida sea más revisable, más alineada con el proyecto y menos propensa a inventar decisiones importantes.

    1. Plan antes de tocar código

    Pide análisis, alcance y riesgos antes del diff. Es especialmente útil cuando el cambio afecta a varias capas o no tienes claro el impacto.

    "Antes de proponer cambios, resume cómo funciona hoy este flujo, enumera riesgos y plantea un plan en pasos. No generes código todavía."

    2. Contrato o tests antes que implementación

    Sirve para fijar comportamiento esperado antes de pedir código. Reduce regresiones y obliga a pensar en entradas inválidas, nulos y casos límite.

    "Primero propón los tests o el contrato de esta API. Cuando estén claros, genera la implementación mínima para que pasen."

    3. Refinamiento por capas

    Evita pedir “la solución completa” de una vez. Primero estructura, luego validaciones, después errores, observabilidad y finalmente tests.

    "Empieza con una versión simple y correcta. En la siguiente iteración añade validaciones, manejo de errores y pruebas. Explica cada cambio."

    4. Contexto real del repositorio

    La mejor forma de reducir respuestas genéricas es aportar ficheros de referencia, convenciones del proyecto y una definición clara de terminado.

    "Usa estos archivos como referencia de estilo y arquitectura. No inventes capas nuevas. Si falta contexto, dilo antes de generar cambios."

    Errores Comunes y Soluciones

    Error Común Síntoma Solución
    Falta de contexto Código genérico, no alineado con tu stack Siempre abre con: "Estoy en [stack real], con estas restricciones y estos archivos de referencia"
    Especificaciones vagas Resultado correcto pero no lo que querías Sé explícito: "Usa Lombok, no data classes"
    Olvidar seguridad Código sin validaciones ni SQL injection prevention Pide explícitamente: "Incluye validaciones de entrada y prepared statements"
    Prompt muy largo AI se pierde en detalles Estructura: Context → Role → Instructions → Specs. Una idea por pregunta.
    No mostrar requisitos no-funcionales Falta logging, monitoreo, documentación Menciona: "Incluye logging SLF4J y métricas"

    Plantillas de Prompts Reutilizables

    Úsalas como punto de partida y adapta stack, restricciones y convenciones del proyecto. Si el equipo ya tiene patrones claros, esas referencias valen más que cualquier prompt genérico.

    Plantilla: Entidad + DTO

    Estoy en [stack backend] con [ORM o framework]. A partir de este contexto, genera:
    
    1. Una entidad [NombreEntidad] con estos campos:
       [listar campos con tipos]
    
    2. Un DTO separado para entrada o salida, según corresponda
    
    3. Validaciones y anotaciones solo si encajan con este proyecto
    
    Restricciones:
    - Respeta la arquitectura y convenciones de los archivos adjuntos
    - No inventes helpers, utilidades ni capas nuevas
    - Si detectas una decisión ambigua, enumérala antes de generar código
    - Devuelve imports correctos y nombres consistentes con el repositorio

    Plantilla: Servicio

    Genera un servicio de aplicación para [NombreDominio] siguiendo la arquitectura existente del proyecto.
    
    Necesito:
    1. Métodos y casos de uso concretos: [listar]
    2. Dependencias ya existentes que debe reutilizar
    3. Transaccionalidad donde aplique
    4. Validación de entrada y errores de negocio coherentes
    5. Logging solo donde aporte trazabilidad real
    
    No pongas lógica de negocio en el controller. Si la capa service actual del proyecto sigue otro patrón, ajústalo a ese patrón en lugar de inventar uno nuevo.

    Plantilla: Tests

    Genera tests para [Clase o caso de uso] usando el framework que ya tiene este proyecto.
    
    Quiero que cubras:
    1. Caso correcto
    2. Entradas inválidas o incompletas
    3. Casos límite y nulos
    4. Errores esperados del dominio
    5. Verificación de efectos laterales relevantes
    
    Reglas:
    - No dependas del orden de ejecución
    - No uses sleeps ni temporizadores arbitrarios
    - Si faltan dependencias o contexto para un test fiable, indícalo antes de inventar mocks irreales

    Plantilla: Thymeleaf

    Genera un template Thymeleaf para [caso de uso] siguiendo la estructura visual y de fragments que ya usa el proyecto.
    
    Incluye:
    1. Tabla o formulario según el caso
    2. Enlaces y acciones con `th:href` o `th:action`
    3. Mensajes de validación y estados vacíos
    4. Nombres de variables coherentes con el controller
    5. Clases CSS existentes antes de proponer estilos nuevos
    
    Si el proyecto mezcla Thymeleaf con Bootstrap u otra librería, reutiliza los componentes reales en lugar de crear HTML genérico.

    6.X — Cuando la IA Falla: Señales y Soluciones

    Saber cuándo no confiar en el output es tan importante como saber promtear bien. Estas son las señales de alarma que debes reconocer desde el primer día.

    Señal de alarmaPor qué ocurreQué hacer
    Inventa métodos que no existen
    Ej: repository.findByActiveAndNotDeleted() no existe
    El modelo genera nombres plausibles basándose en patrones. No verifica la API real. Especifica la versión exacta del framework. Abre los archivos relevantes antes de preguntar.
    Olvida restricciones a mitad de conversación
    Empieza a usar @Autowired después de que le dijiste que no
    La ventana de contexto se llena y las instrucciones iniciales pierden peso. Usa /compact y repite las restricciones clave. Mejor aún: ponlas en CLAUDE.md.
    Genera código que compila pero no hace lo que pediste
    El test pasa pero la lógica está mal
    Optimiza para satisfacer el prompt literal, no la intención real. Describe el comportamiento esperado, no la implementación. Añade casos de prueba al prompt.
    Arregla el test en lugar del código
    Cambia el assert para que el test pase
    El objetivo "pasar el test" puede cumplirse de varias formas. Elige la fácil. Sé explícito: "El test es correcto, arregla la implementación, no el test."
    Responde con confianza algo incorrecto
    Afirma que una versión o API concreta soporta X (y no es verdad)
    Los LLMs no saben lo que no saben. Generan con el mismo tono sea verdad o no. Para afirmaciones sobre versiones o APIs específicas, verifica siempre en la documentación oficial.
    Genera solución demasiado compleja
    Un factory pattern de 4 clases para un if-else
    Entrenado con código de repositorios "impresionantes", tiende al over-engineering. Añade al prompt: "La solución más simple posible. Prioriza legibilidad sobre sofisticación."

    ⏱ La regla de los 3 intentos

    Si después de 3 iteraciones el output sigue sin ser correcto, para y hazlo tú. Seguir iterando con un modelo que no entiende el problema consume más tiempo del que ahorras. Usa la IA para el siguiente subtarea más pequeña y bien definida.

    6.X — Cuándo NO Usar la IA

    La IA no es la herramienta correcta para todo. Usarla indiscriminadamente genera código que no entiendes, deuda técnica invisible, y dependencia que te hace menos productivo a largo plazo.

    ✅ IA muy útil

    • Boilerplate y código repetitivo
    • Convertir especificación a código inicial
    • Generar tests para código ya escrito
    • Entender código ajeno o legacy
    • Refactoring mecánico (renombrar, extraer método)
    • Documentación y JavaDoc
    • Primeras implementaciones que luego refinas

    ⚠️ IA con precaución

    • Decisiones de arquitectura (la IA no conoce tu contexto de negocio)
    • Lógica de negocio crítica sin revisión exhaustiva
    • Código de seguridad (auth, criptografía, validación)
    • Migraciones de base de datos
    • Problemas que no sabes describir claramente
    • Algo que no entenderías aunque lo leyeras
    07

    Taller Central: Del Prompt al PR

    El núcleo del curso: generar, revisar, corregir, probar y decidir

    ⏱ 60 min
    ℹ️

    Este taller es la parte más importante del curso. El objetivo no es ver una demo bonita, sino practicar el ciclo que luego usarás en proyectos reales: contexto, prompt, diff, tests, revisión y decisión. El primer ejercicio es guiado, el segundo semi-guiado y el tercero queda como trabajo posterior.

    Ejercicio 1 — Guiado (20 min): Endpoint con Test

    El instructor ejecuta esto en vivo. El equipo sigue en sus propias máquinas.

    🎯 Objetivo

    Implementar GET /api/orders/summary que devuelva el número total de pedidos, importe total y pedido de mayor valor. El foco no es “no tocar código a mano”, sino aprender a dirigir la IA y a revisar el resultado con el nivel de exigencia de una PR real.

    Paso 1 — Inicializar el contexto (2 min)

    Antes de escribir ningún prompt, abre estos archivos en tabs: Order.java, OrderRepository.java, OrderService.java, OrderController.java. Si usas un agente con instrucciones persistentes, prepara el archivo de contexto del proyecto antes de pedir cambios.

    Paso 2 — El prompt inicial (5 min)

    ✅ Prompt de partida — pégalo tal cual
    Añade a nuestro proyecto, respetando el stack y las convenciones actuales, un endpoint GET /api/orders/summary que: 1. Devuelva un record OrderSummaryResponse con: totalOrders (Long), totalRevenue (BigDecimal), highestOrderValue (BigDecimal) 2. El Service calcule estos valores usando streams sobre findAll() (por ahora, sin optimizar) 3. El Controller delegue en OrderService.getOrderSummary() 4. Incluye tests unitarios del Service: caso con pedidos, caso con lista vacía 5. Sigue las convenciones de los archivos que tienes abiertos (inyección constructor, records para DTOs) No optimices todavía con queries JPQL — hazlo simple y legible primero.

    Paso 3 — Revisar el output (5 min)

    Antes de ejecutar nada, revisa el código generado buscando estos puntos concretos:

    Paso 4 — Ejecutar y verificar (5 min)

    Terminal Bash
    # Ejecutar solo los tests nuevos
    mvn test -Dtest=OrderServiceTest -q
    
    # Si pasan, arrancar y probar el endpoint
    mvn spring-boot:run &
    curl http://localhost:8080/api/orders/summary | jq .

    Paso 5 — Optimizar con un segundo prompt (3 min)

    ✅ Prompt de optimización
    Ahora optimiza OrderService.getOrderSummary(): en lugar de findAll() + streams en Java, crea una query JPQL en OrderRepository que calcule los tres valores en una sola consulta a la BD. Actualiza el test de integración si existe, o crea uno nuevo con @DataJpaTest.

    Ejercicio 2 — Semi-guiado (30 min): Revisión Manual de Pedidos

    Ahora trabajáis en parejas. Tenéis el esqueleto del prompt — completadlo y ejecutadlo.

    🎯 Objetivo

    Implementar un flujo de revisión manual de pedidos (OrderReview): un pedido puede quedar marcado para revisión con motivo y estado, pero no debe tener dos revisiones abiertas al mismo tiempo.

    Vuestro punto de partida

    ✅ Prompt base — completad los [HUECOS]
    Implementa un módulo de revisión manual de pedidos con estas restricciones: Entity OrderReview: id, reason (obligatorio), status, createdAt, relación ManyToOne con Order y con User Restricciones de negocio: - Un pedido no puede tener dos revisiones abiertas al mismo tiempo - [AÑADID: qué estados permitís y cómo cambia de uno a otro] Endpoints necesarios: - [DEFINID vosotros los endpoints que tendría sentido] También necesito: - [AÑADID qué tests queréis] - Vista Thymeleaf con [DESCRIBID qué queréis ver] Sigue las convenciones de [REFERENCIA A VUESTROS ARCHIVOS ABIERTOS]
    💡

    El objetivo del ejercicio no es terminar. Es practicar el ciclo: prompt → revisar → iterar → revisar. Anotad cuántas iteraciones necesitasteis y qué errores encontrasteis al revisar.

    Criterios de revisión para vuestro propio PR

    Ejercicio 3 — Libre (para casa): Code Review de vuestro propio código

    🎯 Objetivo

    Coge un Service real de vuestro proyecto en producción — uno que lleve tiempo ahí y que nadie haya revisado en profundidad. Pásalo por el asistente o agente que use el equipo con el prompt de abajo. Comparad los hallazgos con lo que vosotros hubierais encontrado.

    ✅ Prompt de code review — cópialo y pega tu Service
    Revisa este Service como un senior developer en code review. Sé directo y específico. Busca: 1. RENDIMIENTO: queries N+1, falta de índices, operaciones costosas en bucles 2. SEGURIDAD: inputs sin validar, queries con concatenación de strings, datos sensibles en logs 3. SOLIDEZ: null pointers potenciales, casos límite no contemplados, manejo de excepciones inadecuado 4. DISEÑO: violaciones SOLID, métodos que hacen demasiado, acoplamiento innecesario 5. TESTS: qué casos no están cubiertos que deberían estarlo Para cada problema: indica severidad (🔴 crítico / 🟡 medio / 🟢 menor), línea aproximada, qué hay mal y cómo lo arreglarías en concreto. No me des el código corregido completo — dame las instrucciones para que yo lo corrija y aprenda.

    Adopción Real en Equipos de Desarrollo

    Qué debe cambiar en el trabajo diario para que la IA aporte sin degradar la calidad

    Checklist de Mejores Prácticas

    HAZLO

    • ✓ Revisa y edita todo código generado
    • ✓ Verifica seguridad y cumplimiento
    • ✓ Mantén el control de versiones limpio
    • ✓ Contextualiza tus prompts (CRISP)
    • ✓ Usa prompts específicos para cada tarea
    • ✓ Combina AI con pruebas automáticas
    • ✓ Documenta decisiones de diseño
    • ✓ Itera y refina con feedback
    • ✓ Mantén un journal de patrones efectivos
    • ✓ Comparte conocimiento del equipo

    NO HAGAS

    • ✗ No uses prompts genéricos o vagos
    • ✗ No confíes ciegamente en sugerencias
    • ✗ No copies-pegues sin entender
    • ✗ No desatiendas la seguridad
    • ✗ No ignores las mejores prácticas del equipo
    • ✗ No olvides documentar por qué cambios
    • ✗ No uses AI sin tests posteriores
    • ✗ No dejes código sin revisar
    • ✗ No asumas que el AI siempre está correcto
    • ✗ No pierdas el aprendizaje en el proceso

    Consideraciones de Seguridad

    Datos Sensibles

    Nunca compartas con AI público: contraseñas reales, tokens, keys, datos de clientes, IPs internas.

    ✓ Usa entornos privados o corporativos para código sensible.

    ✓ Sanitiza ejemplos antes de compartir.

    Inyección de Prompts

    Si usas AI para procesar input de usuarios, valida y sanitiza siempre.

    El mismo cuidado que con SQL injection: nunca concatenes user input directamente en prompts.

    Derechos de Autor

    Verifica que el código generado no infriga licencias (GPL, AGPL, etc.).

    Revisa la política de licencias y entrenamiento del proveedor que uses antes de incorporar código generado a un proyecto real.

    Prácticas Seguras

    • Revisa todas las dependencias que AI sugiere
    • Usa SBOM (Software Bill of Materials) tools
    • Mantén dependencias actualizadas
    • Ejecuta SAST (Static Analysis) en código generado
    • Prueba edge cases y errores específicos

    Qué debería salir del curso

    Si el curso funciona, al terminar no tendrás un catálogo memorizado: tendrás un método de trabajo reutilizable dentro del equipo.

    A Nivel Individual

    Mejor arranque

    Menos tiempo en código repetitivo y más foco en revisar comportamiento y diseño.

    Mejor lectura

    Uso de la IA para entender legacy, preparar refactors y localizar edge cases.

    Mejor criterio

    Saber cuándo insistir, cuándo acotar más y cuándo parar y hacerlo manualmente.

    A Nivel de Equipo

    Reglas compartidas

    Qué cambios se permiten con IA, qué revisión mínima se exige y qué datos nunca se pegan.

    PRs mejores

    Diffs más pequeños, tests obligatorios y contexto suficiente para que la review no sea una lotería.

    Playbook común

    Prompts útiles, checklists de revisión y ejemplos de tareas que sí merece delegar.

    A Nivel de Liderazgo

    Guardrails claros

    Política sobre datos sensibles, herramientas permitidas y trazabilidad de cambios.

    Medición útil

    Medir tiempo de ciclo, calidad de PRs y cobertura, no solo “cuántos prompts se lanzan”.

    Adopción progresiva

    Empezar con casos de bajo riesgo y ampliar solo cuando el proceso ya sea reproducible.

    Integración con tu Flujo Git y PRs

    La IA no vive fuera de tu workflow — tiene que encajar en él. Aquí el patrón que funciona mejor en equipos con PRs y code review:

    1. Crea la rama antes de abrir la IA

    La IA va a editar archivos. Trabaja siempre en una feature branch y revisa el estado del repo antes de empezar. Si necesitas descartar cambios, hazlo con criterio sobre el diff, no con comandos globales y ciegos.

    2. Commits atómicos mientras iteras

    Haz commits pequeños después de cada bloque que hayas revisado y validado. No esperes al final — si el agente rompe algo en la siguiente iteración, tienes un punto de retorno limpio.

    Convención de commits con IA Bash
    # Opcional: indica en el commit que fue asistido por IA
    git commit -m "feat(orders): add summary endpoint [ai-assisted]"
    
    # Así el equipo sabe qué revisar con más atención en el PR

    3. Antes del PR: revisa el diff completo

    Ejecuta git diff main y lee cada cambio. El code review de tus compañeros no reemplaza tu propia revisión — tú eres el responsable de lo que pushas, lo haya escrito un humano o una IA.

    4. En la descripción del PR, sé transparente

    No es obligatorio, pero si una parte significativa fue generada por IA, mencionarlo ayuda al reviewer a saber dónde poner más atención. Muchos equipos están adoptando convenciones como [ai-assisted] en el título.

    5. Usa la IA para revisar PRs de otros

    Pega el diff en el chat o usa la integración disponible y pide una revisión con el prompt del Ejercicio 3. La IA no sustituye la aprobación humana, pero sí puede ayudarte a llegar con mejores preguntas a la review.

    Checklist de Revisión para Código Generado por IA

    Úsala en tus primeras semanas hasta que desarrolles el instinto. Después la habrás interiorizado.

    CategoríaQué revisarSeñal de problema
    🔴 Seguridad Inputs validados, no hay SQL concatenado, no hay datos sensibles en logs String query = "SELECT * FROM users WHERE id=" + userId
    🔴 Nulos Optional usado correctamente, no hay NPE potenciales user.getAddress().getCity() sin comprobar nulos
    🟡 Rendimiento No hay queries N+1, no hay findAll() sobre tablas grandes Loop con llamada a repository dentro
    🟡 Transacciones @Transactional en métodos que modifican datos, rollback correcto Dos saves sin @Transactional — si el segundo falla, el primero ya está en BD
    🟡 Edge cases Lista vacía, valor 0, string vacío, fecha en el pasado Asumir que la lista siempre tiene al menos un elemento
    🟢 Convenciones Inyección por constructor, nomenclatura, formato @Autowired en campo, nombres en inglés cuando el proyecto usa español
    🟢 Tests Cubren el caso feliz Y los casos de error Solo el test del happy path, sin probar excepciones

    Seguridad: Qué No Pegar Nunca en el Chat

    Tipo de dato¿Pegar?Alternativa
    Código de negocio, entidades, services ✅ Sí
    Stack traces y logs de error (sin datos de usuarios) ✅ Sí
    API keys, tokens, passwords ❌ Nunca Usa placeholders: API_KEY_HERE
    Datos personales de usuarios reales (emails, nombres, DNIs) ❌ Nunca Anonimiza o usa datos ficticios
    application.properties con credenciales de producción ❌ Nunca Pega solo la estructura con valores como ${DB_PASS}
    Logs con datos de producción ⚠️ Con cuidado Elimina IDs de usuarios, IPs, emails antes de pegar
    Código propietario de clientes bajo NDA ⚠️ Consultar Revisa la política de vuestra empresa antes

    Tu Plan de los Primeros 30 Días

    El error más común es querer usar todo a la vez desde el día uno. La adopción que funciona en equipos serios es progresiva: primero criterio, luego repetibilidad, después automatización.

    📅
    Semana 1 — Uso acotado

    Úsala solo en tareas que ya sabes evaluar: boilerplate, tests sencillos, lectura de código y dudas localizadas. Objetivo: aprender a detectar rápido cuándo ayuda y cuándo estorba.

    💬
    Semana 2 — Chat y revisión

    Empieza a pedir explicaciones, tests y revisiones de diffs. Objetivo: convertir la IA en una ayuda para pensar y revisar, no solo para escribir.

    🔨
    Semana 3 — Cambio real y pequeño

    Haz una tarea de producción bien delimitada: un endpoint, un DTO, unos tests o una refactorización mecánica. Objetivo: completar una PR pequeña con revisión exhaustiva.

    🚀
    Semana 4 — Flujo supervisado

    Solo entonces prueba agentes multiarchivo o terminal con una tarea que siga siendo reversible. Objetivo: que el equipo tenga un flujo repetible y no una colección de trucos personales.

    Diff revisado antes de cada commit
    Tests obligatorios en cambios asistidos
    Scope pequeño mientras el equipo aprende
    Criterio humano siempre por encima del asistente
    💰

    Referencia Temporal: Planes y Costes

    Material orientativo: revisar siempre antes de impartir

    Cómo tratar esta parte en clase

    Los precios, límites de uso, modelos incluidos y nombres de plan cambian con frecuencia. Esta sección debe revisarse siempre antes de impartir el curso. No es el centro de la formación: solo sirve para evitar elegir herramientas a ciegas.

    Pregunta Qué revisar Por qué importa
    ¿Plan individual o de equipo? Permisos, política de datos, trazabilidad y gestión centralizada En entornos reales suele pesar más la gobernanza que el precio
    ¿Qué límites tiene el plan? Mensajes, tiempo de uso, herramientas avanzadas, ejecución remota Condiciona si el flujo cabe de verdad en el día a día del equipo
    ¿Qué integración trae? IDE, terminal, Git, PRs, políticas empresariales Una herramienta barata pero mal integrada genera más fricción que ahorro
    ¿Merece la pena pagar más? Compara coste contra tiempo ahorrado en PRs, tests, refactors y soporte a legacy La decisión correcta depende del flujo real, no del listado de features

    Recomendación docente

    Para impartir el curso suele bastar con comparar una herramienta integrada en IDE y una herramienta más orientada a terminal/agente. Eso permite enseñar criterios reales sin convertir la sesión en una comparativa comercial.

    📋

    Checklist de Adopción: Primeros 30 Días

    Un plan mínimo para pasar de la curiosidad a un uso repetible y supervisado

    Día 1: dejar un flujo mínimo funcionando

    Semana 1: crear criterio, no dependencia

    Día 30: adopción controlada en el equipo

    Señales de que la adopción va bien

    Señal Qué significa Qué hacer si no ocurre
    PRs más pequeñas y mejor explicadas La IA se está usando con alcance controlado Reducir el scope de las tareas y exigir diff más corto
    Más tests y más casos límite cubiertos Se usa para reforzar calidad, no solo para teclear menos Obligar a pedir tests y revisar vacíos, nulos y validaciones
    Menos tiempo en arrancar tareas mecánicas El equipo ha encontrado dónde realmente aporta Volver a casos simples y evitar tareas ambiguas
    Las reviews detectan menos “sorpresas” Hay contexto, reglas y guardrails compartidos Reforzar instrucciones del proyecto y checklist de revisión
    📚

    Recursos & Enlaces Oficiales

    Fuentes primarias para revisar herramientas, planes y compatibilidades antes de usar material temporal