Objetivo de esta guía
La IA puede ayudar mucho a un equipo de desarrollo: puede generar código, explicar clases, proponer tests, resumir documentación o revisar una pull request.
Pero hay una idea muy importante:
Usamos IA para ir más rápido, no para pensar menos.
Esta guía explica, con lenguaje sencillo y ejemplos de poca complejidad, qué debería conocer un equipo que trabaja con Java, Spring Boot y microservicios para aprovechar la IA sin perder criterio técnico.
La IA no es un arquitecto de software
La IA puede ayudar a escribir código, pero no debería decidir por sí sola cómo se diseña un sistema.
Un equipo técnico sigue siendo responsable de decidir cosas como:
- qué hace cada microservicio;
- qué datos pertenecen a cada servicio;
- cómo se comunican los servicios;
- cómo se gestionan los errores;
- cómo se protege la información;
- cómo se hacen los tests;
- cómo se mantiene el código a largo plazo.
Ejemplo sencillo
Le pides a la IA:
La IA podría proponer algo así:
Esto puede parecer cómodo, pero en microservicios suele ser una mala idea.
Cada microservicio debería ser dueño de sus propios datos. Un servicio no debería consultar directamente la base de datos de otro.
Mejor enfoque
Una forma más sana sería:
Idea clave
La IA puede proponer opciones, pero el equipo debe decidir si esas opciones tienen sentido técnico.
Código que compila no siempre es código correcto
La IA puede generar código que parece limpio y que incluso compila, pero eso no significa que sea buen código.
Ejemplo malo
A primera vista parece correcto, pero tiene varios problemas:
- el controlador accede directamente al repositorio;
- devuelve una entidad JPA en la API;
- no hay DTO;
- no hay manejo claro de errores;
- no se ve ninguna validación de permisos;
- puede exponer campos internos de la base de datos.
Versión más recomendable
Aquí el controlador no sabe cómo se busca el usuario. Solo delega en un caso de uso.
Idea clave
No basta con que el código compile. Debe ser seguro, entendible, testeable y coherente con la arquitectura.
La IA debe respetar la arquitectura del proyecto
La IA suele generar ejemplos genéricos. Si no le explicas cómo está organizado tu proyecto, puede mezclar capas o crear código difícil de mantener.
Estructura sencilla recomendada
Qué significa cada capa
api
Contiene lo que se expone hacia fuera:
- controllers;
- DTOs de entrada;
- DTOs de salida.
application
Contiene los casos de uso:
- crear usuario;
- buscar usuario;
- actualizar usuario;
- eliminar usuario.
domain
Contiene las reglas principales del negocio:
- modelos de dominio;
- validaciones importantes;
- excepciones de negocio.
infrastructure
Contiene detalles técnicos:
- base de datos;
- repositorios JPA;
- clientes HTTP;
- mensajería;
- integración con otros sistemas.
Ejemplo de prompt útil
Idea clave
La IA debe adaptarse a la arquitectura del equipo, no al revés.
Pedir bien a la IA: prompts sencillos y útiles
Un prompt es la instrucción que le das a la IA.
Un mal prompt da resultados genéricos. Un buen prompt da resultados más útiles.
Prompt demasiado vago
La IA no sabe:
- qué versión de Java usas;
- si usas DTOs;
- si usas MapStruct;
- si quieres tests;
- si tienes arquitectura hexagonal;
- cómo manejas errores.
Prompt más útil
Idea clave
Cuanto mejor expliques el contexto, mejor será la respuesta de la IA.
No aceptar código generado sin tests
Una regla muy sana para el equipo sería:
Todo código generado por IA debe venir acompañado de tests.
La IA puede escribir código rápido, pero el equipo necesita comprobar que funciona.
Ejemplo de caso de uso
Tests que deberíamos pedir
Ejemplo de test sencillo
Cuidado con ,[object Object]
La IA tiende a usar esto para todo:
Pero no siempre hace falta arrancar toda la aplicación.
Guía sencilla
Tabla en texto: tipo de test y cuándo usarlo
| Tipo de test | Cuándo usarlo |
|---|---|
@Test | Para lógica de negocio simple |
@WebMvcTest | Para probar controllers |
@DataJpaTest | Para probar repositorios |
@SpringBootTest | Para pruebas más completas de integración |
Para equipos que quieran subir nivel
Además de lo básico, suele aportar valor incluir:
- tests de contrato entre microservicios (consumer/provider);
Testcontainerspara integrar con base de datos o Kafka reales de test;- una pirámide de tests equilibrada (más unitarios, menos end-to-end);
- criterios mínimos de calidad en PR (por ejemplo, cobertura por módulo y casos borde).
Idea clave
La IA puede escribir código, pero los tests ayudan a demostrar que ese código se comporta como esperamos.
Seguridad: la IA puede generar código peligroso
La IA puede generar código inseguro sin darse cuenta.
Ejemplo peligroso
Problemas:
- permite llamadas desde cualquier origen;
- parece un endpoint de administración;
- no se ve autorización;
- devuelve entidades JPA;
- puede exponer datos sensibles;
- no tiene paginación.
Versión mejor pensada
Sigue siendo un ejemplo simple, pero ya mejora varios puntos:
- exige rol de administrador;
- usa DTO;
- tiene paginación;
- delega en un caso de uso.
Checklist de seguridad al revisar código generado por IA
Antes de aceptar código, revisar:
- ¿hay autenticación?
- ¿hay autorización?
- ¿se exponen datos sensibles?
- ¿se validan los datos de entrada?
- ¿se están logando tokens o datos personales?
- ¿hay endpoints administrativos sin protección?
- ¿hay CORS abierto sin necesidad?
- ¿se devuelven entidades JPA directamente?
- ¿hay riesgo de inyección (SQL, NoSQL, LDAP)?
- ¿hay riesgo de SSRF al llamar URLs externas?
- ¿hay deserialización insegura de datos no confiables?
- ¿hay mass assignment (se actualizan campos que no deberían)?
- ¿se exponen trazas internas en errores HTTP?
- ¿los secretos están fuera del código y rotados?
Referencia útil
Si el equipo necesita una base común, podéis usar OWASP ASVS como checklist más completo de seguridad.
Idea clave
La salida de una IA debe tratarse como código escrito por alguien externo: hay que revisarlo.
Transacciones en Spring Boot
La IA suele poner @Transactional en muchos métodos sin explicar por qué.
Ejemplo sencillo
Este caso puede tener sentido porque es una operación de escritura en base de datos.
Ejemplo con posible problema
Aquí hay que pensar más.
El método abre una transacción de base de datos y además llama a un servicio externo de email.
¿Qué pasa si?
- se guarda el usuario pero falla el email;
- el email tarda mucho;
- el servicio externo no responde;
- se envía el email pero luego falla la transacción.
Mejor idea
Una opción más segura puede ser:
Detalle importante: evitar perder eventos
Si publicas el evento justo después del commit, aún puede fallar esa publicación.
Para sistemas críticos, es habitual usar patrón Transactional Outbox:
Así reduces el riesgo de "dato guardado pero evento perdido".
Idea clave
No metas llamadas externas dentro de una transacción sin pensarlo bien.
Microservicios: cuidado con las soluciones demasiado simples
La IA puede proponer una solución que funciona en local, pero falla en sistemas reales.
Ejemplo sencillo
Tenemos dos microservicios:
La IA podría proponer:
Parece fácil.
Pero hay que hacerse preguntas:
- ¿qué pasa si Payment Service está caído?
- ¿qué pasa si cobra pero no responde?
- ¿qué pasa si Order Service reintenta y cobra dos veces?
- ¿cómo sabemos en qué estado quedó el pedido?
- ¿cómo lo trazamos en logs?
Conceptos útiles
Idempotencia
Evita repetir una operación peligrosa.
Ejemplo:
Retry con backoff
Reintenta una operación, pero esperando entre intentos.
Importante: no reintentar sin control operaciones no idempotentes, porque puedes duplicar cobros o pedidos.
Circuit breaker
Evita seguir llamando a un servicio que está fallando.
Timeouts explícitos
No dejes llamadas remotas sin límite de tiempo.
Sin timeout, un hilo puede quedarse bloqueado y degradar todo el servicio.
Bulkhead (aislamiento)
Separa recursos para que un fallo en una integración no arrastre todo.
Correlation ID
Identificador común para seguir una operación entre servicios.
Así es más fácil investigar problemas.
Idea clave
En microservicios, no basta con llamar a otro servicio. Hay que pensar en fallos, reintentos, duplicados y trazabilidad.
No confiar en dependencias inventadas
La IA puede inventar librerías, nombres de clases o versiones.
Ejemplo inventado
Puede parecer real, pero no existir.
Qué debe hacer el equipo
Antes de añadir una dependencia sugerida por IA, revisar:
- si existe;
- si está mantenida;
- si tiene buena documentación;
- si tiene licencia compatible;
- si tiene vulnerabilidades conocidas;
- si realmente hace falta;
- si Spring ya ofrece una solución oficial o más estándar;
- qué dependencias transitivas arrastra;
- si podemos fijar versión exacta y evitar upgrades accidentales;
- si aparece en una SBOM del proyecto;
- si viene de un repositorio permitido por la empresa.
Recomendación práctica
Para proyectos de empresa, conviene definir una política simple:
Prompt útil
Idea clave
No copies dependencias sugeridas por IA sin verificarlas.
Usar IA con código legacy
La IA puede ser muy útil para entender código antiguo, pero también puede inventar explicaciones.
Prompt peligroso
La IA puede responder con mucha seguridad aunque no tenga suficiente contexto.
Prompt mejor
Ejemplo
Si una clase se llama:
La IA podría decir:
Eso puede ser cierto, pero hay que comprobarlo en el código.
Quizá realmente:
- lee clientes de una tabla;
- llama a una API externa;
- guarda logs;
- cambia estados;
- borra registros antiguos.
Idea clave
La IA ayuda a entender legacy, pero no conoce la historia real del sistema si no se la das.
MapStruct: revisar los mapeos
MapStruct es muy útil para transformar objetos, pero hay que revisar bien qué se está mapeando.
Ejemplo sencillo
Esto parece bien si los campos coinciden.
Posible problema
Imagina que UserEntity tiene este campo:
Y UserResponse también tiene un campo parecido por error.
La IA podría generar o aceptar un mapeo que exponga información sensible.
Mejor DTO
No incluimos passwordHash.
Qué revisar en mapeos generados por IA
- campos sensibles;
- campos con nombres parecidos pero distinto significado;
- fechas;
- dinero;
- enums;
- nulls;
- relaciones JPA;
- listas grandes;
- datos calculados;
- IDs internos y externos.
Idea clave
Que MapStruct pueda mapear algo no significa que deba mapearlo.
API primero, código después
Una mala práctica es pedir directamente el código del controller.
Prompt pobre
Mejor enfoque
Primero pedir el contrato:
Ejemplo de contrato simple
Request:
Response:
Errores:
Buenas prácticas de contrato API
Además del ejemplo simple, ayuda definir también:
- formato estándar de errores (por ejemplo
application/problem+json); - versionado de API;
- compatibilidad hacia atrás;
- reglas de paginación, ordenación y filtros;
- cuándo una operación debe ser idempotente y cómo garantizarlo.
Después de tener esto claro, ya tiene sentido generar código.
Idea clave
Primero piensa el contrato. Luego genera la implementación.
Documentación técnica con IA
La IA es muy buena ayudando a documentar.
Puede generar:
- README;
- ADRs;
- changelogs;
- documentación de APIs;
- guías de onboarding;
- diagramas Mermaid;
- resúmenes de decisiones técnicas.
Ejemplo de ADR sencillo
Prompt:
Resultado esperado:
Cuidado
La IA puede documentar cosas que no existen en el proyecto.
Por ejemplo, puede escribir:
Pero quizá vuestro sistema no usa Kafka.
Idea clave
La IA puede redactar documentación, pero el equipo debe validar que describe la realidad.
Patrones de diseño: no usarlos porque sí
La IA puede recomendar patrones aunque no hagan falta.
Puede proponer:
- arquitectura hexagonal;
- DDD;
- CQRS;
- saga;
- event sourcing;
- factory;
- strategy;
- mediator.
Todos pueden ser útiles, pero no siempre.
Ejemplo simple
Tienes una aplicación pequeña que solo guarda notas:
La IA podría proponer:
Pero eso probablemente es demasiado.
Pregunta que debe hacer el equipo
Ejemplo de buen uso de patrón
Si tienes varios métodos de pago:
Puede tener sentido usar Strategy:
Pero si solo tienes un método de pago, quizá no hace falta.
Idea clave
Un patrón es bueno cuando resuelve un problema real, no cuando hace que el código parezca más sofisticado.
IA como apoyo en code review
La IA puede ser un revisor adicional, pero no debe aprobar código por sí sola.
Prompt útil para revisar una PR
Qué puede detectar bien
- métodos demasiado largos;
- errores de null;
- falta de validaciones;
- nombres confusos;
- duplicación;
- tests insuficientes;
- endpoints sin seguridad;
- uso incorrecto de DTOs.
Qué puede no entender bien
- contexto de negocio;
- decisiones históricas;
- restricciones de la empresa;
- deuda técnica aceptada;
- planes futuros del equipo;
- acuerdos internos no escritos.
Idea clave
La IA puede ayudar a revisar, pero la responsabilidad final es humana.
Privacidad y datos sensibles
El equipo debe tener reglas claras sobre qué se puede pegar en una herramienta de IA.
No pegar sin permiso
- contraseñas;
- tokens;
- claves privadas;
- datos personales;
- información médica;
- datos bancarios;
- logs con emails o teléfonos;
- dumps de base de datos;
- contratos privados;
- código propietario sensible;
- configuraciones productivas.
Ejemplo malo
Si el log contiene tokens, emails o datos personales, puede ser un problema.
Mejor enfoque
Anonimizar antes:
Regla sencilla
Si no lo subirías a un foro público, no lo pegues en una IA externa sin aprobación.
Idea clave
La IA debe usarse respetando privacidad, seguridad y normas de la empresa.
Pedir explicaciones, no solo código
Para no perder criterio técnico, el equipo debe pedir siempre una explicación breve.
Prompt recomendable
Ejemplo
Si la IA propone usar eventos, pregúntale:
Idea clave
La IA debe ayudarte a pensar mejor, no solo a producir más código.
Señales de una mala respuesta de IA
Hay respuestas que deberían hacer saltar las alarmas.
Desconfiar si la IA
- da una respuesta muy segura con poco contexto;
- genera mucho código sin explicar;
- inventa clases que no existen;
- añade dependencias sin pedirlo;
- mezcla arquitectura en capas con hexagonal sin criterio;
- mete lógica de negocio en controllers;
- usa
@SpringBootTestpara todo; - devuelve entidades JPA en la API;
- no contempla errores;
- no añade tests;
- ignora seguridad;
- usa APIs antiguas;
- no respeta el estilo del proyecto.
Checklist rápido
Antes de aceptar código generado, preguntar:
Idea clave
Una respuesta bonita no siempre es una respuesta buena.
Flujo recomendado de trabajo con IA
Un buen flujo para usar IA en backend puede ser este:
Ejemplo práctico
Tarea:
No pedir directamente:
Mejor ir por pasos:
Luego:
Luego:
Luego:
Luego:
Idea clave
La IA funciona mejor cuando se usa como compañero de trabajo paso a paso.
Conceptos mínimos que debe conocer el equipo
Prompt
Es la instrucción que le das a la IA.
Ejemplo:
Contexto
Es la información que le das para que pueda responder mejor.
Ejemplo:
Alucinación
Es cuando la IA inventa algo.
Ejemplo:
RAG
Es una técnica para que la IA responda usando documentación o código real como fuente.
Ejemplo:
Tool calling
Es cuando la IA puede usar herramientas externas.
Ejemplo:
Agente
Es una IA que no solo responde, sino que puede planificar pasos y usar herramientas.
Ejemplo:
Guardrails
Son límites de seguridad.
Ejemplo:
Evals
Son pruebas para comprobar si la IA responde bien.
Ejemplo:
Salidas estructuradas
Es pedir a la IA que responda en un formato controlado.
Ejemplo:
LLMOps
Es gestionar sistemas con IA en producción.
Incluye:
- logs;
- métricas;
- costes;
- prompts versionados;
- calidad de respuestas;
- errores;
- seguridad.
Idea clave
No hace falta que todo el equipo sea experto en IA, pero sí debe conocer los conceptos básicos para usarla con seguridad y criterio.
Reglas internas recomendadas
Estas reglas pueden servir como base para un equipo Java/Spring Boot:
Idea clave
Las reglas no son para frenar la IA. Son para usarla bien.
Resumen final
La IA es una herramienta muy potente para un equipo de desarrollo.
Puede ayudar a:
- escribir código más rápido;
- generar tests;
- explicar código legacy;
- revisar pull requests;
- crear documentación;
- detectar errores;
- proponer alternativas;
- aprender conceptos nuevos.
Pero también puede:
- inventar cosas;
- generar código inseguro;
- mezclar capas;
- crear soluciones demasiado complejas;
- sugerir dependencias falsas;
- omitir casos borde;
- dar respuestas seguras pero incorrectas.
Por eso, el equipo debe mantener criterio técnico.
La frase más importante de esta guía es:
Usamos IA para ir más rápido, no para pensar menos.
En un stack Java, Spring Boot y microservicios, el equipo debe seguir dominando:
- arquitectura;
- testing;
- seguridad;
- transacciones;
- APIs;
- microservicios;
- mantenibilidad;
- observabilidad;
- revisión de código;
- privacidad.
La IA puede ser un copiloto excelente, pero el equipo sigue siendo el piloto.