En Bodados escribimos seis validadores para impedir que el producto se alejara de su sistema de diseño.
Uno revisa tokens. Otro, componentes. Los demás miran copy, movimiento, flujos y reglas de interfaz. La intención era sencilla: si el criterio está escrito, un agente puede construir más deprisa sin inventar el producto en cada archivo.
Ejecuté la auditoría sobre el código actual.
El primer validador encontró 354 incumplimientos.
El segundo encontró 130 errores, 81 avisos y 60 observaciones.
El problema interesante no fue la cantidad. Fue que, al pasar del primer script al agregador que debía reunir los resultados, aquellos 354 incumplimientos dejaron de contar en el total.
No era un fallo del modelo.
Era un desacuerdo entre dos piezas de código determinista.
Habíamos escrito la regla. No habíamos escrito el contrato entre reglas.
El validador de tokens termina con un mensaje parecido a este:
Validation Failed: Found 354 design system violations.
Y devuelve un código de error. Hasta ahí, bien: ha visto el problema y ha avisado a la siguiente capa.
El agregador recibe el fallo e intenta extraer el número. Pero busca formatos como “130 errors, 81 warnings” o “354 errors”. La frase “354 design system violations” no coincide con ninguno.
El agregador sí marca ese validador como fallido, pero suma cero al contador general por esa prueba.
En esta ejecución el proceso completo todavía falla porque el validador de componentes aporta otros 130 errores en un formato que el agregador sí entiende. Por tanto, no sería correcto decir que el sistema dejó pasar el build actual.
La afirmación exacta es más útil:
El control detectó 354 incumplimientos y el resumen no supo contarlos. Si ése hubiera sido el único validador con errores, el total habría quedado a cero.
Hay una lección bastante menos vistosa que “la IA cambia el diseño”, pero bastante más importante: un sistema de control también necesita un sistema de control.
Qué encontraron realmente los validadores
La auditoría no preguntó si la interfaz era bonita. Buscó decisiones concretas que Bodados ya había declarado como parte de su sistema:
- valores de color o espacio fuera de los tokens;
- anchos arbitrarios escritos directamente en componentes;
- componentes sin contrato de propiedades;
- imágenes sin alternativa textual;
- estilos de color incrustados;
- modales sin tratamiento claro del foco o de la tecla Escape;
- formularios sin estado de carga visible;
- transiciones sin una alternativa para movimiento reducido;
- texto de interfaz que se aleja de las reglas editoriales.
El snapshot produjo estos resultados:
| Control | Resultado | Salida del proceso |
|---|---|---|
| Tokens | 354 incumplimientos | error |
| Componentes | 130 errores · 81 avisos · 60 observaciones | error |
| Copy | 0 errores · 30 avisos · 98 observaciones | correcto |
| Movimiento | 0 errores · 117 avisos · 448 observaciones | correcto |
| Flujos | 0 errores · 10 avisos | correcto |
| Interfaz | 15 avisos | correcto |
Estas cifras no equivalen automáticamente a 484 defectos percibidos por usuarios. Un analizador estático puede duplicar hallazgos, señalar falsos positivos o aplicar una regla demasiado rígida. Lo que sí demuestran es que las decisiones escritas pueden localizarse en el producto y devolver una lista reproducible.
Y también demuestran que todavía falta decidir qué hacemos con esa lista.
Detectar no es gobernar
En muchos equipos, la documentación termina donde debería empezar el mecanismo.
Se escribe “usa tokens”, “cada modal debe gestionar el foco” o “el color no puede ser la única señal”. Después se entrega esa frase a una persona o a un agente y se espera obediencia.
Bodados da un paso más: convierte parte del criterio en código ejecutable. Pero la prueba ha encontrado cuatro contratos distintos que tienen que alinearse:
- La regla de diseño. Qué comportamiento consideramos correcto.
- El detector. Qué patrón de código usamos como aproximación a esa regla.
- La severidad. Qué es un error, qué es un aviso y qué requiere revisión humana.
- La puerta. Qué combinación impide publicar.
Si una de esas capas habla otro idioma, el sistema produce teatro de cumplimiento. Parece que hay un control porque existe un script llamado “validate”, aunque nadie pueda garantizar qué bloquea.
El arreglo no es una expresión regular mejor
Se puede parchear el agregador para que entienda la frase actual. Sería útil, pero insuficiente.
El contrato correcto no debería depender de leer prosa destinada a personas. Cada validador debería devolver una estructura estable:
{
"validator": "tokens",
"status": "fail",
"errors": 354,
"warnings": 0,
"version": "1"
}
La terminal puede seguir mostrando una explicación legible. El agregador, en cambio, consume datos. Así podemos cambiar la frase sin cambiar el significado.
Después hace falta probar la propia puerta con tres casos mínimos:
- repositorio limpio: debe pasar;
- un único error de tokens: debe fallar;
- solo avisos: debe aplicar la política acordada, no una decisión accidental.
La prueba decisiva no es que el validador encuentre muchos fallos. Es que un incumplimiento mínimo y conocido detenga exactamente aquello que prometimos detener.
“Con tantas reglas vais a impedir diseñar”
Es una objeción razonable.
Un validador mal diseñado convierte preferencias en dogma. Puede penalizar una excepción necesaria o empujar al equipo a satisfacer el test en vez de mejorar la experiencia.
Por eso no toda decisión debe tener la misma severidad.
Una imagen sin alternativa textual puede ser un error. Un modal sin foco gestionado puede ser un error. Un ancho específico en una composición editorial quizá sea una excepción documentada. El tono de una frase probablemente necesite revisión humana.
Las reglas no eliminan el criterio. Separan los lugares donde ya hemos decidido de los lugares donde todavía hay que decidir.
Una excepción explícita es diseño. Un silencio que cada agente resuelve de una manera es deuda.
Lo que rompió primero
Creía que la prueba iba a enseñar si un agente respetaba el sistema de diseño de Bodados.
Enseñó algo anterior: el sistema todavía no podía describir de manera inequívoca el resultado de sus propios controles.
No basta con documentar componentes, tokens y patrones. Hay que diseñar cómo se acusa un incumplimiento, cómo viaja entre capas y quién tiene autoridad para detener una publicación.
El diseño agéntico no empieza cuando el modelo genera una pantalla. Empieza cuando el equipo puede responder, sin interpretar un log a ojo:
¿Esta pantalla cumple las decisiones que ya habíamos tomado?
La siguiente versión de la auditoría tendrá menos épica y un contrato mejor. Eso es progreso.
En el Instituto de Diseño Agéntico trabajamos con sistemas reales precisamente por esto: una regla escrita en una diapositiva parece completa; al conectarla a un producto descubre todo lo que todavía no habíamos decidido.
Nota de verificación editorial
Auditoría ejecutada el 14 de septiembre de 2026 sobre Bodados, revisión 44fffc2, con los seis validadores del repositorio contra src/. Las cifras son una fotografía de ese árbol de trabajo, no una métrica permanente de calidad. El comportamiento del agregador se verificó en scripts/lib/run-audit.mjs; los validadores individuales devolvieron error cuando encontraron errores. No se corrigió el código para producir este texto.
Fuentes
- 01 Expediente A.04 · Bodadoswww.institutoagentico.com/casos/bodados →
A seguir
Redactado con ayuda de IA, contrastado contra su fuente y firmado por Joan Arbó.