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 a cada turno tudo é redecidido — 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 costuma ser ignorada porque fazer 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 cor é 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 o que for que sua ferramenta leia — .cursor/rules/design.mdc, .devin/rules/design.md, uma linha em CLAUDE.md. Mantenha como política, não como gosto: use apenas os tokens semânticos, nunca um hex bruto, nenhum segundo destaque em uma tela, nunca entregue uma alteração de light mode sem a contraparte de dark mode, e pergunte em vez de inventar quando o sistema for omisso.

3. 3

   Coloque um preview para rodar 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 válido. "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 e 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 mantê-la enquanto tenta consertá-la.
• Diga o que não deve ser tocado. "Altere apenas este componente" evita aquele refactor indesejado de três arquivos que você já havia aprovado.
• Quando algo der errado, reverta em vez de negociar. Três rodadas de "não, não é assim" geram um resultado remendado que satisfaz a conversa, mas não o design. Volte ao último commit estável e peça novamente com um prompt melhor.

Esta é a habilidade que vale a pena aprender, e é uma habilidade de revisão de design vestindo um chapéu de git. Você não está verificando se o código está bom. Você está verificando quatro coisas, e todas as quatro são visíveis sem entender uma linha de lógica.

Esses quatro checks levam cerca de um minuto por diff e capturam a maior parte do que causa o desvio do design. 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 por completo.

• Aceitação complacente. Pergunte "isso está seguindo o design system?" e geralmente dirão que sim. Pergunte, em vez disso, "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 deixa a tela correta e o sistema errado. Isso aparece na primeira vez que você altera um token e um componente não se move.
• Remendando o output 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.
• Melhorando o sistema no meio da tarefa. Uma nova cor introduzida "para contraste". Isso é desvio com uma justificativa anexada, e é o tipo mais difícil de detectar porque o raciocínio faz sentido.
• Passando no teste errado. Ele renderiza, então funciona. Verifique o dark mode, 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. De forma útil, a quantidade necessária é específica em vez de genérica.

• Lendo um diff. Verde adicionado, vermelho removido, e os quatro checks acima. Uma tarde de trabalho.
• Git básico. Commit, visualizar um 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.
• Lendo um erro. Não corrigi-lo. Ser capaz de colar a parte relevante em vez de um print de todo o terminal.

O que você não precisa é de escrever React, entender ferramentas de build ou gerenciar dependências. Essas são exatamente as funções do agente, e o tempo gasto aprendendo isso é tempo que não é gasto na habilidade de revisão, que nada mais pode fazer por você.

O 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 nas fronteiras onde um erro não é visual: autenticação, pagamentos, qualquer coisa que toque dados de clientes, qualquer coisa que envolva uma 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 for o fato de parecer feio, publique e itere. Se o pior resultado for que os dados ou o dinheiro de outra pessoa sejam afetados, isso é um handoff, não um prompt.