O que é OKLCH e por que usar em vez de RGB ou HSL?

OKLCH é um espaço de cor que representa luminosidade, croma e matiz da forma como o olho humano percebe — diferente de RGB e HSL que são modelos matemáticos. Ele gera gradientes mais suaves, evita faixas estranhas no meio do degradê e mantém contraste previsível entre cores. No design com IA, especificar cores em OKLCH em vez de hex codes reduz drasticamente combinações berrantes.

Como funciona o TDD visual com Playwright e Visly?

Primeiro você cria os arquivos CLAUDE.md e DESIGN.md com anti-padrões explícitos. Depois, pede ao agente para escrever testes ANTES de implementar a UI — os anti-padrões viram casos de teste, regras de cor viram asserções. A Visly Test CLI sobe um servidor local que recebe screenshots via Playwright e mostra diffs pixel a pixel com metadados. Você aprova ou rejeita cada diff; cada rejeição vira feedback para o agente ajustar na próxima iteração.

Quais fontes evitar no design gerado por IA?

Inter e Geist são as principais — todo agente de IA pula nelas por padrão e já viraram marca registrada de AI slop. Chamá-las explicitamente como banidas no prompt força o modelo a explorar alternativas tipográficas que não entregam a origem do design de imediato.

Vale a pena usar TDD visual em projetos pequenos?

Depende do seu nível de tolerância a inconsistência visual. Em projetos com mais de 3 páginas, o DESIGN.md sozinho já evita o problema clássico de "landing page linda, dashboard quebrada". O TDD visual com Visly faz mais sentido quando você está iterando design com agente frequentemente e quer feedback quantificável em vez de ficar caçando diferença no olho.

Os 3 Níveis de Design com IA que Separam Designs Genéricos de Trabalhos Profissionais

Q: Qual a diferença entre CLAUDE.md e DESIGN.md?

CLAUDE.md contém apenas informações do projeto: stack, convenções, arquitetura, regras de negócio. DESIGN.md é o sistema visual completo: cores em OKLCH, escala tipográfica, regras de espaçamento, comportamento responsivo e anti-padrões. Separar os dois evita que o agente se distraia com detalhes visuais enquanto resolve lógica, e mantém cada arquivo focado na sua responsabilidade.

Tem uma coisa que me intriga há meses testando Claude Code, Cursor e outros agentes: por que o mesmo modelo consegue gerar um design que parece feito sob medida e, cinco minutos depois, entrega algo que grita "fui gerado por IA"? O canal AI LABS destrinchou exatamente isso no vídeo The Third Level Actually Separates Your AI Design From The Rest e a resposta está em três níveis que vão do prompt engineering ao TDD visual. Nenhum deles é óbvio — e o terceiro é coisa de quem já cansou de refatorar UI na mão.

Nível 1: Prompt Engineering que de fato muda o output visual

O primeiro nível é o que quase todo mundo ensina: criar um design bom para uma página única. Mas o que quase ninguém fala é que tem uma estrutura de prompt que separa o resultado genérico do personalizado. Não é sobre escrever mais — é sobre a ordem certa das instruções.

A estrutura que o AI LABS recomenda segue esta sequência exata: (1) intenção do site, (2) non-negotiables — os elementos que precisam estar lá sim ou sim, (3) como os elementos de UI devem se comportar, (4) sistema de cores em OKLCH, (5) fluxos de contraste, (6) tipografia, (7) layout e ritmo com definição de simetria ou assimetria, (8) anti-padrões explícitos para evitar.

OKLCH em vez de RGB ou HSL é provavelmente a decisão mais subestimada dessa lista. Diferente dos hex codes que a gente usa por hábito, o OKLCH representa cor do jeito que o olho humano percebe — luminosidade, croma e matiz. Isso significa gradientes mais suaves e balanço de contraste mais previsível. Hex code aleatório produz degradê com faixa estranha no meio; OKLCH não.

Sobre tipografia: fonts como Inter e Geist viraram marcas registradas de AI slop. TODO agente pula nelas por padrão. Chamá-las explicitamente como banidas no prompt força o modelo a explorar alternativas. Na minha experiência, isso sozinho já tira aquele cheiro de "template do v0" do output.

E os anti-padrões: CTA centralizado genérico, ícones Lucid, glassmorfismo com gradiente — mencionar cada um pelo nome ensina o modelo o que NÃO fazer. O Claude Opus 4.7 já reduziu bastante o slop visual comparado com versões anteriores, mas ele ainda converge para padrões seguros se você não empurrar na direção contrária.

Nível 2: Do design de uma página ao sistema completo

Se o Nível 1 é sobre uma página, o Nível 2 é sobre o sistema inteiro. E aqui mora o problema mais comum de app gerado por agente: a landing page fica linda, mas quando você clica em qualquer outra rota — dashboard, auth, settings — parece que o agente esqueceu que estava construindo o mesmo app. Botões com padding diferente, tipografia inconsistente, espaçamento que não segue grade nenhuma.

A solução são dois arquivos que atuam como fonte da verdade: CLAUDE.md e DESIGN.md. O primeiro carrega só informações do projeto — stack, convenções, arquitetura. O segundo é o sistema visual completo: cores em OKLCH, escala tipográfica, regras de espaçamento, comportamento responsivo, anti-padrões. Separar os dois é crucial: se você joga tudo no CLAUDE.md, o agente se distrai com detalhe visual enquanto está resolvendo lógica de negócio.

Um detalhe que eu não tinha pensado antes: o DESIGN.md precisa ser auto-evolutivo. Você coloca uma instrução no topo dizendo para o agente adicionar qualquer novo valor de design que ele descobrir durante a sessão. Assim, cada interação parte de uma versão mais refinada que a anterior. É um acumulador de conhecimento visual.

O Google abriu um template oficial de DESIGN.md com comandos de cross-verification — você roda e ele aponta o que está fora das melhores práticas. Fora isso, existem skills open-source que auditam o design contra princípios estabelecidos. O AI LABS menciona a skill design-principles da Vercel, que referencia uma fonte externa mantida ativamente — então os princípios não congelam na data em que a skill foi escrita. Sobre CLAUDE.md, já escrevi um guia completo com 13 práticas essenciais para configurar o CLAUDE.md que complementa bem esse nível.

Nível 3: TDD Visual — testando design como se fosse código

Esse é o nível que eu nunca tinha visto aplicado a design. A ideia é simples: se TDD funciona para código — escrever o teste antes, fazer a implementação passar — por que não funcionaria para interface?

A chave está em transformar os anti-padrões do DESIGN.md em casos de teste programáticos. Cada regra de cor vira uma asserção. Cada restrição de espaçamento vira um check. Cada escolha tipográfica vira uma verificação. O agente escreve esses testes antes de implementar a UI — se escrever depois, ele otimiza os testes pra caber no código que já existe. O resultado é o equivalente visual de um test suite que pega regressão.

Os testes se dividem em duas categorias: (1) estáticos — checam diretamente os anti-padrões listados no prompt (ex: "existe glassmorfismo em algum componente?"), e (2) visuais — usam Playwright para screenshot e regressão, comparando o estado atual com a referência aprovada.

A ferramenta que fecha esse loop é a Visly Test CLI. Diferente de comparar screenshots no olho ("será que mudou alguma coisa?"), a Visly mostra exatamente quais pixels mudaram e por quanto — com metadados. Você sobe um servidor local, o Claude Code implementa a UI, tira screenshots via Playwright com nome "Visly" e empurra pro viewer. Dali você aprova ou rejeita cada diff. Cada rejeição vira feedback que o agente usa na próxima iteração. Em poucos ciclos, o design converge para o que você realmente quer — não para o que o agente acha que você quer.

Por que isso muda o jogo para devs

Na minha visão, o que esses três níveis realmente entregam não é "design bonito" — é previsibilidade. Três pontos que resumem o valor prático:

(1) O prompt estruturado do Nível 1 elimina a loteria. Você não está torcendo para o modelo acertar o estilo — está dando a ele uma especificação visual tão precisa quanto uma spec de API. OKLCH, contraste, tipografia banida, simetria definida — cada parâmetro reduz o espaço de surpresa.

(2) CLAUDE.md + DESIGN.md resolvem o problema de consistência que mata a credibilidade de qualquer app gerado por agente. Um design system documentado e auto-evolutivo significa que a página 5 não parece que foi feita por outra pessoa.

(3) O TDD visual fecha o ciclo que sempre faltou: feedback quantificável. Você não precisa mais argumentar "achei estranho" numa review de PR — o diff de pixels com metadados diz objetivamente o que mudou. E o ciclo rejeita→feedback→ajuste faz o design convergir sem você precisar mexer no CSS.

Conclusão

Os três níveis formam uma progressão natural: você começa acertando o prompt de uma página, escala para um sistema de design que sobrevive a múltiplas rotas, e eventualmente escreve testes que provam que o design está certo — do mesmo jeito que você provaria que uma função retorna o valor esperado.

O vídeo completo do AI LABS — com os prompts exatos usados em cada nível — está disponível em The Third Level Actually Separates Your AI Design From The Rest. Se você está gerando UI com Claude Code ou qualquer outro agente, esses 11 minutos valem mais que qualquer curso de 4 horas sobre design.