El fin del "one size fits all"

Durante décadas trabajamos bajo un modelo implícito que podríamos llamar el modelo SAP: existe una forma “correcta” de hacer las cosas, alguien la ha codificado en una herramienta, y tu trabajo consiste en adaptar tus procesos a ese molde. El software dictaba el flujo y tú te ajustabas. Pagábamos consultoría por kilo para que nuestra realidad encaje en el diagrama de otro.

Ese contrato se está rompiendo. Hoy, con AI, puedo generar en horas una herramienta que se adapta a mi forma de pensar en lugar de obligarme a pensar en la suya. Y lo interesante no es la velocidad: es el cambio de sentido. La herramienta ya no es el punto de llegada al que uno se amolda, sino materia moldeable que orbita alrededor de cómo uno ya trabaja.

Un colega descubrió hace poco una utilidad open-source que le gustó. En lugar de adoptarla, la rehízo en minutos para que encajara en su flujo personal. No era la misma herramienta con otro color: era algo nuevo que solo tenía sentido para él. En paralelo, yo necesitaba una capa de memoria externa para trabajar con agentes, y en vez de buscar “la mejor solución del mercado” construí una sobre Obsidian. Con cada iteración es “mejor”… y mejor aquí significa, sin ambigüedad, más alineada con mi workflow particular. Menos universal, más mía.

Hasta aquí la buena noticia. Ahora la trampa. Mi colega, entusiasmado con lo que construyó, empezó a compartirlo como “la versión que va a ayudar a todos”. Otro amigo está convencido de que puede vender la app que vibecodeó para resolver un problema muy específico suyo. Y yo mismo, que escribí esta crítica, cada vez que subo una versión de mi sistema de memoria a GitHub la acompaño de un README que la presenta menos como “esto es lo que funciona para mí” y más como “esto podría funcionar para ti”. Cada commit la vuelve, paradójicamente, menos genérica y más evangelizadora.

Es el viejo reflejo. Construimos algo que resuelve nuestro caso de uso y, en el mismo gesto, intentamos universalizarlo. Volvemos a SAP por la puerta de atrás, solo que ahora el que quiere imponer el molde soy yo. Y lo hacemos incluso quienes estamos convencidos de estar habitando un paradigma distinto.

La pregunta incómoda es por qué. Creo que hay tres reflejos operando a la vez. Uno económico: si tu herramienta sirve solo para ti, no hay negocio; si sirve para todos, hay startup. Dos, un reflejo de validación: que otros adopten lo tuyo confirma que el problema era real y que la solución es buena. Tres, un reflejo cognitivo más viejo: pensamos en herramientas como productos (objetos estables, distribuibles, con usuarios) en vez de como prácticas (gestos situados, biográficos, intransferibles).

El cambio de paradigma real no es “ahora puedo construir mi herramienta”. Eso es solo la condición de posibilidad. El cambio es aceptar que la herramienta perfecta para otro no se compra ni se descarga: se reescribe. Lo que mi colega debería compartir no es su app; es el patrón, el razonamiento, la forma de pensar el problema. Lo que yo debería publicar no es el código listo para clonar, sino la lógica subyacente para que alguien más construya la suya.

El artefacto no viaja bien. La idea, sí.

En este nuevo paradigma las herramientas se vuelven biográficas: cargan el modo en que su autor piensa, las fricciones concretas que resuelve, las decisiones idiosincráticas que tomó un martes. Eso es exactamente lo que las hace valiosas para quien las construyó y lo que las hace inservibles, tal cual, para cualquier otro.

Compartir código sigue teniendo sentido como referencia, como inspiración, como atajo de aprendizaje… pero presentarlo como producto para adoptar es traicionar la naturaleza de lo que hicimos.

Todavía estoy aprendiendo a resistir el reflejo. La próxima vez que suba una versión de mi sistema de memoria, me gustaría que el README empiece diciendo: “esto no es para ti pero puede enseñarte cómo construir lo tuyo”. Veremos si lo consigo.