El stack de agentes del ingeniero de diseño

Los ingenieros de diseño necesitan un stack de agentes diferente al de los ingenieros puros. La infraestructura estándar de agentes optimiza para la corrección: las pruebas pasan, los tipos se verifican, las reglas de linting se cumplen. Nadie ha construido el equivalente para la calidad de diseño — la infraestructura que asegura que los agentes produzcan trabajo que se vea deliberado, no meramente funcional. Los seis componentes del stack de agentes del ingeniero de diseño son hooks tipográficos, hooks del sistema de color, validación de layout, gates de Lighthouse, linting de accesibilidad y pruebas de regresión visual. Juntos, codifican el oficio dentro del pipeline.

La brecha se hace visible en cada interfaz generada por IA. El espaciado es inconsistente. Los tamaños de fuente se desvían fuera de la escala. Valores hexadecimales hardcodeados evitan el sistema de tokens. Aparecen cambios de layout en móvil porque nadie verificó el CLS después de que el agente modificara el CSS. El agente pasó cada prueba, satisfizo cada verificación de tipos y produjo un resultado que un revisor de código aprobaría, porque los revisores de código evalúan lógica, no coherencia visual. El ingeniero de diseño nota los problemas de inmediato. La infraestructura del agente no nota nada, porque nadie le dijo qué buscar.

La infraestructura de agentes para ingenieros ha madurado rápidamente. Los hooks bloquean comandos peligrosos de git. Los gates de evidencia requieren pruebas antes de marcar el trabajo como completo. Los loops de calidad exigen releer cada línea. La calidad de ingeniería se descompone en propiedades verificables (corrección, rendimiento, seguridad, seguridad de tipos), y cada propiedad se mapea a una herramienta que produce resultados binarios.

La calidad de diseño también se descompone. El gusto es un sistema técnico con cuatro componentes codificables: restricciones, criterios de evaluación, reconocimiento de patrones y coherencia. Los tres primeros se mapean directamente a infraestructura automatizada. La coherencia requiere juicio humano, pero esos tres cubren suficiente terreno para prevenir las fallas de diseño más comunes que un agente produce. Violaciones tipográficas, deriva de color, inestabilidad de layout, regresiones de rendimiento y fallas de accesibilidad son todas detectables por máquinas. El stack de agentes del ingeniero de diseño las detecta.

Qué necesitan los ingenieros de diseño de los agentes

Un ingeniero puro pregunta: ¿funciona el código? Un ingeniero de diseño hace seis preguntas adicionales, cada una dirigida a una dimensión diferente de la calidad visual.

Consistencia visual. Los valores de espaciado siguen la cuadrícula de 8 puntos o la escala de espaciado definida. La alineación respeta el ritmo vertical. Las relaciones proporcionales entre elementos se mantienen estables a través de los tamaños de viewport. Un agente que agrega un nuevo componente de tarjeta usando margin-top: 13px en lugar de var(--space-md) ha introducido ruido visual que ninguna prueba detectará.

Disciplina tipográfica. Cada tamaño de fuente en el codebase se mapea a un paso en la escala tipográfica. Sin tamaños rogue. Sin overrides inline que eviten las custom properties. El uso de pesos sigue la jerarquía establecida: 700 para encabezados, 400 para cuerpo, 300 para metadatos. Un agente que establece un subtítulo en font-size: 19px ha inventado un paso que no existe en la escala, y la jerarquía visual se fractura.

Cumplimiento del sistema de color. Cada valor de color referencia un token de diseño. Sin valores hexadecimales hardcodeados fuera de :root. Las relaciones de contraste cumplen WCAG AA como mínimo, AAA donde sea posible. El sistema de color cero en mi sitio usa cuatro niveles de opacidad contra negro absoluto, y cada nivel cumple AAA. Un agente que introduce color: #cccccc ha evitado el sistema de tokens y creado una relación de contraste que nadie validó.

Conciencia de rendimiento. Sin Cumulative Layout Shift. El First Contentful Paint se mantiene dentro del presupuesto. El Total Blocking Time no regresiona. El agente debe entender que los cambios visuales tienen consecuencias de rendimiento. Un cambio de CSS que dispara recalculación de layout en cada evento de scroll es un bug de rendimiento, sin importar cómo se vea el cambio.

Accesibilidad. Estructura semántica de HTML. Jerarquía apropiada de encabezados. Atributos ARIA donde se necesitan, ausentes donde no. Verificación de contraste de color. Indicadores de foco. Compatibilidad con lectores de pantalla. La auditoría de Lighthouse captura el subconjunto medible, pero el agente también debe mantener la semántica estructural que las herramientas automatizadas pasan por alto.

Gusto. Lo más difícil de codificar. Coherencia entre elementos. Moderación en la decoración. Espacio en blanco intencional en lugar de vacío accidental. El gusto es la cualidad que distingue un layout que sigue cada regla pero se siente incorrecto de un layout que sigue cada regla y se siente correcto. Las verificaciones automatizadas detectan violaciones. La capa de gusto detecta no-violaciones que aun así carecen de consideración.

Seis componentes del stack del ingeniero de diseño

Cada componente se mapea a un modo de falla específico que he observado en el output generado por agentes. Los componentes no son teóricos. Cada uno existe porque algo salió mal — la misma historia de origen detrás de cada hook en mi infraestructura de 95 hooks.

1. Hooks tipográficos

Un hook tipográfico valida que cada declaración de font-size en un commit referencie una custom property de CSS de la escala tipográfica. El hook escanea archivos modificados en busca de valores crudos en píxeles o rem que no se mapeen a un paso definido.

#!/bin/bash
INPUT=$(cat)
DIFF=$(echo "$INPUT" | jq -r '.tool_input.command // empty')

# Catch font-size declarations that bypass the type scale
if echo "$DIFF" | grep -qE 'font-size:\s*[0-9]+(px|rem|em)'; then
  cat << EOF
{"decision": "block", "reason": "Font size must use a --font-size-* token"}
EOF
fi

El hook es directo. Una versión más refinada parsea el valor y verifica si el equivalente en píxeles coincide con algún paso de la escala de 13 pasos. El objetivo no es la sofisticación. El objetivo es que el agente no pueda introducir un tamaño de fuente rogue sin que la infraestructura lo señale. El principio de Bringhurst sobre relaciones tipográficas armoniosas se cumple no porque el agente entienda la armonía, sino porque el hook impone la escala que la encarna.¹

El peso de fuente merece validación separada. Mi sistema usa tres pesos: 700, 400 y 300. Un agente que establece el título de una tarjeta en font-weight: 600 ha introducido un peso que contradice la jerarquía establecida. Un hook tipográfico detecta la desviación antes de que llegue a producción.

2. Hooks del sistema de color

La deriva de color es la falla de diseño más común en CSS generado por agentes. El agente sabe que el texto debe ser blanco sobre un fondo oscuro. Lo que no sabe es que #ffffff debería ser var(--color-text-primary), o que el texto secundario al 65% de opacidad es var(--color-text-secondary) y no rgba(255,255,255,0.60).

El hook de color escanea valores de color hardcodeados fuera de :root y las definiciones de tokens de diseño:

# Block hardcoded colors outside token definitions
if echo "$DIFF" | grep -vE '^\+.*:root' | \
   grep -qE '#[0-9a-fA-F]{3,8}|rgba?\('; then
  cat << EOF
{"decision": "block", "reason": "Use color tokens, not hardcoded values"}
EOF
fi

El sistema de diseño de color cero — la misma restricción brutalista que impulsa toda la identidad visual del sitio — hace que la aplicación sea directa porque la paleta tiene exactamente diez tokens. Cualquier valor de color que no coincida con uno de esos tokens es incorrecto por definición. Una paleta más amplia requeriría validación más matizada. El enfoque basado en restricciones simplifica el hook porque la restricción simplifica el diseño.

3. Validación de layout

La validación de layout detecta dos categorías de fallas: Cumulative Layout Shift introducido por cambios de CSS, y regresiones de breakpoints responsivos.

La detección de CLS requiere medir la página antes y después del cambio. Un hook de pre-commit no puede ejecutar un navegador, pero un pipeline de CI sí. La infraestructura ejecuta Lighthouse en Chrome headless contra el despliegue de staging, compara los valores de CLS con el build anterior y bloquea el merge si el delta excede 0,01. Google considera CLS por debajo de 0,1 como “bueno”. Mi umbral es 10 veces más estricto porque he visto cómo se ve un CLS de 0,493 y no voy a regresionar.

La validación responsiva requiere verificar el layout en breakpoints definidos. Una herramienta de regresión visual captura screenshots a 375px (móvil), 768px (tablet) y 1440px (escritorio), luego los compara con imágenes de referencia. Un desplazamiento de cinco píxeles en el header a 375px que se ve bien a 1440px aparece en la comparación móvil. El agente que modificó una propiedad max-width sin probar el comportamiento responsivo queda atrapado por la infraestructura que prueba el comportamiento responsivo automáticamente.

4. Gates de Lighthouse

Un gate de Lighthouse ejecuta una auditoría completa antes de cada merge a la rama principal. El gate impone cuatro umbrales:

Los umbrales no son aspiracionales. Reflejan los puntajes actuales de producción. Cualquier commit que baje cualquier puntaje por debajo de 100 se bloquea. El gate se ejecuta en CI usando lighthouse-ci, y los resultados se retroalimentan en el pull request como un status check.

# lighthouse-ci configuration
assertions:
  performance: ["error", { minScore: 1 }]
  accessibility: ["error", { minScore: 1 }]
  best-practices: ["error", { minScore: 1 }]
  seo: ["error", { minScore: 1 }]
  cumulative-layout-shift: ["error", { maxNumericValue: 0.01 }]

El gate de Lighthouse detecta regresiones de rendimiento que ningún revisor humano notaría. Un agente que agrega una imagen sin optimizar, un script que bloquea el renderizado o un archivo de CSS que dispara un flash de contenido sin estilo falla el gate antes de que el cambio llegue a producción. El gate no entiende por qué el cambio causó una regresión. No necesita entenderlo. Bloquea la regresión, y el agente recibe la razón de la falla en su contexto para el siguiente intento.

5. Linting de accesibilidad

La validación de accesibilidad se divide en dos capas: análisis estático y evaluación en tiempo de ejecución.

El análisis estático ejecuta axe-core contra el HTML renderizado. El conjunto de reglas WCAG 2.1 AA detecta texto alternativo faltante, jerarquía de encabezados impropia, contraste de color insuficiente, etiquetas de formulario faltantes y uso incorrecto de ARIA. La verificación se ejecuta en la misma instancia de Chrome headless que el gate de Lighthouse y agrega una sobrecarga insignificante.

// axe-core integration in CI
const { AxeBuilder } = require('@axe-core/playwright');
const results = await new AxeBuilder({ page })
  .withTags(['wcag2a', 'wcag2aa', 'wcag21aa'])
  .analyze();

if (results.violations.length > 0) {
  process.exit(1); // Block the merge
}

La capa de tiempo de ejecución detecta problemas que el análisis estático pasa por alto: gestión de foco después de swaps de HTMX, navegación por teclado a través de contenido dinámico, anuncios del lector de pantalla para cambios de estado. Estas verificaciones requieren interacción programada, no solo inspección del DOM. El enfoque sin build mantiene la página lo suficientemente simple como para que la superficie de accesibilidad siga siendo manejable.

El linting de accesibilidad es el componente que la mayoría de los ingenieros ya entienden. Lo que agrega el ingeniero de diseño no es la herramienta sino el umbral: cero violaciones, no violaciones “aceptables”. La misma filosofía impulsa los puntajes 100/100/100/100 de Lighthouse: la perfección como punto de partida, no como aspiración.

6. Pruebas de regresión visual

Las pruebas de regresión visual comparan screenshots del build actual contra líneas base aprobadas. La comparación usa algoritmos de diffing perceptual que detectan cambios que un humano notaría, ignorando cambios que no (diferencias de renderizado sub-píxel, variaciones de anti-aliasing).

Herramientas como Percy, Chromatic y BackstopJS automatizan la comparación. El pipeline captura screenshots en cada breakpoint definido, ejecuta diffing perceptual contra la línea base y señala cualquier página donde el diff excede el umbral. Una diferencia de 0,1% de píxeles en un footer es ruido. Un desplazamiento de 2% en la sección hero es una regresión.

La regresión visual es la aproximación automatizada más cercana a “¿se ve bien la página?” El diffing perceptual no puede evaluar si un cambio de layout es una mejora o una degradación — solo que ocurrió un cambio. El humano revisa los diffs señalados y los aprueba o rechaza. El valor de la automatización es la cobertura: probar cada página en cada breakpoint en cada commit, una tarea que ningún humano realiza manualmente.

Cómo se mapea el stack a mi infraestructura

Los seis componentes se conectan con decisiones ya documentadas a lo largo del contenido de ingeniería de diseño en este sitio.

Los hooks tipográficos imponen la escala tipográfica de 13 pasos — una progresión basada en contenido donde la escala existe como custom properties de CSS y los hooks aseguran que esas propiedades sean los únicos tamaños de fuente en el codebase. Los hooks del sistema de color imponen el sistema de diseño de color cero: diez tokens, cuatro niveles de opacidad, sin colores de marca, no opcionales. Los gates de Lighthouse mantienen el puntaje 100/100/100/100 y previenen que cualquier commit deshaga la extracción de CSS y la eliminación de bloqueo de renderizado que lograron esos números.

El enfoque sin build simplifica todo el stack. Sin source maps que reconciliar. Sin ambigüedad de tree-shaking. Sin capa de transpilación entre el CSS escrito y el enviado. Lo que el agente escribe es lo que se envía, lo que significa que lo que los hooks validan es lo que el usuario ve.

El gate de evidencia se aplica a las revisiones de diseño de la misma manera que a las revisiones de ingeniería. “La tipografía se ve bien” no es evidencia. “Cada declaración de font-size en el diff se mapea a un token --font-size-*, verificado por el hook tipográfico” sí es evidencia. El sistema de diseño proporciona los tokens que los hooks imponen. Sin tokens, no hay nada contra qué validar. Sin hooks, los tokens son sugerencias. Nathan Curtis identificó la dinámica: un sistema sin gobernanza se degrada en documentación que nadie lee.²

La capa de gusto

Los seis componentes detectan violaciones. Los hooks tipográficos detectan tamaños de fuente incorrectos. Los hooks de color detectan valores hardcodeados. La validación de layout detecta CLS. Los gates de Lighthouse detectan regresiones de rendimiento. El linting de accesibilidad detecta fallas de WCAG. La regresión visual detecta cambios no intencionales.

Ninguno detecta el output que sigue cada regla pero aun así se siente incorrecto.

Un componente de tarjeta con tamaños de fuente correctos, tokens apropiados, CLS cero, puntajes perfectos de Lighthouse, cumplimiento completo de WCAG y sin regresión visual — pero con un espaciado que hace que el título se amontone contra la imagen, una longitud de línea que fuerza la legibilidad y un estado hover que se siente abrupto en lugar de considerado. Cada verificación automatizada pasa. La tarjeta es correcta. La tarjeta no es buena.

El gusto opera por encima de la capa de reglas. Las restricciones detectan lo que viola las reglas. Los criterios de evaluación detectan lo que falla en las métricas. El reconocimiento de patrones detecta lo que revela la segunda mirada. La coherencia detecta lo que solo expone la visión del sistema completo. Los seis componentes automatizados manejan restricciones y criterios de evaluación. El reconocimiento de patrones y la coherencia requieren el loop de calidad: el segundo (y tercer, y cuarto) pase obligatorio a través del trabajo, verificando cada vez no si las reglas se cumplen sino si el resultado merece enviarse.

El loop de calidad es donde el ingeniero de diseño se gana la mitad de “ingeniero” del título. Un ingeniero que envía código que pasa pruebas está cumpliendo con el mínimo. Un ingeniero de diseño que envía interfaces que pasan verificaciones automatizadas y sobreviven el loop de calidad mantiene un estándar que las máquinas aún no pueden evaluar. La verificación de orgullo hace cinco preguntas, y la última (“¿lo dejé mejor?”) no tiene equivalente automatizado. Tampoco lo tiene el criterio de Steve: ¿Blake firmaría esto con su nombre?

El efecto compuesto

Cada componente previene una categoría específica de fallas de diseño. Juntos, los componentes producen un efecto compuesto que excede la suma de las verificaciones individuales.

Una sesión de agente sin el stack produce output que deriva. Los tamaños de fuente se acumulan fuera de la escala. Los valores de color se hardcodean en lugar de tokenizarse. El rendimiento regresiona en incrementos pequeños que ningún commit individual dispara pero que se acumulan a lo largo de semanas. La deriva es invisible en cualquier diff individual y obvia en el agregado.

Una sesión de agente con el stack no puede derivar. Los hooks bloquean cada desviación de la escala tipográfica. El sistema de color rechaza cada valor hardcodeado. El gate de Lighthouse detecta cada regresión de rendimiento. El agente hereda los estándares del ingeniero de diseño no porque entienda esos estándares sino porque la infraestructura los impone. El agente no necesita gusto. Necesita restricciones, y las restricciones encarnan el gusto.

Jony Ive describió el proceso de diseño de Apple como “refinamiento implacable”: calidad a través de la iteración sobre un conjunto fijo de principios, no innovación a través de la novedad.³ El stack de agentes del ingeniero de diseño operacionaliza la misma idea. Los principios están fijados en tokens, escalas y umbrales. El refinamiento es implacable porque la automatización se ejecuta en cada commit.

El ingeniero de diseño que codifica estándares en el stack de agentes hace más que mantener la calidad durante la generación autónoma. Ese ingeniero escala la calidad. Cada sesión, cada agente, cada commit hereda las mismas restricciones. El humano aún evalúa la coherencia, aún ejecuta el loop de calidad, aún pregunta si el output merece enviarse. Pero ya no detecta violaciones de tamaño de fuente, colores hardcodeados o regresiones de CLS. El stack los detectó primero. La atención del humano se dirige enteramente a las preguntas que las máquinas no pueden responder.

FAQ

¿Necesito los seis componentes para empezar?

No. Empieza con el componente que aborde tu modo de falla más común. Los hooks tipográficos y los hooks del sistema de color ofrecen el mayor retorno porque detectan los defectos de diseño generados por agentes más frecuentes. Agrega los gates de Lighthouse y el linting de accesibilidad después. La regresión visual y la validación de layout son los componentes con mayor carga de infraestructura y pertenecen más adelante en la secuencia de adopción.

¿Funciona el stack con herramientas de build?

El stack funciona con cualquier arquitectura de frontend. El enfoque sin build simplifica la implementación porque no hay capa de transformación entre el código escrito y el enviado. Con herramientas de build, los hooks deben validar los archivos fuente mientras que Lighthouse y la regresión visual validan el output compilado. Los componentes siguen siendo los mismos. Los puntos de integración cambian.

¿Pueden los agentes aprender gusto sin el stack?

Los modelos de lenguaje actuales no tienen gusto. Los modelos producen output estadísticamente probable, y el output estadísticamente probable tiende hacia la mediana de los datos de entrenamiento. El stack no enseña gusto a los agentes. El stack restringe a los agentes para que el pipeline rechace output sin gusto antes de que se envíe. La distinción importa: codificar el gusto como infraestructura resulta más confiable que esperar que el modelo lo internalice desde el prompt.

¿Cómo manejan las pruebas de regresión visual los cambios intencionales?

Los cambios intencionales producen diffs visuales esperados. El flujo de trabajo señala los diffs, y el humano los revisa y aprueba, actualizando la línea base. El valor de la regresión visual no es prevenir el cambio sino exponer el cambio no intencional. Un agente que modifica el color de un botón también desplaza el layout de la tarjeta tres píxeles. El cambio de color es intencional, el desplazamiento de layout no, y la prueba de regresión visual detecta el efecto secundario.

Fuentes