Qué es realmente el drift
El drift no es que el agente te ignore ni es un problema de calidad en una pantalla individual. Cada pantalla suele estar bien por sí sola. El fallo es *relacional*: la octava pantalla no coincide con la primera en valores que deberían ser constantes.
Esa distinción es importante 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: ninguna cantidad de criterio adicional hará que dos juicios independientes coincidan en el mismo hex.
Cada pantalla está bien. El producto no. Ese desfase es la esencia del design drift.
Por qué comienza alrededor de la quinta pantalla
No hay nada de mágico en el número cinco; la variable real es la duración de la conversación más que el número de pantallas. Las sesiones largas generan un contexto largo, y tu párrafo de estilos del principio compite con todo lo que ha ocurrido desde entonces.
Lo que se degrada es específico y predecible. Los valores precisos son los primeros en fallar, porque son cadenas arbitrarias sin un anclaje semántico: oklch(0.55 0.19 45) es mucho más difícil de retener que *naranja cálido*. Así que el agente mantiene el adjetivo, descarta el valor y vuelve a derivar un naranja cálido cuando lo necesita de nuevo. Ese nuevo valor se convierte en la referencia para la siguiente pantalla.
- El espaciado y el radio fallan primero. Nadie los nombra en el brief, así que se vuelven a derivar desde cero cada vez.
- La escala tipográfica es la segunda. El tamaño base tiende a sobrevivir; la proporción entre los pasos, no.
- El color de acento es el último. Suele mencionarse en el brief, lo que lo ancla. Por eso la gente subestima el drift al limitarse a comprobar el color.
- Las convenciones de layout apenas presentan drift, razón por la cual la app sigue pareciendo coherente mientras sus detalles discrepan.
Cambiar de herramienta se salta la parte gradual
Si pasas de Cursor a Claude Code a mitad de un proyecto, todos los valores que no se hayan escrito en un archivo se reinician de golpe. La segunda herramienta no tiene acceso a la conversación de la primera, por lo que empieza desde los valores por defecto; por eso el drift suele aparecer como una ruptura repentina en lugar de una pendiente gradual.
Cómo medirlo
El drift es inusual entre las quejas de UI por ser directamente cuantificable. Selecciona los valores que deberían ser invariantes, tómales una muestra en tus primeras y últimas pantallas, y cuenta los desacuerdos.
- 1
Elige tus 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
Toma una muestra de la primera pantalla
Usa los estilos computados en lugar de los de origen, para capturar lo que realmente se renderiza tras la cascada.
getComputedStyle(document.querySelector('[data-primary-action]')).backgroundColor - 3
Toma una muestra de la última pantalla
Los mismos seis valores, de la misma manera.
- 4
Cuenta los desacuerdos
Ese recuento sobre seis es tu puntuación de drift. Cero significa que los valores provienen de algún lugar duradero; cuatro o más significa que se están redecidiendo en cada pantalla.
- 5
Repetir en una pantalla intermedia
Esto indica si el drift es gradual o si se produjo una ruptura en un punto concreto, generalmente por un cambio de herramienta o un intervalo largo entre sesiones.
| Design drift | 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 system prompt 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: 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 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 drift de cero; si no lo es, algo se sigue decidiendo fuera de la capa de tokens.
¿Resuelve un sistema de diseño el drift por sí solo?
En parte, y la parte que omite es la que más afecta. Una librería de componentes soluciona la consistencia a nivel de componente: un Button es un Button en todas las pantallas. Pero no hace nada respecto a los valores del tema que leen esos componentes, y ahí es donde reside realmente el drift.
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 sufriendo drift | |
|---|---|---|
| Internos del componente | Sí. Un Button es un Button | — |
| Valores de tema que leen los componentes | No | Primary, background, radius, spacing |
| Composición entre componentes | No | Ritmo de sección, jerarquía, elecciones de cuadrícula |
| 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 prevenir
Si su sistema reside en Figma y en la cabeza de las personas, un agente de código no puede leerlo. Producirá componentes que parezcan plausibles y utilicen valores que nadie ha elegido. Un sistema de diseño detiene el drift solo en la medida en que exista como texto en el repositorio.
¿Difiere el drift entre Cursor, Claude Code, v0 y Lovable?
El mecanismo es el mismo en todas partes, porque se trata de un deterioro del contexto más que de un defecto en una herramienta concreta. Lo que varía es la cantidad de estado duradero que cada herramienta puede leer, y eso cambia el punto donde el drift hace daño.
- Agentes basados en repo (Claude Code, Cursor). Pueden leer archivos, por lo que un
DESIGN.mdmás los tokens lo solucionan de verdad. Su debilidad es que nada les obliga a mirar, razón por la cual la instrucción debe figurar enAGENTS.mdcomo una prohibición. - Constructores basados en prompt (v0, Lovable, Bolt). Tienen menos repositorio que leer, por lo que hay que reiterar más parte de la identidad. Pegue el bloque de tokens en lugar de describirlo.
- Cambiar entre cualquiera de ellos. La ruptura más brusca, porque la segunda herramienta no tiene acceso a la conversación de la primera y comienza desde los valores predeterminados de la librería.
Por esto la solución es un archivo y no una elección de 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: dark mode
Analizamos 299 archivos DESIGN.md públicos de GitHub y medimos lo que contenían. De los 72 que describen un sistema de diseño visual, el 69% no contiene ningún dark mode. Sin un segundo conjunto de valores, sin prefers-color-scheme, nada.
Eso es crucial específicamente aquí. Cuando un valor está ausente del estado duradero, el agente lo inventa, y los valores inventados son precisamente de lo que se compone el drift. Un archivo que cubra totalmente el light mode y omita el dark mode no está protegido a medias; está totalmente protegido en un tema y completamente desprotegido en el otro. Su puntuación de drift puede ser cero en light mode y cuatro en dark.
Cuando ejecute el diff de seis valores, ejecútelo dos veces: una por cada tema. El dark mode es donde los números suelen distanciarse, y es la medición que la gente omite porque las pantallas en light mode se ven bien.
Lo que merece la pena notar es lo *razonable* que parece el lado que sufre el drift cuando se ve de forma aislada. El drift nunca es obviamente erróneo a nivel de componente; solo es visible cuando se colocan dos pantallas una al lado de la otra, que es precisamente la comparación que nadie hace durante una build.
Deje de pagar 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 de registro de shadcn, 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 el deterioro del contexto y no la capacidad. Un modelo más potente mantiene los valores un poco más de tiempo y luego deriva de la misma manera.
¿Puedo evitarlo manteniendo las sesiones cortas?
Ayuda dentro de una misma sesión, pero agrava el problema entre sesiones. Cada sesión nueva comienza con los valores predeterminados, por lo que las sesiones cortas sin valores persistentes provocan 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.