O que o drift realmente é
Drift não é o agente ignorando você, nem um problema de qualidade em qualquer tela individual. Cada tela geralmente está correta por si só. A falha é *relacional*: a tela oito diverge da tela um em valores que deveriam ser constantes.
Essa distinção importa porque ela define a solução. Um problema de qualidade é resolvido com melhor orientação. Um problema de consistência é resolvido com valores duráveis — nenhuma quantidade de bom gosto adicional fará com que dois julgamentos independentes cheguem ao mesmo hex.
Cada tela está ótima. O produto não. Esse gap é a totalidade do design drift.
Por que começa por volta da quinta tela
Não há nada de mágico no número cinco; a variável real é a duração da conversa, e não a contagem de telas. Sessões longas criam contextos longos, e seu parágrafo de estilização do início está competindo com tudo o que veio depois.
O que se degrada é específico e previsível. Valores precisos somem primeiro, pois são strings arbitrárias sem âncora semântica: oklch(0.55 0.19 45) é muito mais difícil de reter do que *laranja quente*. Então o agente mantém o adjetivo, descarta o valor e rederiva um laranja quente quando precisar de um novamente. Esse novo valor torna-se a referência para a tela seguinte.
- Espaçamento e raio vêm primeiro. Ninguém os nomeia no brief, então eles são rederivados do zero a cada vez.
- Escala tipográfica vem em segundo. O tamanho base tende a sobreviver; a proporção entre os níveis, não.
- Cor de destaque vem por último. Ela geralmente é mencionada no brief, o que a ancora — é por isso que as pessoas subestimam o drift ao checar apenas a cor.
- Convenções de layout quase não sofrem drift, e é por isso que o app ainda parece coerente enquanto seus detalhes divergem.
A troca de ferramenta pula a parte gradual
Mude do Cursor para o Claude Code no meio do projeto e cada valor não escrito em um arquivo é resetado instantaneamente. A segunda ferramenta não tem acesso à conversa da primeira, então ela começa com os padrões — é por isso que o drift frequentemente aparece como uma ruptura súbita, e não como uma inclinação.
Medindo o drift
O drift é incomum entre as reclamações de UI por ser straightforwardmente contável. Escolha os valores que deveriam ser invariantes, colete amostras nas telas mais antiga e mais recente e conte as divergências.
- 1
Escolha seus invariantes
Seis são suficientes: cor primária, fundo da página, tamanho da fonte base, proporção da escala tipográfica, raio do card e o gap padrão entre um label e seu controle.
- 2
Amostre a tela mais antiga
Use estilos computados em vez da fonte, para capturar o que realmente é renderizado após a cascata.
getComputedStyle(document.querySelector('[data-primary-action]')).backgroundColor - 3
Amostre a tela mais recente
Os mesmos seis valores, da mesma maneira.
- 4
Conte as divergências
Essa contagem sobre seis é a sua pontuação de drift. Zero significa que os valores vêm de algum lugar durável; quatro ou mais significa que eles estão sendo redecididos a cada tela.
- 5
Repetir em uma tela intermediária
Isso indica se o drift é gradual ou se ocorreu uma quebra em um ponto específico — geralmente devido à troca de ferramenta ou a um longo intervalo entre sessões.
| Design drift | Nunca especificado | |
|---|---|---|
| Qualquer tela individual | Internamente consistente | Internamente inconsistente |
| Primeira vs última tela | Discordar | Ambos discordam de si mesmos |
| Causa | Valores degradados pelo contexto | Nunca existiram valores |
| Correção | Mover valores para arquivos | Definir o sistema primeiro |
Por que as soluções paliativas habituais decepcionam
- Reafirmar a paleta a cada poucos prompts. Funciona, mas agora você é a memória, e você esquecerá antes do agente.
- Um prompt de sistema muito longo. Ajuda no início, mas depois contribui para a pressão de contexto que causa o problema.
- Pedir ao agente para corresponder a uma tela existente. Ele precisa inferir valores de um markup que pode não estar no contexto, e a inferência introduz seu próprio erro.
- Refatoração ao final. A opção mais cara: você paga para construir a inconsistência e depois paga novamente para removê-la.
Todos os quatro compartilham um padrão. Eles tentam manter os valores vivos dentro da conversa, e as conversas são o que sofre degradação.
A solução, e por que ela funciona
Mova os invariantes para fora da conversa e para o repositório: design tokens semânticos mais um DESIGN.md. O agente os lê no início de cada sessão, de modo que a tela vinte resolva o mesmo --primary da tela um, em vez de um valor aproximado.
A nomenclatura semântica está realizando um trabalho real aqui, além da organização. --primary e --muted-foreground descrevem funções, permitindo que o agente as aplique corretamente em situações que ninguém antecipou. Um hex bruto precisa ser memorizado *e* posicionado corretamente; uma função só precisa ser consultada. Esse é o argumento para uma camada de design tokens semânticos em vez de uma paleta.
- 1
Instalar o contrato
npx --yes identityforge@latest install --client claude-code - 2
Aplicar um kit
Grava o arquivo DESIGN.md e os tokens de temas claro e escuro no repositório.
identityforge apply quiet-matter - 3
Transformar a regra em uma proibição
Proibições são seguidas de forma mais confiável do que preferências.
Never hardcode theme colors, spacing or radii. Use the tokens in DESIGN.md. - 4
Remedir
Execute o diff de seis valores novamente após as próximas duas telas. Um score de drift zero é o resultado esperado e, se não for, algo ainda está sendo decidido fora da camada de tokens.
Um design system resolve o drift por conta própria?
Parcialmente, e a parte que ele não resolve é a que mais machuca. Uma biblioteca de componentes resolve a consistência ao nível de componente: um Button é um Button em todas as telas. Ela não faz nada em relação aos valores de tema que esses componentes leem, e é aí que o drift realmente reside.
Existe uma versão mais aguda desse problema para equipes que já possuem um sistema. A pergunta mais comum sobre habilidades de design e ferramentas de agentes é se um agente irá *respeitar* um tema existente ou se irá inventar algo silenciosamente ao lado dele. A resposta depende inteiramente de o tema existir como valores que o agente possa ler, ou apenas como uma biblioteca no Figma e um entendimento compartilhado.
| Corrigido por uma biblioteca de componentes | Ainda apresenta drift | |
|---|---|---|
| Internos do componente | Sim — um Button é um Button | — |
| Valores de tema que os componentes leem | Não | Primary, background, radius, spacing |
| Composição entre componentes | Não | Ritmo de seção, hierarquia, escolhas de grid |
| Qualquer coisa que a biblioteca não cubra | Não | Inventado por tela, de forma diferente a cada vez |
A falha que uma biblioteca do Figma não consegue evitar
Se o seu sistema vive no Figma e na cabeça das pessoas, um agente de código não consegue lê-lo. Ele produzirá componentes que parecem plausíveis e usará valores que ninguém escolheu. Um design system interrompe o drift apenas na medida em que existe como texto no repositório.
O drift difere entre Cursor, Claude Code, v0 e Lovable?
O mecanismo é o mesmo em todos, pois trata-se de decaimento de contexto e não de um defeito de qualquer ferramenta específica. O que difere é a quantidade de estado durável que cada ferramenta consegue ler, e isso altera onde o drift começa a impactar.
- Agentes baseados em repositório (Claude Code, Cursor). Eles conseguem ler arquivos, então um
DESIGN.mdsomado aos tokens realmente resolve o problema. A fraqueza deles é que nada os obriga a olhar, e é por isso que a instrução deve estar noAGENTS.mdcomo uma proibição. - Builders baseados em prompt (v0, Lovable, Bolt). Têm menos repositório para ler, então mais da identidade precisa ser reafirmada. Cole o bloco de tokens em vez de descrevê-lo.
- Alternar entre qualquer dois deles. A ruptura mais brusca, pois a segunda ferramenta não tem acesso à conversa da primeira e começa com os padrões da biblioteca.
É por isso que a solução é um arquivo, e não a escolha de uma ferramenta. Um arquivo é a única coisa que todos eles conseguem consumir e a única coisa que sobrevive quando você muda de ideia sobre qual usar.
Onde o drift causa mais danos: dark mode
Amostramos 299 arquivos DESIGN.md públicos do GitHub e medimos o que havia neles. Dos 72 que descrevem um design system visual, 69% não contêm dark mode — nenhum segundo conjunto de valores, nenhum prefers-color-scheme, nada.
Isso é especificamente relevante aqui. Onde um valor está ausente do estado durável, o agente o inventa, e valores inventados são exatamente do que o drift é feito. Um arquivo que cobre totalmente o light mode e omite o dark mode não está metade protegido; ele está totalmente protegido em um tema e completamente indefeso no outro. Seu score de drift pode ser zero no light mode e quatro no dark.
Quando executar o diff de seis valores, execute-o duas vezes — uma para cada tema. O dark mode é onde os números geralmente divergem, e é a medição que as pessoas ignoram porque as telas em light mode parecem corretas.
O que vale notar é o quão *razoável* o lado com drift parece isoladamente. O drift nunca é obviamente errado no nível do componente; ele só é visível quando duas telas são colocadas lado a lado, que é precisamente a comparação que ninguém faz durante um build.
Pare de pagar pelo drift duas vezes
Instale um kit antes da próxima tela em vez de refatorar após a vigésima. Tokens, DESIGN.md e um item de registro do shadcn, em um único comando. Kits gratuitos não exigem conta.
O drift é um sinal de que escolhi o modelo errado?
Não. Ele aparece em todos os agentes porque a causa é o decaimento de contexto, e não a capacidade. Um modelo mais forte mantém os valores por um pouco mais de tempo e depois sofre drift da mesma maneira.
Posso evitar isso mantendo as sessões curtas?
Isso ajuda dentro de uma única sessão, mas piora o problema entre sessões. Cada nova sessão começa com os valores padrão; portanto, sessões curtas sem valores duráveis resultam em rupturas mais bruscas e frequentes.
Uma biblioteca de componentes resolve isso?
Em parte. Ela resolve a consistência no nível do componente, já que um Button será sempre um Button. No entanto, ela não resolve os valores de tema que esses componentes consomem, que é onde o drift realmente acontece.
Meu score de drift é zero, mas o app ainda parece inconsistente. E agora?
Nesse caso, você está lidando com outro modo de falha: os valores estão estáveis, mas o sistema é superficial. Analise a hierarquia, o ritmo de espaçamento dentro de uma tela e se uma única família tipográfica está sendo usada para todas as funções.
Com que frequência devo medir novamente?
Após a troca de qualquer ferramenta, após qualquer intervalo superior a alguns dias e antes do deploy. Esses são os três momentos em que os valores não documentados têm maior probabilidade de terem sido resetados.