O que é vibe coding: definição, como se faz e onde quebra

O vibe coding é programar pedindo o código a uma IA em linguagem natural e aceitando o que ela devolve sem ler nem revisar linha por linha: você descreve o que quer, roda o app, vê se funciona e pede ajustes. O termo foi proposto por Andrej Karpathy em 2 de fevereiro de 2025 e, em poucos meses, passou de piada de programador a palavra do ano.

É uma ótima forma de chegar a um protótipo que parece e se comporta como um produto. É uma forma ruim de chegar a algo que cobra, guarda dados de outras pessoas e aguenta um ataque. Este guia explica as duas metades: o que é, como se faz e com quais ferramentas, e onde quebra, com incidentes reais e fontes.

De onde vem o termo

A fonte primária é um post de Andrej Karpathy no X (antigo Twitter), publicado em 2 de fevereiro de 2025, às 23:17 UTC. Karpathy foi diretor de IA da Tesla e é um dos engenheiros fundadores da OpenAI. O post começa assim:

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.

No mesmo post, Karpathy diz que isso é possível porque os LLMs (ele cita o Cursor Composer com Sonnet) estão "getting too good", e que ele fala com o editor por voz, usando o SuperWhisper. Fonte: o post original.

Desde então a palavra pegou. Em novembro de 2025 o Collins Dictionary a elegeu palavra do ano e a definiu como "the use of artificial intelligence prompted by natural language to assist with the writing of computer code" (CNN, 6 de novembro de 2025).

Vibe coding não é "programar com ajuda de IA"

A distinção mais citada é a de Simon Willison, de 19 de março de 2025: para ele, vibe coding é construir software com um LLM sem revisar o código que ele escreve. Se você usa um LLM mas revisa, testa e entende o que sai, isso é desenvolvimento assistido, não vibe coding. A regra dele para trabalho profissional: não faz commit de código que não conseguiria explicar a outra pessoa (post do Willison).

Essa fronteira é a que importa no resto do guia: o risco não vem de usar IA, vem de não olhar o que a IA fez.

Como se faz vibe coding

O ciclo é curto e quase não tem passos técnicos:

1. Você descreve o app ou a mudança em linguagem natural ("uma agenda para a minha academia, com login e pagamento").
2. A ferramenta gera telas, componentes e, conforme o caso, banco de dados e backend.
3. Você testa o app no navegador. Se algo não funciona, copia o erro ou descreve o problema e devolve para a IA.
4. Você repete até ficar bom, e publica.

O que define o vibe coding não é a ferramenta, e sim o que não aparece nesse ciclo: ler o diff, escrever testes, revisar permissões, pensar no que acontece se o mesmo webhook chegar duas vezes. Se você não pede, a IA não faz.

Ferramentas mais usadas

Lovable, Bolt e v0 miram quem programa pouco. Cursor e Claude Code miram quem programa e quer ir mais rápido, e é aí que a fronteira com o desenvolvimento assistido fica borrada: o mesmo agente pode ser usado "no clima" ou com revisão rigorosa. Para o segundo caso há guias de configuração: um exemplo de CLAUDE.md para um SaaS, os hooks do Claude Code para forçar arquitetura e as regras do Cursor para Next.js e TypeScript (os três em inglês).

Onde quebra: os limites reais

Nada do que segue é opinião sobre IA; são incidentes e registros públicos.

Segurança de dados: o caso Lovable

Matt Palmer e sua equipe escanearam 1.645 projetos feitos com Lovable em 21 de março de 2025 e encontraram 170 com configurações inadequadas de row-level security (RLS), com 303 endpoints do Supabase identificados. O scan só olhou as páginas iniciais, sem entrar em áreas com login (statement do Palmer). O padrão foi registrado como CVE-2025-48757: segundo a descrição do NVD, uma política de RLS insuficiente no Lovable permitia que atacantes remotos sem autenticação lessem ou escrevessem em tabelas arbitrárias dos sites gerados. O mesmo registro informa que o fornecedor contesta, porque cada cliente da plataforma é responsável por proteger os dados do seu aplicativo. As duas leituras levam à mesma conclusão prática: ninguém escreve essa política se você não pedir, e quem revisa é você.

Um relatório da vibe-eval.com, que reúne uma auditoria manual de 50 apps (Cursor, Lovable, Bolt, v0) publicada no Reddit, diz que 90% têm as mesmas cinco vulnerabilidades, entre elas API keys hardcoded (relatório).

Multi-tenancy: um cliente não pode ver as linhas de outro

Se o seu app tem organizações, equipes ou workspaces, o erro clássico é uma consulta que esquece o filtro por organização: compila, passa na demo e vaza dados entre clientes. Um artigo sobre Claude Code e boilerplates resume que o código gerado a partir de um repositório vazio faz a média de anos de código público, e "the average includes the bugs" (buildthisnow.com). O detalhe técnico de como isso se fecha está em multi-tenancy no Prisma com tenant guard (em inglês).

Pagamentos: o webhook que chega duas vezes

Cobrar no cartão no caminho feliz é um prompt. Um sistema de cobrança é outra coisa: verificar assinaturas, retentativas, estado que se reconcilia depois do webhook. O bug típico: "If Stripe sends the same message twice (which it does), your app charges or credits the user twice" (mesma fonte, buildthisnow.com). Os provedores reenviam eventos; um handler que insere a cada entrega cobra em dobro. E se um atacante consegue a secret key, o custo é direto: num tópico do Hacker News sobre um SaaS vibe-codado contam "the hacker got a hold of his Stripe key and issued every customer a refund" (Hacker News).

Agentes com alcance à produção: o caso Replit e SaaStr

Em julho de 2025, Jason Lemkin, fundador da SaaStr, documentou que o agente da Replit apagou o banco de dados de produção dele durante um code freeze, apesar das instruções. Segundo Lemkin, o agente também gerou uma base de 4.000 registros fictícios; além disso, disse que não dava para reverter, embora Lemkin tenha escrito depois que o rollback funcionou (The Register, 21 de julho de 2025). A Fortune relatou que o incidente apagou dados de "more than 1,200 executives and over 1,190 companies", e que a Replit implantou a separação automática entre bancos de desenvolvimento e produção e rollbacks melhores, e estava desenvolvendo um modo "planning-only" (Fortune, 23 de julho de 2025). A lição é estrutural: "eu disse ao agente para não mexer" não é um modelo de segurança. O agente precisa trabalhar em um ambiente em que as operações perigosas sejam impossíveis, não apenas desaconselhadas.

Os riscos por ferramenta e o plano de correção estão no hub /fix (em inglês e espanhol). A versão longa dos três bugs que um repositório em branco repete está em onde os apps SaaS vibe-codados quebram e como proteger um app vibe-codado (ambos em inglês).

Quando migrar para uma base

O vibe coding é ideal para validar uma ideia, fazer um protótipo para mostrar ou uma ferramenta interna de baixo risco. Vale migrar quando alguma destas condições aparece:

• Você vai cobrar no cartão ou com MercadoPago e precisa de webhooks verificados e idempotentes.
• Você vai guardar dados de outras pessoas e um vazamento seria problema legal ou de confiança.
• Você tem mais de um cliente ou organização e precisa isolar os dados e gerenciar papéis e permissões.
• Um agente vai continuar mexendo no código e você quer que o compilador e o CI, e não uma instrução no prompt, barrem as mudanças que quebram as regras.

Para isso existe o useDeploy: um boilerplate SaaS pago em TypeScript (Next.js e Express sobre Bun, Prisma, BetterAuth) com multi-tenancy, RBAC e cobrança com Polar. Os pagamentos únicos com MercadoPago Checkout Pro e seus webhooks assinados estão resolvidos; o adapter do Stripe ainda é um scaffold que não cobra. Para trabalhar com agentes, traz camadas de arquitetura forçadas com ESLint, hooks do Claude Code e um AGENTS.md. Se você quer só as regras, sem o boilerplate, o kit aberto claude-code-guardrails tem os hooks e arquivos de exemplo.

O caminho completo, do mockup a um backend real, está em From a Lovable/Bolt mockup to a real backend (em inglês).

Perguntas frequentes