Diseñar el Criterio Heredado

Esta semana estuve escribiendo con una IA y en algún momento me devolvió un párrafo que decía casi exactamente lo que yo quería decir. Lo leí y supe al instante que no era mío. Lo que pude articular fue algo bastante inútil: está buena la idea, pero yo no lo diría así. No tenía una regla para ofrecer, no podía nombrar qué principio se había violado. Solo sabía, con una certeza que no admitía discusión, que esa no era mi voz. Y sin embargo, dos intercambios más tarde, el texto había llegado a un lugar que sí era mío. Algo se había transmitido. Lo raro es que nunca llegué a decirlo.

Cuento esto porque describe con precisión el problema que la industria del diseño está intentando resolver ahora mismo, y que resulta bastante más profundo de lo que parece. Se llama design.md, o context file, o guidelines para agentes, y la premisa siempre es la misma: escribí tu criterio en un archivo para que la máquina pueda usarlo. Poné por escrito lo que sabés. Embotellá tu juicio. Es una idea razonable y probablemente inevitable, porque los agentes trabajan sin nosotros al lado y necesitan algo que reemplace la conversación que ya no van a tener.

La pregunta que casi nadie hace es si el juicio es la clase de cosa que se puede escribir.

Sabemos más de lo que podemos decir

Michael Polanyi dejó formulado hace sesenta años el problema que hoy nos toca administrar, en una frase que no ha envejecido nada: sabemos más de lo que podemos decir. Su ejemplo favorito era andar en bicicleta. Cualquiera que sepa hacerlo lo hace sin pensar, pero casi nadie puede enunciar la regla física que lo mantiene en equilibrio, y quien la enuncia no la usa para pedalear. Reconocer una cara entre miles funciona igual: la reconocemos al instante y no podemos describir cómo. Polanyi llamó a eso conocimiento tácito, y su punto no era que fuera misterioso, sino que era estructural: hay saberes que existen en la práctica y no en la proposición.

El criterio de diseño vive casi entero ahí. Sabemos que una interfaz está mal antes de poder decir por qué. Sabemos que un texto no suena bien sin tener la regla a mano. Un diseñador con experiencia mira una pantalla y detecta el problema en dos segundos, y después necesita veinte minutos para construir la explicación, que además es una reconstrucción posterior y no el mecanismo real que usó. Todo nuestro oficio se transmitió así durante décadas: por proximidad, por corrección repetida, por mirar a alguien decir "no, así no" sin poder explicar del todo por qué.

Lo nuevo es que ahora se nos pide convertir eso en texto. No porque hayamos entendido mejor nuestro criterio, sino porque cambió quién necesita leerlo.

El oficial de cumplimiento

La evidencia más clara de qué pasa cuando lo intentamos la registró Yesenia Perez-Cruz, y es específica y demoledora. Construyendo un prototipo con un agente sobre un design system mínimo, notó que el agente rellenaba cada hueco con el mismo patrón: un ícono grande dentro de un contenedor gris, una y otra vez. Su diagnóstico no fue el que uno esperaría. No era un problema de gusto: era que el agente no entendía qué estaba construyendo.

Entonces probó lo que todos haríamos, que es darle un principio. Algo así como que un color debe portar significado, y si no lo porta es decoración. El agente lo aplicó como un oficial de cumplimiento, marcando todo lo que técnicamente violaba la regla, sin ninguna noción de cuándo la regla importaba. Es el fracaso más instructivo posible, porque muestra que un principio abstracto no transporta criterio: transporta una instrucción que se puede seguir al pie de la letra hasta volverla absurda.

Lo que sí funcionó fue otra cosa. Clasificar cada superficie según el trabajo que la persona iba a hacer ahí —orientarse, comparar, editar en masa, leer un registro— y, sobre todo, dar ejemplos canónicos. Los ejemplos pesaron más que cualquier principio escrito. Y eso ya no es un detalle técnico: es una tesis sobre la naturaleza del criterio. Lo que se puede embotellar no es la regla, es el caso y su porqué. El juicio no viaja en forma de proposición; viaja en forma de ejemplo con razonamiento adjunto.

Hay un detalle de su relato que me quedó dando vueltas más que ningún otro: el agente no tiene un colega a quién preguntarle si alguien ya resolvió esto antes. Nosotros aprendimos casi todo así, preguntando al lado. Lo que estamos intentando escribir en un archivo es, en buena medida, la conversación que ese archivo viene a reemplazar.

Lo que se preserva y lo que se atrofia

Acá se abre la tensión que me interesa de verdad, y no la voy a resolver del todo porque creo que las dos mitades son ciertas.

Escribir el criterio puede preservarlo. Articular obliga a entender: cuando tengo que explicar por qué algo funciona, descubro las veces que no lo sé y me veo forzada a pensarlo. Un equipo que se sienta a redactar sus principios de diseño casi siempre sale de esa reunión sabiendo más que cuando entró, no por el documento sino por la discusión que hizo falta para escribirlo. En ese sentido, externalizar el juicio es una forma de ejercitarlo, y bastante exigente.

Pero también puede atrofiarlo, y por un mecanismo silencioso. Una vez que la conclusión está en el archivo, nadie vuelve a derivarla. El equipo que discutió durante semanas para llegar a esa línea entiende perfectamente de dónde salió; quien entra el año que viene la lee como un hecho. Hereda la conclusión sin el razonamiento, que es exactamente lo que el artículo anterior describía como delegar sin participar. La regla sobrevive y el criterio que la produjo se pierde, y lo peor es que desde afuera no se nota, porque el documento sigue igual de prolijo.

Es la misma pregunta que vengo persiguiendo desde hace dos artículos, en otra escala. Ahí era cuánta fricción conservar para una persona. Acá es qué se transmite entre generaciones de un equipo: si lo que pasa de mano en mano son las respuestas o la capacidad de encontrarlas.

Un archivo con variedad suficiente

Stafford Beer, que pensó estos problemas mucho antes de que existieran los agentes, aporta el criterio más útil que conozco para decidir cuándo un documento así se volvió peligroso. Su idea central es la variedad: la medida del cambio que un entorno produce, y que un sistema tiene que ser capaz de absorber para seguir siendo viable. Un sistema con menos variedad que su entorno no puede responder a lo que le pasa; se vuelve rígido y, tarde o temprano, irrelevante.

Un archivo estático tiene variedad cero. Fue escrito en un momento, frente a unos problemas, con el conocimiento de entonces. El entorno sigue moviéndose y el documento no. Al principio la brecha es imperceptible y todo funciona; después empieza a producir decisiones que nadie tomaría hoy pero que están respaldadas por escrito. Ahí es donde una guía se convierte en dogma, y no por un error de redacción, sino por una propiedad estructural de cualquier cosa que se congela.

Beer tiene además una frase que conviene aplicarle a nuestros propios documentos: el propósito de un sistema es lo que hace. No lo que declara, no lo que sus autores quisieron. Si nuestro design.md está produciendo consistencia mecánica y decisiones que nadie defiende, ese es su propósito real, por más que en el encabezado diga otra cosa.

La herencia

Quizás por eso convenga cambiar lo que le pedimos a estos archivos. Un design.md no es el juicio de un equipo: es su residuo, la marca que dejó un criterio que se ejerció en otro lado. Sirve, y sirve mucho, pero confundir el residuo con la cosa es exactamente lo que convierte una guía en dogma. Un archivo vivo se distingue de uno muerto por una sola cosa, y no es su contenido: es si alguien todavía discute lo que dice. El día que un equipo deja de preguntarle por qué a su propio documento, el documento sigue ahí, impecable, y el criterio ya se fue.

Y hay algo de la escena del principio que me sigue dando vueltas. Cuando dije que no lo diría así, no transmití una regla, porque no la tenía. Transmití un caso, y después otro, y en algún momento el texto empezó a sonar mío. Lo que viajó no fue el principio: fue la corrección repetida, la fricción de volver sobre lo mismo hasta que algo se ajustó. Así aprendimos a diseñar nosotros también, mirando a alguien decir "no, así no" sin poder explicar del todo por qué. Tal vez lo que estamos intentando meter en un archivo sea justamente lo único que nunca se transmitió por escrito. Y entonces la pregunta no es cómo documentamos mejor nuestro criterio, sino qué le vamos a dejar a quien venga después: un conjunto de conclusiones, o la práctica que las produjo.