Si has iniciado sesión en aplicaciones con tu cuenta de Google o Microsoft, lo sepas o no, has usado OAuth2. Déjame contarte una historia:
Hace un tiempo, estábamos integrando una solución de autenticación en un proyecto. Uno de los desarrolladores del equipo propuso algo que en el papel sonaba razonable: en lugar de que el login esté en un proveedor externo, implementemos nosotros mismos la pantalla de inicio de sesión, la idea era controlar las validaciones de la contraseña (que sea compleja, que no use solo números, etc.).
Técnicamente, tenía sentido. El problema es que eso iba en contra de la razón de ser de OAuth2. El protocolo existe para que nadie, ni siquiera tú, tenga acceso a los passwords de nadie. La app solo recibe permiso. En lugar de continuar, paré la jornada y programé una sesión para explicar el protocolo, que resolvía y por qué lo estábamos usando. Había que volver a la pregunta más importante de todas: ¿Qué problema estamos intentando resolver?
Esto no es nuevo y no es exclusivo del software:
Durante y después de la Segunda Guerra Mundial, en varias islas del Pacífico, poblaciones nativas, muchas golpeadas por la guerra y en extrema necesidad, veían llegar aviones con suministros. Los aviones aterrizaban en pistas con torres de control y señales improvisadas. Cuando la guerra terminó, los aviones dejaron de venir. Pero algunos grupos intentaron forzar que los aviones y los suministros volvieran: Construyeron sus propias pistas, sus propias torres, incluso aviones de madera. Repitieron lo que habían visto (pero que no entendían), con la esperanza de que volvieran si repetían los rituales que habían visto.
Ese fenómeno se conoce como Cargo Cult. Y sigue pasando. ¿Alguna vez has visto que se hace algo porque un framework lo dice, porque a alguien más le funcionó, sin que nadie entienda o sepa explicar por qué? Sí, tú has estado ahí, yo he estado ahí.
Una aclaración importante: mi primer ejemplo no es cargo cult en el sentido estricto, pero comparte la misma base: hacer algo sin entenderlo del todo, se conocía lo suficiente, pero no se había interiorizado el por qué de usar el protocolo en primer lugar. Esa distancia, entre usar algo y entenderlo de verdad, es donde vive el cargo cult, solo que en su versión organizacional es más silenciosa. No construyes aviones de madera, construyes procesos, comités, capas de gobierno, todo con intención real, pero sin haber interiorizado del todo qué problema resuelven, y solo porque una receta te lo dice.
Ahí es donde el patrón se vuelve peligroso. Porque el cargo cult puro se nota, un avión de madera no vuela. Pero un framework mal interiorizado sí “funciona”. Se ve estructura, se ve control, se facturan cursos, se ven tareas, proceso y resultados, muchas veces como vanity metrics. Lo único que no logra es resolver el problema real.
Cuando esto llega a un extremo donde el cuestionamiento no solo se desincentiva sino se penaliza, censura, o nos llenamos de golpe de frameworks; es algo a lo que he llamado Frameworktitis.
En medicina “itis” se usa para inflamación, una reacción cuando tu cuerpo se defiende de algo, apendicitis, gastritis, alergias (no termina en itis pero entra aquí). El sistema está fallando por exceso. Tratando de protegerte y, en el proceso, es incómodo, duele y sobre todo te hace daño a ti mismo.
Frameworktitis es lo mismo, aplicado a organizaciones. No es adoptar un framework. Es la respuesta inflamatoria a haber vivido caos, o al miedo de volver a vivirlo. El framework no se adopta como herramienta, se adopta sin entenderlo, solo como una forma de huir del pasado, pero en el camino se pierde justo lo que la hacía funcionar: velocidad, flexibilidad, criterio propio.
Y el síntoma más claro es cuando el criterio de éxito cambia. Dejas de preguntarte “¿esto resuelve el problema?” y empiezas a preguntarte “¿esto cumple con el proceso?”, “¿llegamos a la meta?”. El framework, que debería ser un lente para ver mejor la realidad, se convierte en el objetivo.
Ese es el punto más peligroso: cuando delegas el juicio a algo sin entenderlo, llámalo un framework, un estándar de industria, o un modelo de IA, entras en un engaño mental: piensas que eliminas la responsabilidad de la decisión, pero solo estás dejando de ejercerla. Y la responsabilidad, ejercida o no, sigue siendo tuya.
Hemos hablado de frameworks, pero no se limita a eso, se trata de cualquier instrumento que usemos para dejar de pensar críticamente sobre la realidad, y eso incluye a la IA, solo que con una velocidad de adopción que ningún framework anterior tuvo. Cada vez escucho y leo más: “el modelo lo sugirió, programó, generó” de la misma forma que “el framework lo dice” reemplazó a “esto resuelve el problema”. No es que la IA sea mala, tampoco los frameworks. Es que, otra vez, se puede usar como lente o como una excusa para no pensar.
La diferencia es que esta vez la inflamación puede llegar más rápido y a más escala. Un framework organizacional tarda meses en imponerse. Un modelo de IA está disponible para cualquiera, en cualquier momento.
Lamentablemente no tengo una fórmula para saber cuándo un framework es un lente y cuándo es frameworktitis. Y si la tuviera, sería exactamente el problema del que hablamos: algo que aplicamos a ciegas sin cuestionar y sin pensar.
Lo que sí tengo es una pregunta que me hago cada vez que estoy por adoptar algo, un framework, un estándar, un modelo o herramienta de IA, antes de usarlo: ¿entiendo qué problema resuelve, o solo entiendo cómo se usa?
Si solo entiendo cómo se usa, probablemente tengo un avión de madera, y solo estoy esperando que traiga provisiones.
Disclaimer: luego de terminar este artículo, busqué el término y encontré que “frameworkitis” y “frameworktitis” ya aparecen en dos fuentes previas, una de 2008 y otra de 2013, aunque su uso no está relacionado con el sentido que le doy aquí.