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.
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é.
| 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.
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
- 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.
📋 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
Elegir Herramienta sin Casarte con una Marca
45 minutosLo 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.
# 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.
@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);
}
}
@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.
IA dentro del IDE: contexto corto, iteración rápida
75 minutosEste 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).
# 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.
# 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)
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
@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
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.
# 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.
# 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.
{
"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
Agentes Locales con Repositorio y Terminal
75 minutosPiensa 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.
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 |
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.
# 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 conectada | Qué aporta | Riesgo a vigilar |
|---|---|---|
| Issue tracker | Criterios de aceptación, historial del ticket, decisiones previas | Asumir que el ticket está completo cuando no lo está |
| Repositorio y PRs | Patrones reales, discusiones técnicas y contexto del cambio | Copiar decisiones antiguas ya obsoletas |
| Logs y errores | Síntomas operativos y trazas de fallo | Exponer datos sensibles o sobrediagnosticar |
| BD o documentación | Schema, contratos, restricciones y notas del sistema | Usar 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.
Cuándo usar subagentes en tu trabajo diario
| Caso de uso | Subagentes que lanzar | Lo 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
# 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.