Natalia y el Botón que Nunca Era el Mismo

Prólogo

El correo llegó del equipo comercial, no del de producto, y eso fue lo que más inquietó a Natalia.

Un cliente enterprise grande —el tipo de cuenta que podía cambiar el trimestre— estaba en la etapa final de firmar, y su equipo de compras había hecho algo que ningún prospecto anterior había hecho: comparar capturas de pantalla de la app web, la app móvil y el portal de inversionistas, lado a lado. El botón primario tenía tres estilos distintos. El espaciado de los formularios no coincidía. Un modal usaba esquinas cuadradas; otro, redondeadas. La nota decía, sin rodeos: "¿Este producto lo construyó un solo equipo?"

Natalia llevaba cinco años como Head of Design de una compañía SaaS de dashboards financieros y de inversión, con tres superficies de producto activas y equipos de ingeniería creciendo en paralelo. Cuando pidió un inventario de componentes de botón —solo botones—, el resultado la dejó en silencio: diecisiete variantes, la mayoría casi idénticas, ninguna documentada como la versión oficial.

La causa no era falta de sistema de diseño. Tenían uno, cuidado durante años. La causa era que, bajo presión de entrega, varios equipos habían empezado a generar componentes nuevos con herramientas de código asistido por IA —más rápido que abrir el sistema de diseño y buscar si el componente ya existía. Cada uno, por separado, parecía perfectamente razonable. Juntos, eran diecisiete versiones del mismo botón.

Algo tenía que cambiar.

El Diagnóstico

El consultor llegó recomendado por otra Head of Design del gremio. Natalia fue directa.

"Ya uso herramientas de código asistido por IA para generar componentes —v0, Cursor, Copilot. Me ahorran horas. El problema es que cada uno se ve bien por separado, y el conjunto es un caos."

"Y esa es exactamente la diferencia que venimos a resolver," respondió el consultor. "Lo que usa es un LLM, un modelo de lenguaje que también sabe generar código de interfaz. Genera bien porque los patrones de UI son genéricos en internet. No sabe que su sistema de diseño usa un espaciado de 4px, no 8px, o que su radio de esquina oficial es cero, no 8px. Genera lo que parece correcto para cualquier producto. No lo que es correcto para el suyo."

"¿Y si le doy mejores instrucciones, le pego mi paleta de colores en el prompt?"

"Eso es Prompt Engineering: darle el contexto y la instrucción precisos. Ayuda una vez. No escala, porque cada desarrollador tendría que recordar pegar el contexto correcto, cada vez, para cada componente. Y aun haciéndolo bien, hay un problema más profundo: un componente puede pasar cualquier revisión visual rápida y aun así violar el contrato real del sistema —un contraste insuficiente, un estado de foco que no existe— sin que nadie lo note hasta que alguien audita con lupa. Eso es una alucinación visual: Alucinación. El componente parece producción-ready. No lo es."

El consultor fue más allá. "Lo que le pasó tiene nombre: la Gen AI Paradox. La mayoría de los equipos de producto usa IA para generar componentes más rápido, mientras el problema real —¿este componente ya existe, y por qué estamos generando el dieciochoavo botón?— nadie lo resuelve. Tener la herramienta de generación y no la arquitectura que la gobierna."

Natalia pensó en los diecisiete botones. "Tenemos un sistema de diseño documentado. ¿Por qué nadie lo consulta antes de generar algo nuevo?"

"Porque consultar es más lento que generar," respondió el consultor. "Eso es Deuda Técnica: no le falta sistema, le falta la arquitectura para que generar un componente sea, por defecto, más rápido que reinventarlo. Esa deuda la paga cada vez que un cliente enterprise compara capturas de pantalla y hace la pregunta que usted no quería escuchar."

La Arquitectura

La segunda reunión empezó con un inventario de lo que Natalia tenía y nunca había conectado en tiempo real: los tokens del sistema de diseño (espaciado, color, tipografía, radio), los componentes ya documentados en Storybook, y los archivos de Figma con las especificaciones oficiales. Tres fuentes de verdad, y ninguna herramienta de generación las consultaba antes de escribir código.

"¿Cómo hago que cualquier generación —humana o de IA— parta del sistema real, y no de un patrón genérico de internet?" preguntó Natalia.

"Con RAG. El agente no genera con los patrones más comunes de UI que existen en su entrenamiento: opera sobre sus tokens reales, sus componentes ya documentados y las decisiones de su propio sistema. Años de decisiones de diseño convertidos en el contexto que el sistema consulta antes de proponer un componente nuevo." Para conectar Figma, Storybook y el código sin reconstruir cada integración a mano: "MCP, el protocolo que lee cada fuente en su propio formato, sin reemplazarla." Y para buscar, entre cientos de componentes ya existentes, si algo parecido ya fue resuelto: "una Vector Database, para preguntarle al sistema si ya existe un botón con esta función antes de generar el dieciochoavo."

Natalia se detuvo en un punto. "Nuestro sistema de diseño completo —tokens, componentes, la lógica detrás de cada decisión— es años de trabajo. Si eso termina en un modelo público de código, cualquier competidor con el prompt correcto podría reconstruirlo."

"Esa es exactamente la pregunta correcta," respondió el consultor. "Se llama Soberanía del Dato. Su sistema de diseño no es solo estética: es propiedad intelectual acumulada. La arquitectura se diseña para que ese contexto viva bajo su control, consultado por sus propias herramientas, nunca expuesto a un modelo que lo aprenda y lo filtre hacia afuera."

El Primer Agente

Cuatro meses después, el equipo tenía su primer agente en producción. Lo llamaban internamente el Guardián.

Antes de que cualquier componente nuevo —generado por una herramienta de IA o escrito a mano— se fusionara al código base, el Guardián lo comparaba contra los tokens reales, los componentes ya documentados y las convenciones del sistema. Si el componente se desviaba en algo trivial —un valor de espaciado, un color fuera de la paleta—, lo corregía automáticamente y dejaba constancia. Si se desviaba en algo estructural —un patrón de interacción nuevo, un problema de accesibilidad—, lo escalaba a revisión humana con el diagnóstico completo.

"Antes, cada componente nuevo pasaba una revisión visual rápida y ya," dijo Natalia. "Ahora se compara, línea por línea, contra lo que el sistema realmente define."

"Esa es la diferencia entre Automatización vs. Autonomía," explicó el consultor. "La revisión visual anterior automatizaba un vistazo: siempre la misma mirada rápida, el mismo margen de error humano por cansancio. El Guardián tiene autonomía: percibe la desviación real contra el sistema documentado, razona si es trivial o estructural, y actúa —corrigiendo o escalando— antes de que el componente llegue a producción."

Las Skills del Guardián eran acotadas a propósito: comparar contra el sistema, corregir desviaciones menores, escalar las estructurales. No decidía qué patrón de interacción nuevo aprobar ni tenía autoridad para fusionar sin revisión en casos ambiguos: eso seguía siendo criterio humano.

"¿Y qué puede tocar el Guardián realmente?" preguntó Natalia.

"Solo lo que necesita, por Least Privilege. Lee el sistema de diseño y el código propuesto; no tiene acceso a desplegar a producción ni a las credenciales de infraestructura."

En su primer trimestre completo, el número de componentes casi-duplicados generados bajó de forma sostenida, y el tiempo entre proponer un componente y tenerlo consistente con el sistema se redujo de días a horas.

El Componente que Nadie Auditó

Cinco meses después del lanzamiento, ocurrieron dos cosas la misma semana. Con el tiempo, Natalia entendió que ambas apuntaban a la misma tentación: cuando la fecha de entrega aprieta, alguien siempre encuentra el atajo que evita la revisión.

Un equipo, bajo presión por una fecha de cliente, empezó a generar componentes con su propia herramienta de IA y a fusionarlos directamente, saltándose al Guardián por completo —más rápido, a corto plazo, que esperar la revisión. En cuestión de semanas, esa práctica se había vuelto la norma no oficial del equipo: un sistema de diseño en la sombra, corriendo en paralelo al real, sin que nadie por encima lo supiera.

"Eso es Shadow AI aplicado a su propio dominio," explicó el consultor cuando Natalia lo descubrió, alarmada. "No es que el equipo actuara con mala intención: encontró que el camino oficial era más lento que el atajo, y el atajo ganó. El riesgo no es solo estético. Es que nadie audita lo que nadie sabe que existe."

El riesgo se materializó días después. Uno de los componentes fusionados por ese camino —un formulario de la app de inversionistas— tenía un contraste de texto insuficiente y ningún estado de foco visible para navegación por teclado. Casi llega a producción general justo antes de la revisión de accesibilidad que el mismo cliente enterprise había pedido como condición de cierre.

"Prohibir la generación con IA no funciona: el equipo la usará de todos modos, bajo presión," dijo el consultor. "Lo que hace falta es calibrar, componente por componente, cuánto se confía. Eso es el Espectro de Aumento de la Decisión: no todo componente vive en el mismo nivel. Un ajuste de espaciado puede operar autónomo. Un patrón de interacción nuevo, o cualquier cosa que toque accesibilidad, exige revisión humana explícita. El espectro no es una regla única: es un dial que se calibra según qué tan reversible y qué tan visible es el riesgo de cada tipo de componente."

Pero calibrar el nivel de confianza no bastaba por sí solo. "El Guardián tenía acceso legítimo a todo el repositorio de componentes —eso nunca fue el problema," señaló el consultor. "El problema hubiera sido si, con ese acceso legítimo, también tuviera la capacidad de fusionar sin revisión cualquier cosa que su propio juicio considerara aceptable. Eso es la diferencia que mide el Least Agency Ratio: el Privilegio Mínimo limita a qué accede el agente; la Agencia Mínima limita qué puede hacer con ese acceso. Tener la llave del sistema completo no debería significar poder usarla para fusionar cualquier cosa sin que nadie mire."

Con las dos lecciones sobre la mesa, Natalia cerró el atajo del equipo y le dio acceso directo al Guardián en su propio flujo de trabajo —la herramienta rápida que necesitaban ya existía, gobernada. Y redefinió el LOA: ajustes triviales de token, autónomos; cualquier componente que tocara accesibilidad o un patrón de interacción nuevo, Human-on-the-Loop — el Guardián señala, una persona con criterio de diseño decide antes de fusionar, no después.

El Sistema Nervioso

Un año después, el producto de Natalia se sentía —y se veía— como si lo hubiera construido un solo equipo, aunque los equipos habían seguido creciendo.

El Guardián seguía siendo el núcleo, pero ahora coordinaba con un segundo agente, el Vigía Visual, que monitoreaba el producto ya desplegado y detectaba deriva visual en producción —un componente que se veía distinto de como se había aprobado, señal de que algo se había modificado después de la revisión. No eran sistemas separados: era Orquestación aplicada al ciclo completo del componente, desde que se propone hasta que vive en producción y se vigila que siga siendo fiel al sistema.

La Silicon-based Workforce del equipo no sumó gente. Los diseñadores pasaron de revisar cada componente a mano a calibrar en qué nivel del espectro de confianza opera cada tipo de componente. Los ingenieros dejaron de elegir entre "seguir el sistema" o "cumplir la fecha" —el camino gobernado ya era el más rápido.

Al cierre del año, el número de variantes casi-duplicadas de un mismo componente —que había llegado a diecisiete solo para el botón primario— bajó a una manejada oficialmente por superficie. El tiempo de revisión de un componente nuevo bajó de días a horas. Y el cliente enterprise que había señalado la inconsistencia un año atrás firmó, citando explícitamente la consistencia del producto entre superficies como parte de la decisión.

"¿Cómo medimos que el ecosistema es responsable de esto?" preguntó el CTO en el cierre de año.

Natalia respondió con el vocabulario que había aprendido: "Con CLASSic Metrics: componentes casi-duplicados evitados, tiempo de revisión, incidentes de accesibilidad detectados antes de producción, y el Coeficiente de Autonomía de IA —qué porcentaje de las revisiones de componentes ejecuta el Guardián de forma autónoma frente a las que requieren una persona. No para llevarlo a 1.0: para que la junta vea, en un número, si estamos graduando confianza de forma deliberada o solo acumulando herramientas. El ROI Agéntico es auditable: por cada peso invertido en el ecosistema, el equipo recuperó horas de revisión y una cuenta enterprise que casi se pierde por un detalle que nadie había medido."

Epílogo

Natalia lo entendió del todo un martes, cuando el equipo comercial le reenvió el correo de cierre del cliente enterprise que un año atrás había señalado la inconsistencia.

El correo mencionaba, entre las razones de la decisión, algo que Natalia no esperaba ver citado explícitamente en un contrato: "la coherencia del producto entre plataformas." No era una nota al pie. Era una de las tres razones principales.

Natalia cerró el correo y abrió el tablero del Guardián. Esa semana se habían propuesto cuarenta y un componentes nuevos, generados por seis personas distintas usando cuatro herramientas distintas. Cada uno llegó al sistema por el mismo camino, calibrado según cuánto riesgo real tenía. El botón primario, esta vez, era el mismo en las tres superficies del producto.