Vibe coding para designers: a parte que decide se funciona

A experiência comum é que as duas primeiras telas são surpreendentes e a décima é uma bagunça. Isso não é o modelo piorando. É que nada no projeto definiu como a coisa deveria parecer, então cada turno decide novamente: um espaçamento ligeiramente diferente aqui, um cinza novo ali, um novo destaque quando o anterior "parecia um pouco flat".

Profissionais que entregam consistentemente descrevem o mesmo hábito: esboçam o scaffolding primeiro (tema, grid, tipografia, cor) e só então começam a pedir funcionalidades. Essa ordem é toda a diferença, e é a parte que é ignorada porque criar prompts é mais divertido.

1. 1

   Coloque um conjunto de tokens no projeto

   Papéis de cores nomeados para light e dark, uma escala tipográfica, espaçamentos, raios. Não uma paleta: papéis, para que a resposta para "qual a cor de um botão desativado" exista antes que qualquer coisa precise dela. Um comando instala um conjunto completo se você preferir não montá-lo: npx shadcn add https://identityforge.io/r/ambient-sage.json.

2. 2

   Escreva um arquivo de regras que proíba coisas

   Seja qual for a ferramenta que você usa: .cursor/rules/design.mdc, .devin/rules/design.md, uma linha no CLAUDE.md. Mantenha como política, não como gosto: use apenas os tokens semânticos, nunca um hex puro, nenhum segundo destaque em uma tela, nunca entregue uma alteração no light sem a contraparte no dark, e pergunte em vez de inventar quando o sistema for omisso.

3. 3

   Tenha um preview rodando antes de construir qualquer coisa

   Você é designer; você revisa olhando. Se você não consegue ver a mudança aplicada, você está revisando código, que é a única coisa para a qual você não está preparado.

4. 4

   Faça o primeiro commit

   Antes da primeira funcionalidade. Este é o seu baseline e, a partir daqui, cada prompt é reversível. O git é o botão de undo. O do chat não é.

O arquivo de regras importa mais do que parece, e especificamente as proibições. Uma preferência adiciona uma opção; uma proibição remove todas as outras. "Use nosso verde" deixa qualquer padrão genérico ainda legal. "Nunca introduza uma cor que não seja um token" não deixa. Analisamos 299 documentos de design públicos escritos exatamente para esse propósito e 76% listavam apenas preferências, o que é a descrição precisa de por que eles param de funcionar por volta da quinta tela.

O problema autoinfligido mais comum é pedir demais de uma vez. Um prompt que produz um diff de quarenta arquivos é um diff que ninguém lê, o que significa que o desvio entrou sem revisão e você o encontrará mais tarde como "por que esta página parece diferente".

• Uma tela ou um componente por turno. Olhe, faça o commit, siga em frente.
• Faça commit antes de cada prompt, não depois. Assim, o estado anterior correto está sempre a um comando de distância e você nunca precisa decidir se a última alteração valeu a pena enquanto tenta corrigi-la.
• Diga o que não deve ser tocado. "Altere apenas este componente" evita aquela refatoração "prestativa" em três arquivos que você já havia aprovado.
• Quando as coisas derem errado, reverta em vez de negociar. Três rodadas de "não, não é assim" resultam em um remendo que satisfaz a conversa, mas não o design. Volte para o último commit estável e peça novamente com um prompt melhor.

Esta é a habilidade que vale a pena aprender, e é basicamente uma habilidade de revisão de design com a "roupa" do git. Você não está verificando se o código é bom. Você está verificando quatro coisas, e todas as quatro são visíveis sem entender uma única linha de lógica.

Essas quatro verificações levam cerca de um minuto por diff e pegam a maioria das causas de drift. Todo o resto (se o gerenciamento de estado é sensato, se a query é eficiente) genuinamente não é seu trabalho nesta etapa, e fingir o contrário é o que faz os designers evitarem a revisão completamente.

• Aceitação condescendente. Se você perguntar "isso está seguindo o design system?", geralmente ouvirá que sim. Em vez disso, pergunte "liste cada valor de cor neste arquivo que não seja um token": uma pergunta com uma resposta verificável.
• Hardcoding para fazer funcionar. Um valor colado no lugar de uma busca torna a tela correta, mas o sistema errado. Isso aparece na primeira vez que você altera um token e um componente não se move.
• Remendar o resultado em vez de corrigir a causa. Uma margem adicionada para compensar um layout que estava errado dois componentes acima. Cada remendo é pequeno; o décimo é o motivo pelo qual nada pode ser alterado com segurança.
• Melhorar o sistema no meio da tarefa. Uma nova cor introduzida "para dar contraste". Isso é drift com uma justificativa anexa, e é o tipo mais difícil de detectar porque o raciocínio faz sentido.
• Passar no teste errado. Renderizou, então funciona. Verifique o modo escuro, um estado vazio e uma string longa em uma coluna estreita antes de acreditar.

Menos do que os cursos sugerem e mais do que zero. Felizmente, a quantidade necessária é específica, não geral.

• Ler um diff. Verde adicionado, vermelho removido e as quatro verificações acima. Uma tarde.
• Git básico. Commit, visualizar log, reverter para um commit. Meia hora, e é a meia hora de maior retorno disponível.
• Onde as coisas ficam. Qual arquivo é o tema, qual é um componente, qual é uma página. Peça ao agente para explicar a estrutura uma vez. Ele é bom nisso.
• Ler um erro. Não corrigi-lo. Ser capaz de colar a parte relevante em vez de um screenshot de todo o terminal.

O que você não precisa é escrever React, entender ferramentas de build ou gerenciar dependências. É exatamente para isso que o agente serve, e o tempo gasto aprendendo isso é tempo não gasto na habilidade de revisão, que nada mais pode fazer por você.

Vibe coding é excepcional para protótipos, ferramentas internas, sites de marketing e para provar que uma interação vale a pena ser construída. É genuinamente arriscado nos limites onde um erro não é visual: autenticação, pagamentos, qualquer coisa que toque em dados de clientes, qualquer coisa com migração. Essas falhas não aparecem no preview, que é o único canal de revisão que você tem.

Uma regra útil: se o pior resultado de estar errado é que fique feio, publique e itere. Se o pior resultado é que os dados ou o dinheiro de outra pessoa sejam afetados, isso é um handoff, não um prompt.