Cuatro controles que impiden que el agente rompa el sistema

No puedes revisar lo que un agente produce

Un agente compone a velocidad industrial. Donde una persona hacía tres pantallas en una mañana, él hace cuarenta antes del café. Ese es el motivo por el que lo quieres en el equipo, y también el motivo por el que el método de siempre se rompe: revisar pantalla por pantalla, que era el control de calidad de toda la vida, se convierte en el cuello de botella que anula la ventaja. Si para validar lo que el agente genera necesitas el mismo tiempo que habrías tardado en hacerlo a mano, no has ganado nada.

La tentación es revisar más rápido. La salida es no revisar el output en absoluto.

Dejas de juzgar pantallas; defines la aptitud del sistema

Hay una idea prestada de la arquitectura de software que aquí encaja entera: la fitness function, una función que mide cuánto se acerca un sistema a las cualidades que quieres que tenga, y que se ejecuta sola en cada cambio. No juzga el resultado una vez terminado; comprueba, de forma continua y automática, si lo que se acaba de producir sigue perteneciendo al sistema.

El ebanista no inspecciona cada pieza al microscopio cuando fabrica cien sillas iguales. Construye una plantilla, una horma, y todo lo que no encaja en ella se cae solo, antes de llegar al montaje. El control deja de ser una mirada al final y pasa a ser la forma del molde. Tu trabajo ya no es revisar las cuarenta pantallas: es tallar la horma una vez y dejar que rechace ella lo que no entra.

Cuatro hormas bastan para sostener un sistema de diseño frente a un agente.

1. Conformidad de tokens

El primer control es el más simple y el que más fuga tapa: ningún valor crudo. Ni un #hex, ni un 16px suelto, ni un radio inventado. Todo color, todo espaciado, toda medida tiene que venir del vocabulario de tokens o no entra. Es un lint que recorre lo generado y bloquea el merge en cuanto aparece un literal que no pertenece al sistema.

# Falla el merge si aparece un color que no viene del vocabulario
deny[msg] {
  some d in input.declarations
  is_raw_color(d.value)
  msg := sprintf("Valor crudo '%s' en %s: usa un token", [d.value, d.path])
}

Parece poca cosa. Es la diferencia entre un sistema que se mantiene coherente solo y uno que se erosiona un hex cada vez, hasta que nadie sabe ya cuál es el azul de verdad.

2. Regresión visual

El segundo control mira lo que el lint no ve: que la pantalla, además de usar las piezas correctas, siga pareciéndose a sí misma. Snapshots de la interfaz generada, diffs contra una referencia aprobada y un umbral por debajo del cual la diferencia se ignora y por encima del cual se detiene todo. La deriva visual (ese desplazamiento lento e invisible en cada cambio) deja de poder colarse, porque cualquier desviación sin aprobar levanta la mano.

3. Regresión de accesibilidad

El tercero convierte la accesibilidad en una condición de merge, no en una auditoría que llega tarde. Contraste, orden de foco, roles, tamaño mínimo de impacto: comprobados en CI sobre la interfaz que el modelo acaba de generar, y un fallo bloquea la integración igual que lo haría un test roto. Es la única forma de que el European Accessibility Act sea una propiedad del sistema y no un susto antes de la fecha límite.

4. Conformidad de contrato

El cuarto vigila que el agente respete la API del sistema en lugar de inventarse la suya. El componente generado usa props que existen, variantes que están declaradas, composiciones que el sistema permite; no aparece un size="extra-huge" que nadie definió ni un botón anidado donde no debe haberlo. El sistema tiene un contrato, y lo generado se valida contra él antes de poder vivir en la rama.

El control no frena al agente: lo libera

Es tentador leer cuatro controles como cuatro frenos. Son lo contrario. Sin raíles, cada salida del agente es una negociación manual: hay que mirarla, dudarla, aprobarla a mano, y la velocidad que prometía se evapora en revisiones. Con raíles, el agente corre todo lo que sabe correr y lo que se sale se rechaza solo, sin que tú estés delante. La horma es justo lo que te permite soltarle la mano.

Y ahí cambia el oficio. El diseñador deja de ser el inspector que mira pantalla por pantalla y pasa a ser quien diseña los controles: quien decide qué cuenta como «sigue siendo nuestro sistema» y lo escribe en una función que lo defiende sin él. De revisar el output a juzgar lo que produce el agente escribiendo las reglas que lo juzgan por ti.

Tallar esas cuatro hormas sobre tu propio sistema, y conectarlas a la cadena que el agente recorre cada vez que compone, es el trabajo de las últimas semanas de el Programa.