El día que el arquitecto devolvió un 503

Os voy a contar una situación que, si no habéis vivido ya en alguna guardia o comité de crisis, es muy probable que tengáis a la vuelta de la esquina.

A las 10:14 de la mañana, los despliegues de una pasarela de pagos interbancarios fallaron, pero no por una errata de sintaxis en un prompt, o una mala configuración en el balanceador o una alerta de SonarQube. Sencillamente, los pipelines de CI/CD se congelaron en seco. En mitad de una ventana de actualización crítica previa al cierre contable, tres servicios de conciliación en tiempo real y una migración masiva de esquemas transaccionales quedaron suspendidos en el limbo.

¿El problema?, un simple fallo en el proceso de renovación del servicio API LLM. En las pantallas de la sala técnica, las consolas dejaron de escupir métricas de rendimiento y mostraron una sola alerta crítica:

En resumen

No hay misterio aquí: la tecnología avanza y nos brinda herramientas extraordinarias para ser más productivos, pero la soberanía técnica de una organización no se puede subcontratar.

Acelerad vuestros desarrollos todo lo que podáis, sí, pero mantened el volante bien sujeto. El día que la nube falle o la API de turno devuelva un 503, vuestra empresa debe ser capaz de desconectar el piloto automático, tomar los mandos manuales y seguir operando con solvencia.

Espero que esta reflexión os sea útil en vuestro próximo comité de arquitectura o de estrategia técnica. ¿Habéis vivido ya situaciones similares en vuestros equipos?, ya sabéis donde comentar.

Los tres pecados capitales del diseño arquitectónico

Seamos sinceros: el problema aquí no fue una caída fortuita de red. En cualquier sistema distribuido asumimos que las cosas fallan. El colapso vino provocado por tres fallos estructurales de diseño que veo repetirse con demasiada frecuencia:

- El punto único de fallo cognitivo (Cognitive SPOF): Acoplar pipelines críticos a una única API externa, sin capas de abstracción, sin patrones de circuit breaker ni planes de contingencia hacia modelos locales (*on-premise*), expone la continuidad del negocio a un proveedor ajeno. Si tu tubería de entrega no compila ni despliega sin conexión a Silicon Valley, tienes un SPOF de manual.

- La ilusión de la caja negra y la pérdida del plano de control: Tratar la inferencia probabilística de un LLM como si fuera un compilador determinista elimina la trazabilidad y la reproducibilidad técnica. En sectores regulados como la banca o la salud, donde cada línea de código debe responder ante una auditoría forense, operar a ciegas no es agilidad: es negligencia en la gobernanza.

- Desacoplamiento tóxico y atrofia técnica: Reducir la ingeniería a meros operadores de prompts convierte el código base en una caja sellada. Cuando el sistema explota en producción, ningún humano en plantilla conserva la capacidad de auditar, depurar a bajo nivel o meter un parche en caliente.

La trampa del desaprendizaje organizacional

A día de hoy se habla mucho del ahorro de costes, pero la verdadera factura oculta es el desaprendizaje de los equipos.

Cuando delegas la resolución de problemas en un agente, el músculo técnico se atrofia a una velocidad pasmosa:

- Pérdida de destrezas críticas: Desaparece la soltura para diagnosticar deadlocks en motores relacionales, cazar fugas de memoria bajo estrés, optimizar planes de ejecución de SQL o lidiar con la serialización en gRPC. Si el modelo genera código con fallos sutiles de rendimiento, el operador no sabe ni por dónde empezar a mirar trazas de red o bytecode.

- Evaporación del conocimiento tácito: En proyectos con sistemas heredados (*legacy*), la mitad de la arquitectura real no está escrita en diagramas: reside en la experiencia acumulada de resolver incendios en guardias nocturnas. Al cortar el contacto directo con el código, ese capital se evapora.

- Riesgo regulatorio y legal (DORA y normativas bancarias): Con marcos como la directiva DORA o las exigencias del BCE, la explicabilidad es innegociable. No puedes justificar ante un regulador un error contable o un fallo en el enrutamiento de pagos diciendo que "el agente generó esa respuesta".

- Coste asimétrico de recuperación: Desprenderse del talento sénior lleva semanas; reconstruir un equipo con criterio arquitectónico y conocimiento funcional de negocio cuesta años. Es una trampa de dependencia unidireccional.

Durante dos años, esa factoría había sido el orgullo de la dirección. Habían automatizado el ciclo de vida completo: desde traducir pliegos normativos a especificaciones, hasta generar microservicios en Spring Boot, refactorizar lógica contable legacy y parir miles de casos de prueba para transacciones ISO 20022. La velocidad de entrega se multiplicó por cinco. Los costes cayeron en picado.

Y aquí vino el gran error: decidieron prescindir progresivamente de los arquitectos sénior y de los analistas que llevaban veinte años pegándose con la letra pequeña del core banking. La pregunta en los despachos era la de siempre: ¿para qué mantener perfiles caros y obstinados con la gobernanza, si una malla de agentes resuelve incidencias y firma despliegues en segundos?

La respuesta llegó con esa llamada fallida a la API.

Media docena de desarrolladores júnior miraban las consolas sin saber por dónde empezar. Sabían lanzar jobs en Jenkins y abrir incidencias en Jira. Pero ninguno comprendía la máquina de estados tras los bloqueos pesimistas en la base de datos; nadie sabía reconciliar a mano un desfase en el libro mayor sin las trazas que interpretaba el agente; y nadie tenía el criterio para auditar un parche de urgencia cumpliendo la normativa financiera.

El conocimiento profundo del sistema ya no estaba en el equipo ni en documentación viva: estaba diluido en miles de prompts y llamadas a un tercero que ahora devolvía silencio. Descubrieron, por las malas, la enorme diferencia entre acelerar el desarrollo y perder la soberanía de tu propia ingeniería.

Simbiosis entre criterio sénior y aceleración cognitiva

¿Significa esto que debamos renegar de la inteligencia artificial? En absoluto. Quien me conoce sabe que no soy amigo de poner puertas al campo. La solución no es rechazar la herramienta, sino desterrar la fantasía de la sustitución y abrazar un sistema de colaboración simbiótica, donde un ser humano y un sistema de inteligencia artificial trabajan en equipo.

En este enfoque, la IA no sustituye el intelecto humano: actúa como un exoesqueleto cognitivo. En sistemas donde el margen de error es cero, el profesional cualificado debe permanecer obligatoriamente en el bucle (*Human-in-the-loop*).

Como veis, el valor diferencial no está en escribir código trivial, sino en el criterio para validarlo:

- Acelerar lo mecánico para blindar lo nuclear: Usemos los agentes para generar DTOs, mappers, esquemas de migraciones repetitivas o esqueletos de pruebas. Pero el tiempo ganado debe invertirse en lo que de verdad importa: invariantes transaccionales, coherencia del modelo de dominio, tolerancia a particiones de red y consistencia eventual.

- Probabilidad frente a causalidad: Un LLM genera respuestas basadas en distribuciones de probabilidad aprendidas del pasado; no entiende de causa y efecto ni del contexto vivo de tu negocio. Ante situaciones límite o compensaciones (*trade-offs*) críticas entre latencia y consistencia, solo la experiencia humana puede tomar la decisión correcta.

- Garantizar el relevo generacional: Si los desarrolladores noveles solo consumen código sintético, nunca aprenderán los fundamentos. Necesitamos a los séniors tutorizando, haciendo revisiones de código exhaustivas y enseñando el "porqué" de las cosas para formar a los líderes técnicos de la próxima década.

Historias de un Tech Lead

Reflexiones sobre arquitectura, desarrollo de software y otras cosas.

© 2026. All rights reserved.

NOTA:

Si, ya lo se, casi todas las imágenes contenidas en este blog, han sido y posiblemente serán generadas por IA, por desgracia no dispongo de capacidades artísticas adecuadas y mucho menos de tiempo para buscar imágenes adecuadas en la red. Por lo que muy pocas serán creadas por mi directamente.