Existe una fe silenciosa en la industria del software de que más capas siempre es mejor. Hexagonal, Clean Architecture, DDD táctico, DDD estratégico, Saga, Event Sourcing, CQRS, el catálogo de la arquitectura ritualística se vende como prueba de seniority. Discrepar es confesar inmadurez. Pero tres números recientes, 76%, 58% y 7-13, empiezan a ponerle precio a esa fe. Y el precio no es abstracto. Se mide en acurácia perdida, contexto desperdiciado y tiempo humano quemado para hacer que un agente entienda lo que debería ser trivial.
Este post se sumerge en lo que significan esos números, por qué no son un accidente, y por qué el sesgo del LLM hacia abstracciones pesadas es estructural, heredado directo del corpus de entrenamiento. No es una receta anti-arquitectura. Es un llamado a dejar de confundir ceremonia con ingeniería, especialmente ahora que parte de tu equipo es un agente de IA que paga, literalmente, en tokens y accuracy points, cada capa que agregaste "por si acaso".
76%, La acurácia que se evapora cuando la dependencia se esconde en DI/DIP
El primer número viene de benchmarks de agentes de código intentando rastrear dependencias en proyectos que aplican Dependency Injection con el Dependency Inversion Principle en todas las fronteras. Cuando el agente necesita responder "¿qué llama PaymentService realmente en producción?", la respuesta correcta exige seguir una interfaz, un binding en un container, una factory, y finalmente una implementación que puede estar en otro módulo. El agente acierta esto el 76% de las veces. Comparado con el 95%+ en código directo, es una caída brutal, y es una caída silenciosa, porque el agente sigue produciendo código que parece correcto, pero que se ancla en la implementación equivocada.
El problema no es DI. Es DI ritualística: aplicada como default, sin que exista un segundo implementador real, sin que el test se beneficie, sin que la frontera justifique la indirección. La regla práctica es directa: si existe exactamente una implementación, y va a seguir siendo una sola, la interfaz es decoración. Para el humano que lee el código por primera vez, es una capa de traducción. Para el agente, es un hueco donde la verdad desaparece.
Qué hacer en la práctica
- Invierte la presunción: la clase va concreta hasta que aparezca un segundo caso de uso real. Refactorizar a una interfaz después cuesta minutos.
- Mantén el wiring visible: un container mágico que hace binding por convención es veneno para cualquier lector que no tenga el framework en la cabeza.
- Anota el "por qué" de la interfaz: si existe, deja escrito cuál es el segundo implementador (¿un test? ¿un adapter externo? ¿un feature flag?). Sin esa anotación, la interfaz es deuda disfrazada de principio.
58%, Cuando el agente prefiere glob+read a la herramienta de navegación
Segundo número: en el 58% de las tareas, los agentes modernos ignoran las herramientas de navegación de código provistas (LSP, símbolos indexados, MCP de codebase) y vuelven a la heurística primitiva de glob + read. La explicación no es pereza del modelo. Es que la arquitectura ritualística fragmenta el contexto al punto de que la indexación semántica entrega peor señal que el barrido por nombre. Cuando una feature está esparcida en domain/, application/, infrastructure/, interfaces/ y shared-kernel/, el resultado de un find symbol es una lista de wrappers alrededor de wrappers. glob "**/Payment*" + leer los 4 archivos que aparecen es, empíricamente, más rápido y más correcto.
Esto tiene una implicación dura para quien diseña una codebase: la mejor herramienta de navegación es una estructura de archivos que vuelve la navegación innecesaria. La co-localización le gana a la indexación. Un directorio por feature, con todo lo de la feature adentro, hace que cd feature/ && ls sea más informativo que cualquier árbol de símbolos. No es primitivismo, es el reconocimiento de que el sistema de archivos es una estructura de datos que los LLMs ya dominan profundamente, mientras que los plugins de navegación dependen de tooling externo que puede fallar, estar desactualizado, o simplemente no existir en el ambiente del agente.
7-13, El presupuesto de contexto que tu arquitectura está quemando
Tercer número: en codebases con separación rígida en domain/app/infra, el agente necesita abrir entre 7 y 13 archivos para entender una única feature de punta a punta. Compáralo con la alternativa pragmática, controller, service, repository en el mismo archivo, o a lo sumo tres archivos co-localizados en features/payments/. La diferencia es un orden de magnitud en el consumo de context window, y todo lo que entra en el contexto desplaza algo que podría estar ahí: la regla de negocio real, el test relevante, el historial del bug.
Cada archivo extra cobra tres peajes. (1) Tokens leídos: pagados en latencia y en costo. (2) Razonamiento para reconciliar la nomenclatura entre capas, porque PaymentDTO, PaymentEntity, PaymentModel y PaymentDomainObject típicamente representan la misma cosa con nombres diferentes, y el agente quema ciclos solo para descubrir que son, sí, la misma entidad. (3) El riesgo de que el agente importe la abstracción equivocada y produzca código que compila pero viola la regla que vive en otra capa. Los tres peajes se pagan en toda interacción. La multiplicación se acumula hasta volverse la mayor parte de la factura mensual de tokens de tu empresa.
Abstraction Bloat: por qué el LLM tiene un sesgo estructural a favor de la arquitectura pesada
Aquí está el punto que pocos ven. El LLM no elige arquitectura hexagonal porque concluyó que es la mejor. La elige porque fue entrenado en un corpus donde la abrumadora mayoría del material técnico publicado habla sobre Event Sourcing, CQRS, Saga, DDD y Hexagonal. Nadie publica un Medium llamado "Cómo mantengo desde hace 5 años un CRUD de 3 archivos que sirve 8 mil requests por minuto sin dolor". Ese post no existe porque no da engagement, pero el sistema correspondiente existe en producción en miles de empresas que pagan sus cuentas todos los meses.
El resultado es un sesgo estadístico que se vuelve sesgo normativo: el modelo sugiere la estructura ceremoniosa porque es la estructura visible en el corpus. Los ingenieros menos experimentados confunden esa sugerencia con best practice y la aceptan sin cuestionar. Los ingenieros experimentados pisan el freno, pero la fricción es constante, recurrente, y cobra energía en cada sesión. El costo de ese sesgo es acumulativo: cada decisión tomada a la sombra del default ceremonioso agrega una capa más que va a cobrar peaje para siempre.
El reencuadre necesario
- Ceremonia ≠ ingeniería. La ingeniería es resolver el problema dentro del presupuesto (de tiempo, contexto, atención, dinero). La ceremonia es ejecutar el ritual independiente del presupuesto.
- La arquitectura es local, no universal. Hexagonal puede ser lo correcto para el núcleo crítico del producto y un absurdo para el servicio de notificación de email, y los dos pueden coexistir en el mismo repositorio sin hipocresía.
- El agente es parte del equipo ahora. Las decisiones de arquitectura tienen que considerar el costo cognitivo para los humanos y el costo de contexto/acurácia para los agentes. Ambos pagan.
- La co-localización derrota a la indexación. Un directorio por feature, con todo adentro, le gana a cualquier mapa mental de capas esparcidas. Borrar la feature debería ser borrar un directorio, no una caza del tesoro en cinco carpetas.
El test de seniority invertido
Durante años la industria midió la seniority por la capacidad de agregar abstracción. Quien proponía Hexagonal era senior. Quien proponía "service + db" era junior. El nuevo test es el opuesto. Senior es quien logra mirar una feature de bajo riesgo que cambia despacio y responder, sin culpa, "tres archivos lo resuelven". Senior es quien percibe que la capa que está a punto de agregar va a cobrar peaje por diez años para resolver un problema que puede nunca ocurrir. Senior es quien acepta que el sistema más maduro es típicamente el más aburrido.
Los números de la diapositiva, 76%, 58%, 7-13, no están diciendo que la arquitectura sea mala. Están diciendo que la arquitectura ritualística cobra un precio que ahora se puede medir. Ignorar el precio ya era caro. Seguir ignorándolo, en un equipo donde la mitad de las interacciones con el código pasan por un agente, es una decisión consciente de pagar un impuesto recurrente para parecer senior en vez de ser senior.