Guias

O que é vibe coding e onde o design costuma falhar

Por Thales Andrades MachadoPublicado em 23 de outubro de 2026Atualizado em 23 de outubro de 20269 min de leitura

Em resumo

Vibe coding é criar software conversando com uma IA, que escreve o código a partir de pedidos em linguagem natural; o termo foi cunhado por Andrej Karpathy em 2025. No design, as falhas típicas são paleta genérica, hierarquia fraca, contraste baixo, estados ausentes, layout quebrado no celular, movimento sem controle e efeitos pesados demais.

Vibe coding virou o nome de um jeito novo de criar software: em vez de escrever o código linha a linha, a pessoa descreve o que quer para uma IA, testa o resultado e pede ajustes. É uma forma rápida de tirar uma ideia do papel e também a origem de problemas visuais que se repetem de projeto em projeto. Este guia define o termo com fontes e passa pelos nove erros de design mais frequentes, com a correção de cada um.

O que é vibe coding?

O termo foi cunhado em fevereiro de 2025 por Andrej Karpathy, num post no X, como registra Martin Fowler. Na definição de Fowler, vibe coding é construir um aplicativo pedindo a um modelo de linguagem o que construir, testando e pedindo mudanças, sem olhar o código que o modelo gera. O post original de Karpathy fala em se entregar totalmente às vibes e esquecer que o código existe.

O Google Cloud descreve vibe coding como uma prática que torna a criação de apps mais acessível, em especial para quem tem pouca experiência em programação: o papel principal deixa de ser escrever código e passa a ser guiar um assistente de IA, numa conversa, para gerar, refinar e depurar o aplicativo. A página separa duas formas:

Vibe coding puro: a pessoa confia no resultado da IA quase sem inspecionar. Serve para explorar ideias rapidamente e para o que Karpathy chamou de projetos descartáveis de fim de semana.
Desenvolvimento assistido por IA com responsabilidade: a IA atua como parceira de programação, e a pessoa revisa, testa e entende o código, assumindo o produto final.

Fowler observa ainda que o termo pegou a ponto de muita gente usar "vibe coding" também para o trabalho em que o código é revisado. Na prática, quem chega a este guia costuma estar em algum ponto entre as duas formas.

Por que o design é o ponto fraco do vibe coding?

Três fatores se somam. Primeiro, o modelo tende ao padrão mais provável: a documentação de prompts da Anthropic afirma que, sem orientação, os modelos podem cair em padrões genéricos, o que os usuários chamam de estética "AI slop". Segundo, cada tela costuma nascer numa conversa diferente, sem regras visuais compartilhadas. Terceiro, a verificação para quando a tela funciona, e não quando ela funciona bem para todas as pessoas e em todos os aparelhos. No vibe coding puro, ninguém confere contraste, foco do teclado ou peso dos efeitos, porque ninguém está lendo o código nem testando além do caminho feliz.

Quais são os erros visuais mais comuns?

Erro	Como aparece	Correção
Paleta genérica	Gradiente roxo, cores sem papel	Tokens de cor com papéis definidos
Espaçamento aleatório	Blocos parecidos com distâncias diferentes	Uma escala de espaçamento única
Hierarquia fraca	Tudo do mesmo tamanho, ou tudo em destaque	Escala tipográfica e um foco por tela
Contraste baixo	Cinza-claro sobre branco	4,5:1 no texto normal e 3:1 no grande
Estados ausentes	Sem carregando, vazio, erro ou foco	Pedir cada estado de forma explícita
Celular esquecido	Rolagem lateral, botões minúsculos	Mobile first, 320 px sem rolagem lateral, alvos de 24 px
Movimento sem controle	Animação contínua e sem pausa	Movimento reduzido e controle de pausa
Efeitos pesados	Página lenta, layout que pula	Carregar sob demanda e medir Core Web Vitals
Modo escuro remendado	Cores invertidas sem critério	Tokens para os dois temas

Como corrigir cada erro?

Paleta genérica

É o sintoma mais reconhecível: o gradiente roxo sobre fundo branco que a própria documentação da Anthropic cita como clichê. A correção é dar papel a cada cor (fundo, superfície, texto, texto secundário, borda, destaque, sucesso e erro) e registrar tudo como tokens, por exemplo no bloco @theme do Tailwind CSS v4. Um seletor como Anilina, que trabalha em OKLCH, mostra o contraste WCAG contra um fundo escolhido e gera uma escala de 50 a 950, ajuda a montar a paleta. No topo da página, um fundo de movimento lento nas cores da marca, como Lusco-fusco, que o catálogo classifica como Leve, substitui o gradiente padrão.

Espaçamento aleatório

A IA escolhe uma distância diferente a cada bloco, e a tela perde ritmo. Defina uma escala de espaçamento, registre no CLAUDE.md ou nas regras do Cursor que toda margem e todo preenchimento saem dela e use mais espaço entre grupos do que dentro de cada grupo.

Hierarquia fraca

Quando título, subtítulo e botões têm pesos parecidos, a pessoa não sabe para onde olhar. Use uma escala tipográfica curta, um elemento dominante por tela e as tags de título em ordem, de h1 a h6, sem pular níveis, como recomenda o guia de acessibilidade da Vue.

Contraste baixo

Cinza-claro sobre branco parece elegante no monitor e some no celular sob o sol, um caso que o próprio guia de acessibilidade da Vue cita. O critério 1.4.3 das WCAG 2.2, de nível AA, pede pelo menos 4,5:1 para texto normal e 3:1 para texto grande. Coloque o número no pedido e peça à IA que confira cada par de cores.

Estados ausentes

A IA entrega a tela com dados e com o mouse por cima, e esquece o resto: carregando, vazio, erro, desabilitado e foco do teclado. O critério 2.4.7 das WCAG 2.2, de nível AA, exige que interfaces operáveis por teclado tenham um modo com o indicador de foco visível. Para o feedback de ações, um componente como Baralho, com avisos de sucesso, erro, aviso, informação e carregando, além da ação Desfazer, cobre de uma vez um estado que costuma faltar.

Celular esquecido

O vibe coding costuma acontecer num monitor grande, e o celular fica para depois. O critério 1.4.10 das WCAG, de nível AA, pede que o conteúdo funcione numa largura equivalente a 320 pixels CSS sem rolagem nas duas direções, e o critério 2.5.8 das WCAG 2.2 pede alvos de toque de pelo menos 24 por 24 pixels CSS, salvo exceções. O Tailwind CSS ajuda porque é mobile first: classes sem prefixo valem para todas as larguras, e prefixos como md: valem a partir daquele ponto de quebra. Para filtros e detalhes no celular, um painel que sobe de baixo, como Mezanino, costuma ser mais confortável que um modal centralizado, e dicas ancoradas como as de Baliza invertem de lado quando encostam na borda da tela.

Movimento sem controle

Animação em tudo cansa e pode incomodar quem tem sensibilidade a movimento. A media query prefers-reduced-motion detecta quando a pessoa pediu ao sistema menos movimento, e todo efeito precisa de uma versão estática ou mais calma para esse caso. Além disso, o critério 2.2.2 das WCAG, de nível A, pede um meio de pausar, parar ou ocultar qualquer conteúdo que se move sozinho, dura mais de cinco segundos e aparece junto com outro conteúdo, como carrosséis automáticos e faixas que rolam sem parar.

Efeitos pesados demais

Um fundo em WebGL, um cursor com rastro e um carrossel em 3D na mesma página derrubam o desempenho, principalmente no celular. O web.dev considera boa a experiência com LCP de até 2,5 s, INP de até 200 ms e CLS de até 0,1. O CLS piora com imagens sem dimensões, conteúdo injetado depois do carregamento e fontes web; a recomendação é informar sempre largura e altura de imagens e vídeos, ou reservar o espaço com aspect-ratio, e animar com transform. Use no máximo um efeito pesado por página e carregue esse efeito sob demanda.

Modo escuro remendado

Pedir "faça o modo escuro" no fim do projeto costuma gerar cores invertidas sem critério e contraste quebrado em algum canto. A media query prefers-color-scheme detecta se a pessoa pediu tema claro ou escuro no sistema operacional ou no navegador. Defina os tokens dos dois temas desde o início e confira o contraste nos dois.

Como pedir a correção para a IA?

Com os erros identificados, peça a correção com a lista na mão. Este pedido funciona no Claude Code e no Cursor:

Faça uma auditoria visual desta tela e corrija nesta ordem: 1) troque cores soltas por tokens do @theme; 2) aplique a escala de espaçamento; 3) deixe um único foco visual; 4) garanta contraste de 4,5:1 no texto; 5) crie os estados de carregando, vazio, erro e foco visível; 6) teste em 320 px sem rolagem lateral e com alvos de toque de 24 px; 7) adicione a versão para prefers-reduced-motion e um botão de pausa em tudo que se move sozinho; 8) confira que LCP, INP e CLS não pioraram. Antes de cada correção, explique o problema em uma frase; depois, mostre uma captura do resultado.

Se você está no vibe coding puro, sem ler o código, essa auditoria é o mínimo antes de publicar algo que outras pessoas vão usar. Se você revisa o código, ela vira parte do processo, como qualquer teste.

Onde componentes prontos ajudam?

Boa parte desses erros some quando a peça já chega resolvida. O THM Componentes é um catálogo de 268 componentes para Vue 3 e Nuxt, 115 deles exclusivos, e cada componente vem com um prompt pronto para Claude Code e Cursor. Os exclusivos citados aqui já tratam detalhes que a IA costuma esquecer, como o foco preso e o Esc de Mezanino e as máscaras e validações de CPF, CNPJ e CEP de Despachante. O suporte oficial é para Vue 3 e Nuxt; em React, a IA precisa converter o código, e a conversão pede revisão.

Para o método completo de acabamento, veja Como deixar um app feito com IA com visual profissional. Para escrever pedidos que evitem esses erros desde o início, veja Como pedir uma interface bonita para o Claude Code e o Cursor.