Vibe coding é o jeito de criar software descrevendo o que você quer para uma IA, em linguagem natural, e aceitando o código que ela gera sem ler. Se algo quebra, a mensagem de erro volta para o modelo até a aplicação funcionar. O termo foi cunhado em fevereiro de 2025 por Andrej Karpathy, cofundador da OpenAI e ex-diretor de IA da Tesla, e se espalhou tão rápido que o Collins Dictionary o escolheu como palavra do ano de 2025.
A prática resolve bem uma parte do trabalho: um protótipo que antes levava uma semana sai em uma tarde, e gente de produto, design e negócio consegue testar uma ideia sem esperar a fila do time de engenharia. O problema começa quando esse protótipo vira sistema de verdade, com usuário, dado pessoal e cobrança. Na pesquisa de desenvolvedores do Stack Overflow de 2025, cerca de 77% disseram que vibe coding não faz parte do seu trabalho profissional, e essa distância entre o uso pessoal e o uso em produção explica boa parte da discussão.
Este guia explica o que é vibe coding, em que situações ele funciona, quais riscos aparecem quando o código gerado chega à produção e o que precisa acontecer para um protótipo virar produto.
O que é vibe coding, na definição de quem criou o termo
No post original, Karpathy descreve um modo de programar em que ele "se entrega às vibes" e esquece que o código existe: pede mudanças, aceita todas as alterações sem revisar o diff e cola os erros de volta no modelo. Ele mesmo delimitou o uso: serve para projetos descartáveis de fim de semana, em que não importa se o código cresce além da compreensão de quem o pediu.
Simon Willison, um dos criadores do framework Django, deu a definição que ficou como referência técnica: vibe coding é construir software com um modelo de linguagem sem revisar o código que ele escreve. Por essa régua, usar IA para programar não é automaticamente vibe coding. Se o desenvolvedor lê, testa e consegue explicar cada linha antes do commit, ele está fazendo programação assistida por IA, que é outra prática, com outro nível de risco.
A ferramenta pode ser a mesma nos três modos. O que muda é quem lê o código e o que precisa passar antes do deploy.
A ferramenta, portanto, não define o modo. Os construtores de aplicação como Lovable, Bolt, v0 e Replit Agent geram um app inteiro a partir de uma descrição e convidam ao vibe coding. Já os agentes que trabalham dentro do repositório, como Claude Code, Cursor e o agente do GitHub Copilot, podem ser usados nos dois modos. No uso do Claude Code em engenharia de dados, por exemplo, o agente propõe o plano e o diff, e uma pessoa decide o que entra.
O vocabulário também mudou. Em fevereiro de 2026, um ano depois do post original, Karpathy passou a preferir o termo agentic engineering para o trabalho profissional com agentes, em que a pessoa orquestra e supervisiona em vez de digitar o código. O vibe coding continuou existindo com o sentido original: gerar sem revisar.
Onde o vibe coding funciona
O vibe coding rende quando o custo de errar é baixo e a vida útil do código é curta. Um protótipo clicável para validar uma ideia com cinco clientes, uma tela para mostrar ao comitê de investimento ou um script que organiza arquivos no seu computador são casos em que velocidade vale mais do que manutenção. Se o resultado quebrar, ninguém perde dado e ninguém fica sem atendimento.
O critério prático é perguntar o que acontece se o código tiver uma falha que ninguém viu. A tabela abaixo organiza os casos mais comuns.
| Cenário | Vibe coding resolve? | O que exigir antes de seguir |
|---|---|---|
| Protótipo para validar ideia com usuários | Sim | Nada, desde que use dados fictícios |
| Demo para diretoria ou investidor | Sim | Não conectar a sistemas reais |
| Script pessoal ou automação local | Sim, com cuidado | Rodar sem credenciais de produção |
| Ferramenta interna usada por um time | Em parte | Login, controle de acesso e revisão do código |
| Aplicação com dado de cliente ou pagamento | Não | Revisão, testes, varredura de segurança e regras de acesso ao banco |
| Agente com permissão de escrita em produção | Não | Ambientes separados, permissão mínima e aprovação humana |
Repare que a linha divisória é o dado real. Enquanto o protótipo roda com dados inventados e fora da rede da empresa, o risco fica contido. Quando ele recebe dado pessoal, chave de API ou acesso ao banco de produção, passa a valer a mesma régua de qualquer desenvolvimento de software que vai ao ar.
Os riscos do vibe coding em produção
Os riscos já foram medidos em estudo controlado e já apareceram em incidente público. Três deles concentram a maior parte dos problemas.
Código gerado com vulnerabilidade conhecida
A Veracode testou mais de 100 modelos em 80 tarefas de programação sensíveis a segurança e publicou o resultado em julho de 2025: em 45% dos casos, o código gerado introduziu uma vulnerabilidade da lista OWASP Top 10. As falhas mais frequentes foram cross-site scripting e injeção em log. A edição de 2026 do mesmo relatório mostrou que a taxa de aprovação em segurança ficou em 56%, praticamente igual à do ano anterior, mesmo com modelos mais capazes. Em outras palavras, o modelo escreve código que funciona, e funcionar não garante que o código esteja seguro.
O caso mais conhecido aconteceu no Lovable. Em 2025, um pesquisador analisou 1.645 aplicações da vitrine da plataforma e encontrou 170 com regras de acesso ao banco mal configuradas, expondo e-mails, telefones, dados de pagamento e chaves de API. A falha virou a CVE-2025-48757, com nota 9,3 de 10 na escala CVSS, faixa considerada crítica. A Lovable contesta o registro, com o argumento de que cada cliente responde pelos dados da própria aplicação. A causa foi a ausência de Row Level Security, o recurso do banco que limita quais linhas cada usuário pode ler, documentado pelo Supabase. É o tipo de configuração que quem trabalha com Supabase via CLI revisa por hábito, e que quem não lê o código nem sabe que existe.
Agente com permissão demais
Em julho de 2025, Jason Lemkin, fundador da SaaStr, relatou que o agente do Replit apagou o banco de produção do projeto dele durante um teste, mesmo com a instrução explícita de congelar o código. O CEO do Replit classificou o episódio como inaceitável e anunciou a separação automática entre banco de desenvolvimento e banco de produção. O agente não precisou de um invasor para causar o estrago: ele tinha a permissão e a usou.
O mesmo raciocínio vale quando a aplicação gerada usa um modelo de linguagem por dentro. Um app que lê e-mails, documentos ou páginas da web fica exposto a prompt injection em agentes de IA, e a lista OWASP Top 10 for LLM Applications cataloga esse e outros riscos, como agência excessiva e tratamento inseguro da saída do modelo.
Produtividade percebida maior que a medida
O terceiro risco é de gestão. Em um estudo controlado de 2025, o instituto METR acompanhou 16 desenvolvedores experientes de projetos open source em 246 tarefas. Com IA, eles levaram 19% mais tempo, embora tenham saído do experimento convencidos de que tinham ficado 20% mais rápidos. A atualização de 2026 do mesmo estudo encontrou sinais de ganho, mas o próprio METR classificou o resultado como pouco confiável, porque muitos participantes passaram a recusar tarefas sem IA. A lição para quem decide é medir o ciclo inteiro, incluindo revisão e correção, antes de assumir o ganho que a equipe relata.
Como levar um protótipo de vibe coding para produção
O protótipo feito por vibe coding pode virar produto, desde que passe pelos mesmos controles de qualquer código escrito por uma pessoa. Na prática, são cinco passos.
- Dar dono ao código. Alguém do time lê o código gerado, entende a arquitetura e responde por ele. Se ninguém consegue explicar um trecho, ele é reescrito ou removido.
- Escrever a especificação que faltou. Requisitos, regras de negócio e critérios de aceite vão para um documento que orienta as próximas gerações do agente. É a base do spec-driven development com agentes de IA, e o GitHub mantém um kit aberto para esse fluxo, o Spec Kit.
- Cobrir com testes e CI. Os testes derivados da especificação rodam a cada mudança, e nenhum diff do agente entra sem passar por eles.
- Fazer a varredura de segurança. Análise estática, busca de segredos no repositório, checagem de dependências e revisão das regras de acesso ao banco, com atenção especial a autenticação e autorização.
- Separar ambientes e reduzir permissões. O agente trabalha em desenvolvimento, com credencial de leitura sempre que possível, e qualquer ação irreversível em produção exige aprovação humana.
As cinco etapas que transformam um protótipo gerado por IA em código que pode ir ao ar.
Nenhuma dessas etapas proíbe a IA. O agente continua escrevendo boa parte do código, como mostra o avanço da IA no desenvolvimento de software. A diferença é que, a partir daqui, o que ele gera passa por revisão, teste e controle de acesso antes de chegar ao usuário.
O vibe coding encurtou a distância entre ter uma ideia e ver a ideia funcionando, e isso tem valor real para quem precisa validar rápido. O cuidado está em reconhecer o momento em que o protótipo deixa de ser descartável. A partir dele, o código gerado precisa de dono, especificação, testes e segurança, como qualquer outro.
Se sua empresa está transformando protótipos feitos com IA em produtos que lidam com dados reais, nossos especialistas podem ajudar a estruturar a melhor arquitetura para o seu contexto. Fale com a nossa equipe e avance na maturidade dos seus dados.
Perguntas frequentes sobre vibe coding
O que é vibe coding? Vibe coding é criar software pedindo o código a uma IA em linguagem natural e aceitando o resultado sem revisar o que foi gerado. Quando algo falha, o erro volta para o modelo até a aplicação funcionar. É útil para protótipos e projetos descartáveis, mas exige revisão, testes e varredura de segurança antes de chegar à produção.
Quem criou o termo vibe coding? O termo foi criado por Andrej Karpathy, cofundador da OpenAI e ex-diretor de IA da Tesla, em um post publicado em fevereiro de 2025. Ele descreveu um modo de programar em que aceita as mudanças da IA sem ler o diff. O Collins Dictionary escolheu vibe coding como palavra do ano de 2025.
Vibe coding é seguro para usar em produção? Sem revisão, não. A Veracode encontrou vulnerabilidades da lista OWASP Top 10 em 45% das tarefas de programação feitas por modelos de IA em 2025. Para ir à produção, o código gerado precisa de um responsável, testes automatizados, varredura de segurança, regras de acesso ao banco e ambientes separados.
Qual a diferença entre vibe coding e programação assistida por IA? A diferença está na revisão. No vibe coding, ninguém lê o código gerado. Na programação assistida por IA, o desenvolvedor usa a mesma ferramenta, mas revisa, testa e entende cada trecho antes do commit. A ferramenta pode ser a mesma, como Claude Code ou Cursor. O que muda é o processo em volta dela.
Quais ferramentas são usadas para vibe coding? As mais associadas ao vibe coding são os construtores de aplicação que geram um app inteiro a partir de uma descrição, como Lovable, Bolt, v0 e Replit Agent. Agentes de código como Claude Code, Cursor e GitHub Copilot também permitem vibe coding, mas costumam ser usados com revisão em times de engenharia.
