Vibe coding: o que é, quando faz sentido e onde vira armadilha

Vibe coding é descrever o que você quer construir em linguagem natural e deixar a IA gerar o código, sem ler o diff, sem rodar teste, sem entender o que voltou. O termo foi cunhado por Andrej Karpathy em fevereiro de 2025 e viralizou no Twitter/X. Funciona pra protótipo descartável. Quebra em produto que precisa viver mais de três meses. Em 7.500+ sessões Claude Code do AIOX, observamos exatamente onde quebra. E como CLI First com framework salva.

O que é vibe coding, na definição mínima?

Vibe coding é um modo específico de usar IA pra programar: você descreve a intenção, o modelo gera o código, e você aceita o output sem auditar. Sem ler diff. Sem rodar teste. Sem entender a lógica que voltou.

Andrej Karpathy publicou a definição original em 2 de fevereiro de 2025 no X: "There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists." A frase virou meme em uma semana e entrou no vocabulário do mercado de software no trimestre seguinte.

O ponto central é a abdicação consciente da revisão. Você confia no modelo. Você roda. Se funciona visualmente, segue em frente. Se não funciona, prompt de novo até passar.

Pair programming clássico tem dois humanos lendo o código. Programar com IA inclui ler o output, testar e entender. Vibe coding pula essas etapas. Toda vibe coding é programação com IA, mas nem toda programação com IA é vibe coding.

Por que o termo viralizou em 2025?

Três forças convergiram em Q1 2025. Primeira: ferramentas como Claude Code, Cursor e Bolt baixaram a fricção entre intenção e código gerado. Segunda: Karpathy é um nome respeitado (cofundador da OpenAI, ex-Tesla) e a frase tinha potência viral. Terceira: o ciclo curto do Twitter/X premia demos de 30 segundos onde alguém "constrói um app em 10 minutos".

Demo culture vendeu uma narrativa: "agora qualquer um pode programar". Para o ICP que chamamos de Empreendedor Refém (pessoa que tem ideia, sente que paga caro pra dev/agência e não consegue validar), a promessa é magnética. Vibe coding parece atalho.

O problema não é o termo. O problema é que 80% das demos virais são protótipos descartáveis vendidos como produto. O dev sênior assiste, identifica os buracos. O empreendedor sem contexto técnico assiste e acredita que ali está a fórmula.

Em 7.500+ sessões Claude Code, vimos esse gap repetido. As pessoas adotam vibe coding pra demos. Depois tentam fazer produto com a mesma técnica. O segundo passo costuma falhar.

Vibe coding é programação ou entretenimento?

Vibe coding sem framework é entretenimento, não engenharia. Essa é a tese.

Programação tem quatro camadas: especificação, código, teste, manutenção. Vibe coding pula três das quatro. Assume que o prompt cobre a spec. Ignora o teste. Ignora a manutenção. Sobra uma camada: o código que apareceu na tela.

Engenharia de software incorpora entropia desde o dia zero. Tipos, contratos, testes, observabilidade. Tudo existe pra controlar a entropia que se acumula no tempo. Vibe coding maximiza velocidade no presente assumindo que o futuro vai se resolver.

Do ponto de vista de sistemas, isso é o oposto de engenharia. É demo. Demo é uma forma legítima de comunicação: venda, validação de ideia, exploração de tema. Mas demo não é produto. Confundir os dois custa caro.

O que vimos na cohort AIOX Pro com 250+ alunos: quem entrou achando que vibe coding era a etapa final travou no momento de avançar o protótipo. Quem entendeu que era etapa inicial passou pra etapa seguinte (framework, governance, agents) e construiu produto.

Onde vibe coding faz sentido (e onde quebra)?

Vibe coding faz sentido em quatro contextos: prototipagem descartável, exploração de ideia, scripts pessoais one-shot, e mock pra demo de venda. O ponto comum é horizonte curto. O código existe pra cumprir uma função imediata e morrer depois.

Vibe coding quebra em quatro contextos opostos: produto que precisa de manutenção contínua, time com mais de um dev, código que precisa onboarding, e qualquer fluxo crítico (pagamento, autenticação, dados sensíveis). O ponto comum é horizonte longo e múltiplos leitores.

A heurística prática é uma pergunta: alguém vai precisar entender esse código em três meses? Se sim, vibe coding sozinho não basta. Você precisa de spec escrita, teste cobrindo o caminho feliz, e estrutura de pasta que outro humano entenda sem decifrar.

Exemplo concreto. O blog que você está lendo (apps/blog-aiox-pt no nosso monorepo) é open-source. Foi escrito com framework AIOX, oito layers de governance, agents owning each layer. Se tivesse sido escrito puro vibe coding, hoje seria intratável. Como foi estruturado, é mantível por qualquer um que entre no projeto.

As três armadilhas que ninguém te conta

Primeira armadilha: tech debt invisível. O código gerado roda. Passa nos seus testes manuais (que são "abrir e clicar"). Mas ninguém leu de verdade. Em três meses você precisa adicionar uma feature e descobre que metade do código foi gerada usando uma lib deprecated, uma convenção que o resto do projeto não segue, e uma lógica de tratamento de erro que ninguém pensou. Custo silencioso acumulado.

Segunda armadilha: lock-in de prompt. O source of truth virou o prompt, não o código. Você muda de modelo (Claude pra GPT-5 pra Gemini), muda a versão do modelo, e o output muda. Você perdeu reproducibilidade. Duas chamadas idênticas geram código diferente. Em produção, isso vira bug intermitente que ninguém consegue rastrear.

Terceira armadilha: código que ninguém entende em três meses, incluindo você. Sem squads, sem agents, sem rules estruturando o output, vibe coding vira caixa preta. Funcionou. Você não sabe por quê. Quando precisar mexer, vai prompt de novo, gerando outra caixa preta em cima da primeira.

Cada uma das três armadilhas tem o mesmo padrão: custo zero hoje, custo alto depois. Vibe coding sem método empurra entropia pro futuro. Quando o futuro chega, o custo está pago em juros compostos.

Como aplicar vibe coding sem virar refém dele?

Vibe coding com método versus vibe coding sem método. Essa é a partição certa. Quatro práticas concretas separam um do outro.

Primeira prática: defina contratos antes do prompt. Schema, types, critérios de aceite. Vibe coding gera o código rápido. Os contratos validam se o código gerado faz o que devia. Sem contrato, você não tem como saber se a saída é certa ou parece certa.

Segunda prática: squads/agents owning each layer. Arquitetura, dev, qa, devops separados. Cada agent tem authority delegada e responsabilidade clara. Quando algo dá errado, você sabe quem revisa. No framework AIOX, "@devops é o único que pode push" não é sugestão, é regra inegociável aplicada por hook.

Terceira prática: framework acima de prompts one-shot. Framework dá estrutura repetível. Prompt one-shot é volátil: funciona uma vez, dá outra coisa na próxima. AIOX usa templates, checklists e workflows que sobrevivem a mudanças de modelo, mudanças de operador e mudanças de contexto.

Quarta prática: Constitution mais governance. Regras inegociáveis aplicam mesmo quando você está em modo vibe. CLI First, story-driven, no invention, quality first. Esses princípios não dependem do humor do criador. Eles travam quando alguém tenta atalhar.

Em 7.500+ sessões Claude Code do AIOX, framework converte vibe em produção. Sem framework, vibe vira demo bonita que não escala.

Vibe coding ou framework: a falsa escolha

O argumento popular é binário: "framework atrasa, vibe coding é o futuro" ou "vibe coding é gambiarra, só engenharia tradicional vale". Os dois lados perdem.

A leitura correta é composta. Framework é estratégia (estrutura repetível, governance, qualidade). Vibe coding é tática (geração rápida, exploração, baixa fricção). Você usa os dois, em camadas diferentes do mesmo projeto.

Pareto ao Cubo aplicado: framework define os 0,8% que importam (autenticação, integridade de dados, governance, agents authority). Vibe coding fecha os 99,2% (UI, glue code, scripts auxiliares, prototipagem rápida de feature). O criador profissional usa os dois sem culpa. O criador travado escolhe um e perde o outro.

Vibe coding não é vilão nem herói. É ferramenta com escopo. Sem método vira tech debt. Com framework vira CLI First de produção real. A pergunta certa não é "vibe coding sim ou não". É "vibe coding com qual estrutura ao redor?".

Há um teste simples pra saber em qual lado da linha você está hoje. Pegue um repositório que você gerou com vibe coding nos últimos seis meses. Tente adicionar uma feature nova sem reler o código todo. Se você consegue, o que existe ali é estrutura, e o vibe foi tática. Se você não consegue, o que existe é dívida, e o vibe foi estratégia. Quem está construindo produto pra ficar usa vibe coding como acelerador dentro de uma arquitetura que aguenta. Quem está construindo demo pra impressionar usa vibe coding como tudo, e descobre depois que o tudo era pouco. A diferença entre os dois caminhos não aparece na primeira semana, aparece no terceiro mês, quando o produto pede manutenção e o código pede uma reescrita inteira. Framework AIOX, CLI First, agent authority, Constitution: esses não são overhead, são o seguro que você paga pra que o vibe de hoje não vire prejuízo amanhã.