Línea de apertura (opcional, para el feed): Llevas seis meses usando Claude para tus decisiones de arquitectura Java. Eres más rápido. Pero ya no sabes si elegirías Spring Security + JWT o Keycloak sin preguntarle primero. Eso no es productividad. Es atrofia.
Parte de la serie "Los 6 pilares del desarrollo asistido por IA" — basado en el material de Thor Henning Hetland (Totto) / Ægis. Adaptado a proyectos Java.
Hay dos formas de trabajar con IA. La mayoría de los desarrolladores elige la segunda sin darse cuenta.
El intermediario le pregunta a Claude qué hacer y ejecuta lo que dice. Más rápido al principio. Pero seis meses después no puede tomar una decisión de arquitectura sin consultarle primero. Su experiencia se erosiona.
El director le asigna trabajo específico a la IA, triangula perspectivas, sintetiza con su propio criterio y se hace dueño de la decisión. Más lento al principio. Pero seis meses después es más rápido y más experto que antes.
El Pilar 4 es la arquitectura cognitiva para mantenerte como director, no convertirte en intermediario.
La cronología de seis meses que nadie ve venir
El patrón es siempre el mismo:
Mes 1: "Claude es increíble. Soy mucho más rápido."
Mes 3: "Me siento un poco menos seguro en mis decisiones técnicas..."
Mes 6: "No puedo tomar una decisión de arquitectura sin preguntarle a Claude primero."
La velocidad sube. La confianza técnica cae. Y como la velocidad es visible y la confianza no, nadie lo nota hasta que es tarde.
En términos Java: el desarrollador que solía poder debatir los trade-offs de Spring Security vs. Keycloak, de CQRS vs. arquitectura tradicional, de JPA vs. jOOQ... ahora simplemente pregunta y ejecuta.
La diferencia no está en si usas IA. Está en cómo la usas.
Un ejemplo concreto en Java. Tu equipo necesita decidir si implementa CQRS en el dominio de pedidos de un e-commerce.
El intermediario pregunta:
"¿Debo usar CQRS en mi aplicación Spring Boot?"
Claude dice que sí, con una lista de beneficios. El desarrollador implementa CQRS.
El director pregunta:
"Estoy evaluando CQRS para el dominio de pedidos de un e-commerce con Spring Boot 3. El volumen es de 10.000 pedidos/día, el equipo tiene 4 devs, y actualmente tenemos una sola base de datos PostgreSQL. Analiza los trade-offs: complejidad operacional, consistencia eventual, y si el volumen justifica la separación de modelos de lectura y escritura."
Claude da una respuesta matizada. El director la contrasta con otra perspectiva, sintetiza y toma la decisión con criterio propio.
Lectura pasiva vs. síntesis activa
La misma distinción aplica a cómo procesas el output de la IA:
| Lectura pasiva |
Síntesis activa |
| Los músculos mentales quedan sin uso |
Escribir organiza el pensamiento |
| El reconocimiento de patrones se degrada |
Comparar perspectivas exige pensamiento crítico |
| La toma de decisiones se subcontrata |
Sintetizar en tus propias palabras consolida comprensión |
| El aprendizaje se detiene |
La experiencia se acumula |
Cuando Claude te da una configuración de Spring Security para OAuth2, hay dos caminos:
Pasivo: copias el código, lo pegas, funciona, sigues.
Activo: lees el código, anotas qué hace cada bean, identificas las decisiones que tomó la IA (¿por qué usó SessionCreationPolicy.STATELESS?, ¿por qué ese orden en los filtros?), y luego lo integras porque entiendes lo que hace.
El segundo camino tarda 15 minutos más. En seis meses, esa diferencia es la que separa al arquitecto del que solo sabe usar Claude.
El modelo de triangulación: por qué una sola IA no basta
La certeza técnica requiere triangulación. No porque una IA sea mala, sino porque así es como los humanos procesan la certeza de forma natural.
Ejemplo Java — elegir entre JPA y jOOQ:
Tienes un dominio de reportes con consultas SQL complejas (múltiples JOINs, agregaciones, paginación custom). ¿Spring Data JPA o jOOQ?
Prompt para Claude (consciente del contexto):
"El equipo tiene dominio de JPA/Hibernate 6. Tenemos un módulo de reportes con 20+ consultas de más de 5 JOINs cada una. Evalúa con detalle los trade-offs de mantener Spring Data JPA con @Query nativas vs. migrar ese módulo a jOOQ, considerando: curva de aprendizaje, tipado en tiempo de compilación, mantenibilidad de las queries, y coste de migración."
Prompt para ChatGPT (crítica desde primeros principios):
"Asume que estoy inclinado hacia Spring Data JPA por inercia del equipo. Dame el mejor argumento posible para que un equipo Spring Boot cambie a jOOQ en un módulo de reportes con consultas complejas. Sé directo sobre los puntos donde JPA realmente falla."
Después identificas dónde coinciden (seguramente: jOOQ tiene mejor control sobre SQL complejo), dónde difieren (quizás en la estimación del coste de migración), y escribes tu síntesis. Esa síntesis es la decisión que puedes defender ante el equipo.
El bucle de 15 minutos
Para decisiones técnicas importantes, este es el protocolo:
15 minutos invertidos en una decisión de arquitectura previenen horas — a veces días — de incertidumbre y rework.
Escenario real (ficticio pero típico): Tu equipo discute si implementar Outbox Pattern para garantizar consistencia entre la base de datos PostgreSQL y Kafka en el módulo de pedidos.
Sin el bucle: alguien pregunta a Claude, Claude dice que sí, se implementa, tres semanas después aparecen edge cases que Claude no mencionó porque nadie preguntó de forma específica.
Con el bucle: formulas la pregunta con contexto real (volumen, equipo, stack), obtienes dos perspectivas, identificas el punto de fricción (complejidad operacional del Debezium vs. solución custom), escribes la síntesis, documentas la decisión en un ADR. Tres semanas después, cuando aparecen los edge cases, el ADR ya los anticipaba.
Las reglas del director para Java devs
La distinción clave en el día a día Java:
Uso correcto del director (decisión de autenticación):
"Estoy diseñando la capa de autenticación para una API Spring Boot 3 con 50.000 usuarios activos. Compara JWT stateless con sesiones gestionadas por Spring Session + Redis: latencia, revocación de tokens, complejidad de implementación y escalabilidad horizontal. El equipo ya conoce Spring Security."
Uso del intermediario (evitar):
"¿Cómo implemento autenticación con Spring Boot?"
El primero produce una respuesta accionable que puedes evaluar. El segundo produce una respuesta genérica que ejecutas sin criterio.
Integrar el rol de director en tu flujo Java
En decisiones de arquitectura (antes de empezar):
Siempre formula la pregunta con contexto: equipo, volumen, stack, restricciones
Siempre contrasta con al menos una perspectiva adicional
Documenta la síntesis como ADR en /docs/decisions/
En code review de código generado por IA:
Lee el diff entero, no confíes en el resumen de la IA
Pregúntate: "¿Podría explicarle a un colega por qué este código hace lo que hace?"
Si no puedes, no mergeas hasta entenderlo
En el CLAUDE.md del proyecto (Pilar 1):
## Decisiones de arquitectura
Toda decisión técnica mayor debe:
1. Formularse con restricciones específicas (equipo, volumen, stack)
2. Contrastarse con al menos una perspectiva adicional
3. Documentarse en docs/decisions/ con el razonamiento propio
La IA propone. El equipo decide.
En el daily o la retrospectiva: Pregunta periódicamente: "¿Hay alguna decisión técnica de las últimas dos semanas que tomamos porque Claude lo dijo, sin haberla triangulado?"
La elección que se hace en cada prompt
Cada vez que abres una conversación con Claude hay una elección implícita:
La IA no te quita la agencia. Tú se la cedes, prompt a prompt, cada vez que aceptas la primera respuesta sin leerla, cada vez que copias sin entender, cada vez que dejas que el modelo elija por ti lo que es tuyo elegir.
El Pilar 4 no es una restricción al uso de IA. Es la forma de asegurarte de que el uso de IA te hace más experto, no más dependiente.
La conexión con los otros pilares
El Pilar 1 (CLAUDE.md + skills) documenta las decisiones pasadas del equipo para que la IA no las ignore. El director actualiza ese contexto después de cada síntesis: las decisiones que tomó y el razonamiento detrás de ellas.
El Pilar 2 (delegación estratégica) asigna el modelo correcto para cada tarea. El director sabe que Opus 5 o Fable 5 son apropiados para triangular decisiones de arquitectura, y Haiku para ejecutar patrones ya decididos.
El Pilar 3 (verificación) asegura que el código generado es correcto. El director no solo verifica el código: verifica que entiende el código que verifica.
Los seis pilares juntos son una arquitectura de trabajo, no un conjunto de herramientas. El director las orquesta.
¿Cuándo fue la última vez que tomaste una decisión de arquitectura Java triangulando dos perspectivas de IA y escribiendo tu propia síntesis? ¿O directamente ejecutaste lo que dijo Claude? Sin juicio — es una pregunta honesta para el equipo.
Enjoy!
Joe
