O que o drift realmente é
Drift não é o agente ignorando você e não é um problema de qualidade em qualquer tela individual. Cada tela geralmente está ótima por si só. A falha é *relacional*: a tela oito discorda da tela um sobre 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 faz 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, porque 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 todas as vezes.
- 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 de uma vez. 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 quebra súbita em vez de uma inclinação.
Medindo o drift
O drift é incomum entre as reclamações de UI por ser straightforwardly contabilizável. Escolha os valores que deveriam ser invariantes, colete amostras em suas 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 de 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
Repita em uma tela intermediária
Isso indica se o drift é gradual ou se ocorreu 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 | Discordam | Ambas discordam de si mesmas |
| Causa | Valores degradados pelo contexto | Valores nunca existiram |
| Correção | Mover valores para arquivos | Definir o sistema primeiro |
Por que as soluções paliativas comuns decepcionam
- Reiterar a paleta a cada poucos prompts. Funciona, mas agora você é a memória, e você esquecerá antes do agente.
- Um system prompt muito longo. Ajuda no início, mas depois contribui para a pressão de contexto que causa o problema.
- Pedir ao agente para combinar com uma tela existente. Ele precisa inferir valores de marcações que podem não estar no contexto, e a inferência introduz seu próprio erro.
- Refatorar ao final. A opção mais cara: você paga para construir a inconsistência e depois paga novamente para removê-la.
Todas as quatro compartilham a mesma lógica. Elas tentam manter os valores vivos dentro da conversa, e conversas são a coisa que mais degrada.
A correção e por que ela funciona
Mova os invariantes para fora da conversa e para dentro do repositório: design tokens semânticos mais um DESIGN.md. O agente os lê no início de cada sessão, portanto, a tela vinte resolve o mesmo --primary que a tela um, em vez de um valor aproximado.
A nomenclatura semântica desempenha um papel fundamental aqui, além da organização. --primary e --muted-foreground descrevem funções, permitindo que o agente as aplique corretamente em situações imprevistas. Um hex puro precisa ser lembrado *e* posicionado corretamente; uma função precisa apenas ser consultada. Esse é o argumento a favor de uma camada de tokens semânticos em vez de apenas uma paleta.
- 1
Instalar o contrato
npx --yes identityforge@latest install --client claude-code - 2
Aplicar um kit
Grava o DESIGN.md e os tokens de light e dark mode no repositório.
identityforge apply quiet-matter - 3
Transformar a regra em uma proibição
Proibições são seguidas com mais rigor 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; 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 prejudica. Uma biblioteca de componentes resolve a consistência no nível do 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 crítica deste 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 inventar 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 sofre 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 degradação 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 repo (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 ferramenta 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.
Ao 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 pulam 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 é a degradação do 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 persistentes geram rupturas mais bruscas com maior frequência.
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?
Então 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.