Uma interface gerada por IA pode parecer pronta no primeiro screenshot e ainda falhar no uso real. O problema aparece no texto longo que quebra o botão, no estado vazio que não foi previsto, na tabela que ocupa o mobile inteiro ou no componente que ignora o design system do projeto.

Quem quer usar vibe coding em UI com design system claro precisa tratar a tela como comportamento, não como imagem bonita. A IA pode montar a primeira versão, mas a aprovação depende de referência visual, componente existente, estado previsto, dado real e revisão humana.

Eu não aprovo uma tela gerada por IA olhando apenas se ela ficou bonita. Eu olho se ela respeita os componentes existentes, se responde à tarefa do usuário, se funciona com dados reais e se deixa claro o que acontece em erro, carregamento, vazio e permissão negada.

Aqui na Promovaweb, eu vejo esse tema aparecer direto na Formação IA Makers, principalmente quando alguém chega ao Co-work com uma tela gerada por agente e percebe que pedir componente era a parte mais simples. O Co-work é o encontro ao vivo de trabalho acompanhado em que projetos reais são abertos para revisão, servindo para tirar dúvidas, conferir decisões e transformar a própria dúvida em próximo passo revisável.

Direto ao ponto

Para usar vibe coding em UI com design system claro, defina o padrão visual antes do prompt, descreva a tarefa da tela, informe componentes existentes, peça estados reais e revise o resultado em desktop e mobile. A IA pode gerar a interface inicial, mas a pessoa responsável precisa aprovar layout, acessibilidade, comportamento e integração com dados.

UI com IA começa pelo design system

Vibe coding em interface não combina com improviso visual, porque cada tela nova precisa conversar com o restante do sistema. Quanto mais solto o pedido, maior a chance de a IA criar uma composição que parece sofisticada e ignora tokens, espaçamento, componentes e densidade já definidos.

O design system reduz ambiguidade quando informa cor, tipografia, espaçamento, densidade, raio, estados de botão, hierarquia de título, comportamento de formulário e padrão de componente. Sem essa referência, cada tela nasce com estética própria e o sistema começa a parecer uma coleção de versões diferentes do mesmo projeto.

O post sobre como usar DESIGN.md em projetos com IA no frontend aprofunda esse ponto com foco em referência visual persistente. A regra vale para qualquer agente, pois a IA precisa ler o padrão do projeto antes de gerar tela, componente ou variação visual.

Eu prefiro tratar o design system como entrada técnica, não como documento decorativo. Se a IA não sabe qual botão usar, qual card existe, qual grid está permitido e qual variação de formulário já foi aprovada, ela vai preencher lacunas com padrão genérico.

A tela precisa declarar estados antes da aparência

Interface boa inclui a versão feliz do fluxo e os estados que aparecem no uso real. A tela precisa dizer o que acontece enquanto carrega, quando não existe dado, quando a pessoa não tem permissão, quando o formulário falha, quando a lista tem muitos itens e quando uma informação importante é longa demais para caber em uma linha.

Esse é um erro comum no uso de IA para frontend quando o pedido valoriza a primeira impressão. O prompt pede “crie uma dashboard moderna”, a ferramenta entrega uma composição bonita e ninguém revisa os estados que definem a experiência real.

Quando eu peço UI para um agente, incluo pelo menos quatro informações: quem usa a tela, qual tarefa precisa concluir, quais dados podem aparecer e quais estados precisam existir. Essa referência muda o resultado porque a IA reduz o impulso de montar vitrine e começa a organizar uma interface com função.

Esse raciocínio conversa com o post sobre usar UX para orientar vibe coding, porque UX precisa entrar antes do prompt visual. A revisão melhora quando o pedido descreve tarefa, estado, fluxo e limite, em vez de deixar a IA decidir a experiência por aparência.

O pedido deve nomear componente, dado e limite

Um bom pedido de UI para IA precisa ser mais específico do que “crie uma página bonita”. Ele deve indicar se a tela usa botão primário ou secundário, card existente ou lista compacta, tabela simples ou tabela com ações, modal ou página dedicada.

O pedido também precisa informar dado real, porque nome de cliente longo, status com três palavras, preço, data, anexo, etiqueta, mensagem de erro e campo obrigatório mudam a composição. Se a revisão usa apenas texto falso curto, a tela pode quebrar no primeiro cadastro real.

Eu gosto de escrever pedidos nesse formato: objetivo da tela, usuário, componentes permitidos, dados de exemplo, estados obrigatórios e restrições de responsividade. Esse roteiro deixa menos espaço para a IA inventar padrão visual.

O GitHub Spec Kit ajuda quando a interface faz parte de um escopo maior e precisa virar requisito revisável. A especificação registra comportamento esperado, critério de aceite e restrições antes da implementação, tornando o código gerado mais fácil de revisar porque existe uma referência anterior ao componente.

Revisão visual é etapa técnica

Revisar UI gerada por IA exige critério técnico, não impressão estética isolada. A revisão precisa conferir contraste, hierarquia, alinhamento, densidade, responsividade, foco de teclado, estados interativos e coerência com os componentes locais.

Eu não aprovaria uma tela sem screenshot em desktop e mobile, nem aceitaria uma interface sem testar texto longo, lista vazia, erro de validação e loading. Esses casos revelam problemas que a primeira imagem costuma esconder, principalmente quando a IA gerou a tela com dados perfeitos e curtos.

Uma revisão simples pode usar um quadro curto para impedir aprovação baseada em impressão visual isolada. O objetivo não é substituir leitura técnica do código, mas garantir que a tela seja avaliada por comportamento, dado e responsividade.

Camada	Pergunta de revisão	Evidência esperada
Design system	Componentes existentes foram usados?	Botões, cards, inputs e espaçamentos coerentes
Comportamento	Estados principais foram previstos?	Loading, vazio, erro e permissão negada cobertos
Dados	Conteúdo real foi testado?	Texto longo, status e valores testados
Responsivo	Mobile continua legível?	Screenshot sem sobreposição ou quebra crítica
Acessibilidade	Foco e contraste foram revisados?	Elementos navegáveis e texto legível

Começar pela interface ajuda quando há critério

Começar pela tela pode ser uma boa escolha quando o objetivo é descobrir fluxo, estado e requisito visível. O risco aparece quando quem desenvolve confunde protótipo com sistema pronto e deixa regra de acesso, persistência, evento, segurança ou integração para depois.

O artigo sobre começar pela interface antes do banco de dados explica essa diferença com mais detalhe técnico. A tela ajuda a revelar o que precisa existir, mas precisa virar especificação antes de orientar arquitetura, dados e permissões.

No vibe coding, eu usaria a interface como conversa inicial com o sistema. Ela mostra o que o usuário tenta fazer, quais ações precisam existir e onde a experiência ainda está confusa, mas a especificação precisa transformar a tela em contrato técnico antes da implementação.

Também vale olhar o post sobre usar protótipo no vibe coding antes do backend quando a dúvida ainda está no fluxo visível. Protótipo é útil quando permite revisar percurso, estado e linguagem antes de fixar arquitetura.

O front-end ganha mais responsabilidade

O desenvolvedor que trabalha com UI assistida por IA não perde relevância por digitar menos classe. Ele ganha responsabilidade sobre especificação, leitura visual, acessibilidade, componente e aceite.

Esse trabalho exige repertório de interface, componente e manutenção em projeto real. É preciso saber quando reaproveitar componente, quando criar variação, quando uma tela está densa demais, quando o mobile ficou frágil e quando a IA inventou uma estrutura que vai custar caro para manter.

Na página de Vibe Coding, esse ponto é central porque IA ajuda a escrever código, mas a pessoa continua decidindo intenção, limite e revisão. Uma tela gerada sem esse filtro pode impressionar em demonstração e cobrar ajuste depois, quando dados reais, mobile e estados de erro entram no fluxo.

Aqui na Promovaweb, eu prefiro formar gente que sabe pedir, revisar e recusar saída ruim da IA. Aceitar tudo que a ferramenta entrega parece eficiente no começo, mas cria uma fila de correções visuais, inconsistências e exceções que aparecem no uso real.

Como aplicar no próximo prompt de UI

O próximo prompt deve começar com a tarefa do usuário e com o componente que já existe no projeto. Depois entram dados de exemplo, estados obrigatórios, restrições responsivas, regra de acessibilidade e referência ao design system.

Eu também pediria que a IA explique as escolhas visuais antes de alterar o código. Essa explicação ajuda a perceber quando ela ignorou componente local, inventou espaçamento, simplificou estado ou escolheu uma estrutura difícil de manter.

Depois da geração, revise a interface com screenshot e dado real do fluxo. Se a tela quebra com texto longo, fica densa no mobile ou não mostra erro, ela ainda não deve ser aprovada.

Esse ciclo pode parecer mais lento na primeira tentativa, mas reduz correção visual depois. O ganho aparece quando cada nova tela herda padrão, linguagem e comportamento, em vez de criar uma exceção estética que alguém precisará consertar no futuro.

Fechamento com critério de aceite

Vibe coding em UI funciona melhor quando o design system entra como requisito, não como revisão tardia. A IA pode montar a primeira versão, mas a tela só deveria avançar quando passa por estados, dados reais, mobile, acessibilidade e coerência com componentes existentes.

Eu usaria esse fluxo para criar primeira versão, comparar caminhos e reduzir repetição visual sem terceirizar a decisão de experiência. Para aprofundar esse tipo de rotina com agentes, frontend e revisão de código, a Formação IA Makers é o caminho mais próximo dentro da Promovaweb.