Qué es realmente el drift
El drift no es que el agente le ignore, ni es un problema de calidad de una pantalla concreta. Normalmente, cada pantalla es correcta por sí sola. El fallo es *relacional*: la pantalla ocho discrepa de la pantalla uno en valores que deberían ser constantes.
Esa distinción es fundamental porque determina la solución. Un problema de calidad se soluciona con una mejor guía. Un problema de consistencia se soluciona con valores duraderos; por mucha sensibilidad estética que se tenga, dos juicios independientes no llegarán al mismo código hex.
Cada pantalla está bien. El producto, no. Esa brecha es el design drift en su totalidad.
Por qué empieza alrededor de la quinta pantalla
No hay nada mágico en el número cinco; la variable real es la longitud de la conversación más que el recuento de pantallas. Las sesiones largas generan contextos extensos, y el párrafo de estilos del principio compite con todo lo ocurrido desde entonces.
Lo que se degrada es específico y predecible. Los valores precisos son los primeros en caer, porque son cadenas arbitrarias sin anclaje semántico: oklch(0.55 0.19 45) es mucho más difícil de retener que *naranja cálido*. Así, el agente conserva el adjetivo, descarta el valor y vuelve a derivar un naranja cálido la próxima vez que lo necesite. Ese nuevo valor se convierte en la referencia para la siguiente pantalla.
- El espaciado y el radio son los primeros. Nadie los define en el brief, por lo que se derivan desde cero cada vez.
- La escala tipográfica es lo segundo. El tamaño base suele sobrevivir; la proporción entre niveles, no.
- El color de acento es lo último. Normalmente se menciona en el brief, lo que lo ancla; por eso mucha gente subestima el drift al comprobar solo el color.
- Las convenciones de layout apenas divergen, razón por la cual la app sigue pareciendo coherente aunque sus detalles discrepen.
Cambiar de herramienta elimina la fase gradual
Si pasa de Cursor a Claude Code a mitad de un proyecto, cada valor que no esté escrito en un archivo se reinicia al instante. La segunda herramienta no tiene acceso a la conversación de la primera, por lo que comienza con los valores por defecto; es por esto que el drift a menudo se manifiesta como una ruptura brusca en lugar de una pendiente.
Cómo medirlo
El drift es inusual entre las quejas de UI porque es sencillamente contabilizable. Elija los valores que deberían ser invariantes, tome muestras en sus pantallas más antigua y más reciente, y cuente las discrepancias.
- 1
Elija sus invariantes
Seis son suficientes: color primario, fondo de página, tamaño de fuente base, proporción de la escala tipográfica, radio de las tarjetas y el espacio estándar entre una etiqueta y su control.
- 2
Tome muestras de la primera pantalla
Utilice los estilos computados en lugar del código fuente para capturar lo que realmente se renderiza tras la cascada.
getComputedStyle(document.querySelector('[data-primary-action]')).backgroundColor - 3
Tome muestras de la última pantalla
Los mismos seis valores, del mismo modo.
- 4
Cuente las discrepancias
Ese recuento sobre seis es su puntuación de drift. Cero significa que los valores provienen de una fuente duradera; cuatro o más significa que se están decidiendo de nuevo en cada pantalla.
- 5
Repetir en una pantalla intermedia
Esto indica si la deriva es gradual o si se produjo una ruptura en un punto concreto, generalmente debido a un cambio de herramienta o a un intervalo largo entre sesiones.
| Deriva de diseño | Nunca especificado | |
|---|---|---|
| Cualquier pantalla individual | Consistentemente interno | Inconsistentemente interno |
| Primera pantalla frente a la última | Discrepan | Ambas discrepan consigo mismas |
| Causa | Los valores se degradaron por el contexto | Nunca existieron valores |
| Solución | Mover los valores a archivos | Definir el sistema primero |
Por qué las soluciones habituales decepcionan
- Reiterar la paleta cada pocos prompts. Funciona, pero ahora usted es la memoria, y olvidará las cosas antes que el agente.
- Un prompt de sistema muy largo. Ayuda al principio, pero luego contribuye a la presión del contexto que causa el problema.
- Pedir al agente que imite una pantalla existente. El agente debe inferir valores de un marcado que puede no tener en el contexto, y la inferencia introduce sus propios errores.
- Refactorizar al final. La opción más costosa: paga por construir la inconsistencia y luego paga de nuevo para eliminarla.
Las cuatro comparten un patrón. Intentan mantener los valores vivos dentro de la conversación, y las conversaciones son precisamente lo que se degrada.
La solución y por qué funciona
Mueva los invariantes fuera de la conversación y llévelos al repositorio: design tokens semánticos más un archivo DESIGN.md. El agente los lee al inicio de cada sesión, por lo que la pantalla veinte resuelve el mismo --primary que la pantalla uno, en lugar de uno similar.
El nombrado semántico cumple una función real aquí, más allá del orden. --primary y --muted-foreground describen roles, permitiendo que el agente los aplique correctamente en situaciones no previstas. Un valor hex puro debe recordarse *y* colocarse correctamente; un rol solo debe consultarse. Ese es el argumento a favor de una capa de tokens semánticos en lugar de una paleta.
- 1
Instalar el contrato
npx --yes identityforge@latest install --client claude-code - 2
Aplicar un kit
Escribe el archivo DESIGN.md y los design tokens de modo claro y oscuro en el repositorio.
identityforge apply quiet-matter - 3
Convertir la regla en una prohibición
Las prohibiciones se cumplen con más fiabilidad que las preferencias.
Never hardcode theme colors, spacing or radii. Use the tokens in DESIGN.md. - 4
Volver a medir
Ejecute de nuevo la diferencia de seis valores tras las siguientes dos pantallas. El resultado esperado es una puntuación de deriva de cero; si no lo es, algo se sigue decidiendo fuera de la capa de tokens.
¿Resuelve un sistema de diseño la deriva por sí solo?
En parte, y la parte que omite es la que más perjudica. Una librería de componentes soluciona la consistencia a nivel de componente: un Button es un Button en todas las pantallas. No hace nada respecto a los valores del tema que leen esos componentes, y ahí es donde reside realmente la deriva.
Existe una versión más aguda de este problema para los equipos que ya tienen un sistema. La pregunta más común sobre las habilidades de diseño y las herramientas de agentes es si un agente *respetará* un tema existente o si inventará uno discretamente en paralelo. La respuesta depende totalmente de si el tema existe como valores que el agente puede leer, o solo como una librería de Figma y un entendimiento compartido.
| Solucionado por una librería de componentes | Sigue derivando | |
|---|---|---|
| Internos del componente | Sí: un botón es un botón | — |
| Valores de tema que leen los componentes | No | Primary, background, radius, spacing |
| Composición entre componentes | No | Ritmo de sección, jerarquía, elección de rejilla |
| Cualquier cosa que la librería no cubra | No | Inventado por pantalla, de forma distinta cada vez |
El fallo que una librería de Figma no puede evitar
Si su sistema vive en Figma y en la cabeza de las personas, un agente de código no puede leerlo. Producirá componentes que parecen plausibles y utilizará valores que nadie eligió. Un sistema de diseño detiene el drift solo en la medida en que exista como texto en el repositorio.
¿El drift difiere entre Cursor, Claude Code, v0 y Lovable?
El mecanismo es el mismo en todas partes, porque se trata de una degradación del contexto y no de un defecto de ninguna herramienta en particular. Lo que varía es cuántos estados duraderos puede leer cada herramienta, y eso cambia el punto donde el drift impacta.
- Agentes basados en repositorio (Claude Code, Cursor). Pueden leer archivos, por lo que un
DESIGN.mdmás los tokens realmente soluciona el problema. Su debilidad es que nada los obliga a mirar, razón por la cual la instrucción debe figurar enAGENTS.mdcomo una prohibición. - Constructores basados en prompts (v0, Lovable, Bolt). Tienen menos repositorio del cual leer, por lo que gran parte de la identidad debe reiterarse. Pegue el bloque de tokens en lugar de describirlo.
- Cambiar entre cualquiera de ellos. Es la ruptura más brusca, ya que la segunda herramienta no tiene acceso a la conversación de la primera y comienza con los valores por defecto de la librería.
Por esto la solución es un archivo y no la elección de una herramienta. Un archivo es lo único que todos pueden consumir y lo único que sobrevive cuando usted cambia de opinión sobre cuál utilizar.
Donde el drift causa más daño: el modo oscuro
Analizamos 299 archivos DESIGN.md públicos de GitHub y medimos su contenido. De los 72 que describen un sistema de diseño visual, el 69% no contiene ningún modo oscuro: sin un segundo conjunto de valores, sin prefers-color-scheme, nada.
Esto es especialmente relevante aquí. Cuando un valor está ausente del estado duradero, el agente lo inventa, y los valores inventados son precisamente de lo que está hecho el drift. Un archivo que cubre totalmente el modo claro pero omite el oscuro no está protegido a medias; está totalmente protegido en un tema y completamente indefenso en el otro. Su puntuación de drift puede ser cero en modo claro y cuatro en modo oscuro.
Cuando ejecute el diff de seis valores, hágalo dos veces: una por cada tema. El modo oscuro es donde las cifras suelen divergir, y es la medición que la gente omite porque las pantallas en modo claro se ven bien.
Lo que conviene notar es lo *razonable* que parece el lado con drift de forma aislada. El drift nunca es obviamente erróneo a nivel de componente; solo es visible cuando se ponen dos pantallas una junto a la otra, que es precisamente la comparación que nadie hace durante una compilación.
Deje de pagar por el drift dos veces
Instale un kit antes de la siguiente pantalla en lugar de refactorizar después de la vigésima. Tokens, DESIGN.md y un elemento del registro de shadcn/ui, en un solo comando. Los kits gratuitos no requieren cuenta.
¿Es el drift una señal de que elegí el modelo equivocado?
No. Aparece en todos los agentes porque la causa es la degradación del contexto y no la capacidad. Un modelo más potente mantiene los valores un poco más de tiempo y luego sufre drift de la misma manera.
¿Puedo evitarlo manteniendo las sesiones cortas?
Ayuda dentro de una misma sesión, pero empeora el problema entre sesiones. Cada sesión nueva comienza con los valores predeterminados, por lo que las sesiones cortas sin valores persistentes generan rupturas más bruscas y frecuentes.
¿Resuelve esto una librería de componentes?
En parte. Soluciona la consistencia a nivel de componente, ya que un Button es siempre un Button. Sin embargo, no soluciona los valores del tema que leen dichos componentes, que es donde realmente reside el drift.
Mi puntuación de drift es cero, pero la aplicación sigue pareciendo inconsistente. ¿Y ahora qué?
Entonces se trata del otro modo de fallo: los valores son estables, pero el sistema es insuficiente. Revise la jerarquía, el ritmo del espaciado dentro de una pantalla y si una sola familia tipográfica está asumiendo todas las funciones.
¿Con qué frecuencia debo volver a medir?
Después de cambiar de herramienta, tras cualquier interrupción de más de unos pocos días y antes del despliegue. Esos son los tres puntos donde es más probable que los valores no documentados se hayan restablecido.