Vibe coding vs vibe designing: 5 limites para designers

Vibe coding é programar descrevendo o que você quer a uma IA e aceitando o resultado sem revisar linha por linha; o Merriam-Webster atribui o termo a um post de Andrej Karpathy de 2 de fevereiro de 2025. Na comparação vibe coding vs vibe designing, o segundo é o mesmo movimento aplicado à interface: você descreve a intenção e a IA devolve telas ou um protótipo.

Este texto separa os dois termos, apresenta cinco limites para checar (seleção editorial, não um ranking) e explica o que isso muda no jeito de se posicionar para vagas fora. Ferramentas mudam com frequência, então o foco aqui está nos critérios.

O que é vibe coding e quem criou o termo?

Vibe coding é um estilo de programar em que você pede o resultado em linguagem natural e confia na IA para escrever o código. O Merriam-Webster registra a expressão como gíria e a define como “writing computer code in a somewhat careless fashion, with AI assistance” (escrever código de forma um tanto descuidada, com ajuda de IA). O dicionário atribui o termo, em caráter provisório (“tentatively”), a Andrej Karpathy (descrito como cofundador da OpenAI) e cita o post de 2 de fevereiro de 2025 em que ele escreve: “There’s a new kind of coding I call ‘vibe coding’, where you fully give in to the vibes”.

Duas observações sobre essa origem. Primeiro, a frase citada pelo dicionário apresenta uma forma nova de programar, e não um método de trabalho com etapas. Segundo, “descuidado” está na própria definição. O termo já nasce com a ressalva de que você abre mão de revisar o que foi gerado, e é isso que interessa a quem entrega produto para empresa de fora.

O que é vibe designing?

Vibe designing é o uso informal do mesmo fluxo no design de interface: em vez de posicionar elementos um a um, você descreve a intenção e a IA propõe layouts, fluxos ou protótipos em código. Não há definição oficial conhecida. Por isso, aqui vai como definição de trabalho, não como conceito consolidado.

O que as fontes confiáveis descrevem é o fenômeno por trás do nome. A Adobe, em um texto sobre como seus designers prototipam em código, diz que o trabalho do designer passa de descrever intenção para mostrar comportamento: testar com conteúdo real, restrições de sistema e casos de borda antes que os requisitos endureçam.

Qual a diferença entre vibe coding e vibe designing?

A diferença está no objetivo e em quem responde pelo resultado. Vibe coding busca software que roda; vibe designing busca uma interface que comunica a decisão certa. A tabela resume.

	Vibe coding	Vibe designing
Entrada	Descrição do que o software deve fazer	Descrição da experiência, do fluxo ou da tela
Saída	Código e aplicação funcionando	Telas, fluxos ou protótipo navegável
Quem usa	Desenvolvedores e pessoas sem formação em programação	Designers, PMs e quem quer validar uma ideia
Critério de “bom”	Roda, passa nos testes, é seguro	Resolve o problema do usuário e do negócio
Risco principal	Código frágil ou inseguro que ninguém entende	Interface genérica, inconsistente ou inacessível
Onde o humano decide	Arquitetura, revisão, segurança	Problema, prioridade, trade-offs, critério de qualidade
Fonte do termo	Post de Karpathy, 2/2/2025 (atribuição do Merriam-Webster, citado acima)	Uso informal, sem definição oficial

Em projetos reais os dois se misturam. Quando o designer gera um protótipo em código, ele está fazendo as duas coisas ao mesmo tempo, e herda os riscos das duas colunas.

Quais são os 5 limites reais do vibe coding e do vibe designing?

A seleção a seguir é editorial: nenhuma fonte ordena os limites por peso. São cinco pontos para checar: qualidade do que é gerado, acessibilidade, consistência de design system, handoff e segurança. Cada um tem uma fonte que você pode conferir e uma consequência para o seu trabalho.

1. Qualidade: o resultado precisa ser revisado

Uma pesquisa com 22 integrantes de times de produto (empresas, startups e academia) descreve o fluxo do vibe coding em quatro etapas: ideação, geração, debug e revisão. Os participantes relataram código pouco confiável, dificuldade de integração e dependência excessiva da IA. Os autores também discutem risco de perda de habilidade (deskilling) e a pergunta sobre quem responde pelo que foi gerado.

Na leitura do blog, essa etapa de revisão é a que mais cabe ao designer. A IA entrega uma primeira versão rápida; quem avalia se aquilo é bom é você. Se o seu processo termina quando a tela aparece, falta mostrar o critério de revisão, e é ele que dá substância a um case.

2. Acessibilidade: o ponto de partida da web já é ruim

O padrão de referência é o WCAG 2.2, publicado pelo W3C em 5 de outubro de 2023, com atualização em 12 de dezembro de 2024. Ele organiza 13 diretrizes com critérios testáveis em três níveis (A, AA e AAA).

Para ter uma noção do estado atual da web: o WebAIM Million, com dados de fevereiro de 2026, encontrou falhas de WCAG 2 detectáveis em 95,9% das páginas iniciais analisadas. A falha mais comum foi texto com baixo contraste (83,9%), seguida de imagens sem texto alternativo (53,1%) e campos de formulário sem rótulo (51%).

Esses números descrevem a web em geral, não código gerado por IA. Eles servem de aviso: acessibilidade não sai pronta de um prompt; alguém precisa checar. Se você publica uma tela gerada sem checar contraste, rótulos e navegação por teclado, a responsabilidade é sua. Uma checagem automática também não cobre tudo, então teste fluxos reais.

3. Consistência de design system: a IA precisa de regras

Gerar uma tela bonita leva minutos. Gerar uma tela que usa os componentes e tokens do seu produto é outro problema. A Adobe descreve que seu design system, o Spectrum, entra no fluxo de protótipo com IA por meio de tokens, componentes, documentação e regras legíveis por máquina. O objetivo é que o resultado pareça intencional em vez de genérico.

A documentação do Figma segue a mesma lógica. No Figma Make, a página sobre pacotes de design system afirma que as guidelines são “critical for ensuring Figma Make can use your design package for high quality, reliable output” e recomenda gerar as guidelines e depois revisar o resultado.

Nas duas empresas a orientação converge: sem sistema bem documentado, a IA tem menos regras para seguir. Quem sabe construir e manter essas regras ganha valor. Se esse é o seu ponto fraco, veja como contar um design system no portfólio.

4. Handoff: protótipo não é produção

O texto da Adobe sobre prototipar em código é direto: “A coded prototype is not a shortcut around engineering rigor.” Um protótipo gerado ajuda a responder perguntas de comportamento e de casos de borda cedo, quando mudar é barato, e dá a designers, PMs e engenheiros uma experiência compartilhada em vez de uma especificação abstrata. Mas a linha entre exploração e compromisso continua existindo.

No dia a dia, o handoff muda de forma. Em vez de só entregar telas, você entrega o protótipo com o que ele prova, o que ele ainda não resolve e o que precisa ser reescrito para produção. Se o time de engenharia herda um protótipo sem essa conversa, o custo aparece depois.

5. Segurança e manutenção: o código gerado também falha

Segundo a Veracode, empresa de segurança de aplicações, em seu relatório 2025 GenAI Code Security Report (30 de julho de 2025), testando código gerado por mais de 100 modelos de linguagem, 45% das amostras falharam em testes de segurança, introduzindo vulnerabilidades do OWASP Top 10. Em Java, a taxa de falha foi de 72%. Os dados vêm de um fornecedor de segurança e de tarefas de teste, então servem como sinal, não como previsão de quanto do seu protótipo vai falhar.

Um estudo acadêmico anterior, com outro modelo e outro método, aponta a mesma ordem de grandeza: aproximadamente 40% dos programas gerados pelo GitHub Copilot eram vulneráveis em 89 cenários de teste ligados a fraquezas da lista CWE Top 25 (Pearce et al., IEEE S&P 2022). O modelo estudado era o Copilot de 2021 e já mudou desde então; o número descreve aquele momento, não as ferramentas de hoje. Também são cenários desenhados para provocar falhas, não uso cotidiano.

Em termos de responsabilidade: se o que você gerou vai a produção, alguém precisa revisar segurança e manter aquele código. Quem entrega sem saber o que há dentro do código transfere o risco para o time. Saber explicar isso em uma entrevista é, a nosso ver, uma forma de mostrar maturidade.

O que vibe coding faz bem para designers?

Faz bem o que a Adobe descreve: explorar comportamento e validar ideias cedo. Protótipos em código mostram timing, estados e casos de borda que uma tela estática esconde. Eles também reduzem a distância entre design e engenharia, porque todos reagem a algo que funciona.

É uma boa ferramenta de discovery. O problema aparece quando o protótipo é tratado como entrega final ou quando o designer deixa de explicar por que aquela solução foi escolhida.

O que isso muda para quem é designer?

A recomendação editorial é mudar o que você prova. Quando gerar telas fica mais rápido (leitura editorial, não dado de fonte), a qualidade das decisões e a clareza de como você as comunica ganham peso no seu case. Isso conversa com a tese deste blog: antes de um portfólio novo, você precisa de um posicionamento claro.

O que as fontes mostram	O que o designer faz com isso (leitura editorial)
45% das amostras de código gerado por IA falharam em testes de segurança (Veracode, julho de 2025)	Não apresenta protótipo de IA como produto pronto; diz no case o que foi revisado e por quem
95,9% das home pages tinham falhas de WCAG 2 detectáveis (WebAIM Million, fevereiro de 2026)	Confere contraste, rótulos e foco em toda tela gerada e mostra essa checagem no case
O Figma diz que as guidelines do pacote de design system são críticas para um resultado confiável no Figma Make	Leva o design system para o fluxo com IA e conta a consistência como decisão sua
22 integrantes de times de produto relataram código pouco confiável e dependência excessiva da IA (arXiv, 2025)	Mostra no case o que revisou ou corrigiu no protótipo gerado, e por quê

Quatro ajustes concretos antes de se candidatar:

1. Mostre julgamento, não só output. No case study, explique qual problema você escolheu resolver, quais alternativas descartou e por quê. Gerar uma tela leva minutos; explicar o trade-off é o que mostra critério.
2. Ligue o trabalho a outcomes. Diga o que mudou para o usuário ou para o negócio. Se não há métrica, descreva o critério que usou para decidir. Mais em diferença entre portfólio de UX/UI para vagas globais.
3. Declare como você usa IA. Vale preparar-se para a pergunta em entrevista. Uma boa resposta mostra onde a IA acelera, onde você revisa (acessibilidade, consistência, segurança) e onde você decide sozinho.
4. Pratique defender decisões em inglês. Descrever “por que não escolhi a primeira opção que a IA deu” é o tipo de resposta que diferencia. Veja como defender decisões de design em inglês.

Exemplo ilustrativo de frase para entrevista; adapte só se for verdade no seu caso:

“I used AI to explore five directions in an afternoon. I discarded four because they didn’t meet our accessibility requirements, and I chose the fifth because it matched the existing design system. Here’s how I validated it with users.”

A frase reúne três elementos que vale demonstrar a um hiring manager: velocidade, critério e validação. Nenhum deles depende da ferramenta que você usou.

Se você ainda está montando esse tipo de narrativa, a Masterclass de Posicionamento do Designer na Gringa trabalha o foco no posicionamento e em resultados validados: outcomes acima de outputs. Para mais artigos sobre carreira internacional, veja a categoria carreira.

Como contornar esses 5 limites no próximo projeto

Um roteiro curto para usar IA sem perder o controle do resultado:

1. Defina o problema e o critério antes do prompt. O que é um bom resultado? Escreva isso em duas frases.
2. Gere variações e descarte com motivo. Anote por que cada uma saiu. Esse registro vira conteúdo do case.
3. Cheque acessibilidade com o WCAG 2.2 como referência. Contraste, rótulos, foco e teclado, no mínimo.
4. Compare com o design system. Se a variação usa componente que não existe, decida: ajusta a tela ou propõe o componente.
5. Documente o handoff. O que o protótipo prova, o que falta e o que vai ser reescrito.
6. Registre o que você decidiu sozinho. É esse trecho que você vai contar na entrevista.

Nada disso depende de uma ferramenta específica. Se a ferramenta mudar daqui a seis meses, o processo continua valendo.

Resumo: o que levar deste texto

Vibe coding é um termo com data: o Merriam-Webster o atribui a um post de Karpathy de 2 de fevereiro de 2025. Vibe designing é o uso informal do mesmo fluxo na interface. Os limites reais são de qualidade, acessibilidade, consistência, handoff e segurança, e todos pedem alguém que revise e responda pelo resultado. Para quem busca vaga fora, isso desloca o foco: menos “sei usar a ferramenta X”, mais “tomo boas decisões e consigo defendê-las”.