Caso contra la abstracción
Caso en contra de la abstracción
Recientemente estuve inmerso en un proyecto extremadamente complejo donde el problema no era solo el tamaño del códigobase sino un bosque interminable de indireccionamiento. Funciones factoría, providers, managers, registros y mixins; por donde miraba aparecía otra capa más. Seguir el flujo de datos se sentía menos como trazar lógica y más como explorar una cueva sin mapa.
En un momento apoyé la depuración en un modelo de lenguaje y falló. No porque la IA fuera débil sino porque la arquitectura estaba tan fragmentada e implícita que ni siquiera un agente podía recomponerla. La abstracción que usamos para domar la complejidad se había convertido en la fuente de la misma.
Históricamente la abstracción fue nuestra defensa contra la sobrecarga cognitiva. Ocultábamos detalles irrelevantes tras capas limpias para que la memoria de trabajo humana no colapsara. Encapsulación, gestión de estado, factories y patrones similares eran mecanismos de supervivencia. Pero en la era de la inteligencia artificial los intercambios han cambiado.
Los humanos llegamos rápido a límites cognitivos mientras que un LLM puede procesar mucho detalle sin fatiga. Lo que no puede manejar bien es la fragmentación: comportamientos implícitos repartidos en docenas de ficheros y contexto roto en múltiples capas de indireccionamiento. El resultado es que la abstracción deja de reducir carga cognitiva y la multiplica, transformando el trabajo de resolver problemas en arqueología del código.
Un caso real que viví en un proyecto basado en TypeScript y React muestra el efecto acumulado: más de 40 000 archivos en total, miles de líneas en los ficheros núcleo, cientos de ficheros con patrones de abstracción, más de 20 reductores con dependencias complejas, docenas de mixins en la capa de componentes, un objeto de estado con 80 propiedades distribuidas entre UI, lógica de negocio, red y persistencia, y miles de tests unitarios y E2E que solo aumentaban la fragilidad.
Una acción de usuario podía rebotar a través de una cadena de 6 a 8 archivos solo para localizar la causa raíz. No era arquitectura, era burocracia. Cada capa existía para desacoplar pero combinadas generaban indireccionamiento en forma de muñecas rusas donde nada era visible sin pelar cuatro envoltorios.
Los equipos incluso construyeron frameworks internos encima de frameworks para salvar limitaciones de librerías como Immutable.js. El coste fue que cada desarrollador tuvo que comprender internals de dependencias, capas de herencia personalizadas y la lógica de dominio encima de todo. Esa profundidad implícita impidió que tanto humanos como modelos de lenguaje razonen sin exploración constante.
El estado monolítico fue otro problema. Un estado central con más de 80 propiedades que mezclaba UI, campos de formulario, adjuntos, errores de validación, servicios de API y estado de conexión convertía cualquier cambio en una inmersión de 500 líneas y docenas de imports. Nuevos desarrolladores quedaban paralizados y la asistencia de IA empeoraba al dar respuestas superficiales o inventadas porque no podía mantener coherencia del contexto entero.
Las plantillas complejas proliferaban copiando el patrón más complicado para cada entidad, generando duplicación 4x con interfaces inconsistentes. Incluso si un modelo analizaba con éxito una cadena, ese conocimiento rara vez transfería a otras cadenas parecidas.
Cuando los modelos de lenguaje se encuentran con estos proyectos ocurre lo siguiente. Fragmentación de contexto: una sola funcionalidad puede abarcar 20 o más archivos y miles de líneas, más de lo que incluso ventanas de contexto grandes manejan bien. Flujos implícitos: cambios de estado que se propagan por cadenas ocultas entre reducers, managers y providers. Lógica dispersa: validación en modelos, manejo de errores en reductores y sincronización en providers sin un lugar único que contenga la verdad.
El impacto observado fue real y cuantificable. Diagnosticar fallos llevó entre 8 y 10 veces más tiempo. Las explicaciones generadas por LLM fueron entre 70 y 85 por ciento menos precisas. Sugerencias de refactorización quedaron bloqueadas por dependencias enmarañadas. El tiempo medio para incorporar un desarrollador nuevo pasó de semanas a meses.
La suite de pruebas no salvó la situación. Miles de tests existían pero añadían fragilidad y mantenimiento. Las pruebas requerían mocks masivos, sincronización implícita entre múltiples capas, temporizadores arbitrarios y una cultura de reintentos que enmascaraba problemas sistémicos. Añadir una propiedad o una pequeña nueva característica implicaba actualizar decenas de ficheros de test y fixtures.
En números aproximados, un 80 por ciento del tiempo de ejecución de tests se gastaba en setup, teardown, mocks y reintentos y no en lógica efectiva. Depurar un test intermitente podía llevar más de 3 horas y mantener las pruebas absorbía una parte enorme del tiempo de desarrollo.
Todo esto no significa que la abstracción sea mala por definición. Hay usos claros donde mejora la claridad como separar límites de dominio, gestionar preocupaciones transversales como logs y autenticación, encapsular algoritmos complejos y envolver APIs externas. La diferencia clave es que una buena abstracción reduce la carga cognitiva ocultando detalles irrelevantes mientras que la mala abstracción la aumenta ocultando detalles relevantes.
En la práctica tanto humanos como máquinas necesitan directitud. Los humanos razonan mejor con claridad y la IA funciona mejor con explicitud. En la era de la IA la abstracción nos pasa factura en tres frentes: carga cognitiva humana, contexto roto para máquinas y fragilidad en las pruebas. La arquitectura más útil para ambos es directa, explícita y orientada por dominios.
Aquí van soluciones prácticas que implementamos y recomendamos. Audita las abstracciones como si fueran dependencias: si una capa no justifica su coste, elimínala. Colapsa capas innecesarias y prefiere servicios sencillos frente a factories que solo añaden indireccionamiento. Diseña pensando en colaborar con agentes IA: aplana estructuras, corta el estado en rebanadas de dominio y usa nombres explícitos que permitan a un modelo y a un humano entender una parte sin consumir todo el contexto.
Aplica la regla de los cinco minutos: si no puedes explicar en cinco minutos qué hace una abstracción a un nuevo desarrollador o a un asistente IA, simplíficala o elimínala. Prioriza slices de estado con nombres claros como documento, datos, ui y sincronización en lugar de blobs con ochenta propiedades.
En Q2BSTUDIO nos especializamos en ayudar a empresas a modernizar arquitecturas y a diseñar software que funcione bien tanto para equipos humanos como para herramientas de inteligencia artificial. Somos una empresa de desarrollo de software aplicaciones a medida y software a medida con experiencia en inteligencia artificial, ia para empresas, agentes IA, ciberseguridad, servicios cloud aws y azure, servicios inteligencia de negocio y power bi para informes y visualización. Ofrecemos auditorías de arquitectura, refactorizaciones orientadas al dominio, implementación de servicios en la nube y soluciones de ciberseguridad para proteger pipelines y datos.
Nuestro enfoque es pragmático: reducir indireccionamiento innecesario, crear servicios claros, definir fronteras de dominio y escribir tests que aporten confianza en lugar de fragilidad. Trabajamos con equipos para introducir prácticas que aceleran onboarding, mejoran la colaboración con agentes IA y reducen la deuda técnica.
Si tu proyecto sufre por exceso de abstracción y quieres transformar el código en una base sostenible y fácil de entender para desarrolladores y modelos de inteligencia artificial, Q2BSTUDIO puede ayudarte a auditar, simplificar y modernizar. Contáctanos para una evaluación y recupera velocidad en desarrollo de aplicaciones a medida, potencia en inteligencia artificial, seguridad en ciberseguridad, migración a servicios cloud aws y azure y valor en servicios inteligencia de negocio con power bi y soluciones IA para empresas.
La abstracción no ha muerto pero los valores por defecto han cambiado. Cada capa debe ganarse su lugar preguntando si realmente reduce la carga cognitiva y si se puede explicar en menos de cinco minutos. La mejor arquitectura no es la más abstracta sino la más directa y útil para humanos y máquinas por igual.