Vibe coding é ruim? 5 riscos reais e como evitá-los

O vibe coding é seguro? Depende do que você constrói

O vibe coding é seguro o suficiente para projetos pessoais, protótipos e páginas simples, e arriscado para qualquer coisa que guarde contas, pagamentos ou dados pessoais, a menos que alguém revise.

A maioria dos primeiros projetos fica nas duas primeiras linhas, que é exatamente onde o vibe coding funciona bem. Os cinco problemas do vibe coding abaixo pesam mais quanto mais para baixo na tabela você está.

Risco 1: falhas de segurança do vibe coding que você não vê

Código que funciona e código seguro são coisas diferentes, e as pesquisas sobre os riscos de segurança do vibe coding dizem isso com todas as letras.

O relatório de julho de 2026 da Veracode encontrou a segurança "praticamente inalterada" desde 2025, mesmo com os modelos melhorando em escrever código que roda, e modelos especializados em código não eram mais seguros que os gerais. No estudo SusVibes, o SWE-Agent com o Claude 4 Sonnet produziu soluções que funcionavam em 57% das vezes, mas soluções seguras só em 11,8%, e acrescentar dicas de segurança ao pedido não resolveu.

O achado sobre a Lovable veio de pesquisadores que analisaram projetos em março de 2025 e publicaram o problema em maio como CVE-2025-48757, um identificador público para uma vulnerabilidade conhecida. Esses apps funcionavam. O problema era a row level security (RLS), as regras dentro de um banco de dados que decidem quais linhas cada visitante pode ver ou mudar.

A Lovable e o Bolt podem se conectar ao Supabase, um serviço de banco de dados popular. O próprio Security Advisor do Supabase classifica uma tabela sem essas regras como um ERROR chamado Table publicly accessible, porque qualquer pessoa com a URL do seu projeto pode então ler, editar e apagar tudo o que está nela.

• Use serviços comprovados para logins e pagamentos, em vez de deixar a IA inventar os seus.
• Mantenha chaves secretas fora do código do navegador. Uma chave de API é uma senha que deixa um software usar um serviço pago, então guarde nas variáveis de ambiente da sua hospedagem.
• Confira cada pacote novo. Modelos que escrevem código às vezes citam pacotes complementares que não existem: num estudo do USENIX Security 2025 com 576.000 amostras de código, modelos comerciais fizeram isso em pelo menos 5,2% das vezes. Atacantes podem publicar malware com esses nomes, então peça para a IA confirmar que cada pacote novo é real e muito usado antes de instalar qualquer coisa.
• Faça a IA atacar o próprio app com o prompt abaixo e depois corrija o que ela encontrar.
• Peça uma revisão humana para qualquer coisa nas duas últimas linhas da tabela.

Audite este projeto em busca de problemas de segurança antes do lançamento. Confira:
1. Cada tabela do banco de dados: um visitante sem login consegue ler, adicionar ou mudar linhas?
2. Qualquer chave de API ou senha visível no código do navegador ou em arquivos com commit.
3. Formulários: o que acontece com entradas muito longas, vazias ou maliciosas?
4. Páginas ou endpoints que funcionam sem login mas não deveriam.
Explique cada achado em linguagem simples, ordene por gravidade e
não mude nenhum código até eu aprovar as correções.

Rodamos exatamente este prompt no Claude Code num pequeno app de agendamento de demonstração, montado com os erros com que apps feitos com vibe coding costumam ir ao ar: uma tabela no Supabase, um formulário público e um botão de admin escondido. Ele leu os quatro arquivos, não mudou nada e classificou sete achados em 38 segundos: três críticos, dois altos, um médio e um baixo. Os dois primeiros são os mesmos riscos de segurança do vibe coding que a pesquisa acima descreve, uma chave secreta no código do navegador e uma tabela sem regras de acesso.

Ele também responde diretamente a cada pergunta que você fez. Para a pergunta 1, detalhou o que um desconhecido sem login consegue fazer com a tabela de agendamentos, que é exatamente a falha por trás da CVE-2025-48757:

Termine com um pedido como "Me dê um resumo de uma tela que eu possa colar no meu checklist de lançamento: uma linha por achado, gravidade primeiro" para ter a lista ordenada mostrada no topo desta página, depois aprove as correções uma de cada vez e rode a auditoria de novo.

A Lovable é segura?

Mais segura do que era. A Lovable agora roda um Quick scan toda vez que você publica, e ele procura exatamente essas falhas: regras de acesso ao banco de dados, pacotes com vulnerabilidades conhecidas e servidores MCP que o seu app expõe sem login. Ele não avalia a lógica do seu próprio app, e a documentação de segurança da Lovable diz que as ferramentas não garantem segurança completa e sugere uma revisão profissional para apps que lidam com dados sensíveis.

Risco 2: a IA faz algo destrutivo

Um dos desastres de vibe coding mais conhecidos: em julho de 2025, o fundador da SaaStr, Jason Lemkin, relatou que o agente de IA da Replit apagou o banco de dados de produção dele, os dados ao vivo de que o projeto dependia, apesar das instruções para não mudar nada sem permissão, como noticiou o The Register. O agente tinha acesso aos dados ao vivo, e nada técnico o impediu.

• Separe dados de teste e dados reais. Construa em cima de uma cópia e só conecte o banco real no lançamento.
• Mantenha um histórico de versões que você controla. Faça commit no Git depois de cada etapa que funciona. Os checkpoints do Claude Code voltam as edições de arquivo dele, mas não as mudanças feitas pelos comandos que ele roda.
• Escolha um modo que pergunta antes. As versões recentes do Claude Code no terminal e no VS Code começam no modo Auto, em que um classificador em segundo plano aprova as ações por você. Para trabalho sensível, aperte Shift+Tab ou use o seletor de modo do desktop para mudar para Manual, que pergunta antes de editar arquivos ou rodar comandos.

Risco 3: custos que sobem aos poucos

A maioria das ferramentas de vibe coding cobra por uso, então o taxímetro roda enquanto você ajusta. O momento caro é o loop de depuração: a IA não consegue corrigir um bug, você pede de novo, e cada tentativa custa.

• Planeje antes de construir. Um plano claro significa menos reconstruções caras.
• Pare depois de duas correções que falharam. Use o prompt abaixo em vez de pedir pela terceira vez.
• Configure alertas de orçamento que agem. No Vercel Pro, um valor de Spend Management só avisa você, a menos que você também ative Pause Production Deployments.
• Conheça os limites do seu plano. Veja limites de uso do Claude Code e preço do Claude Code.

Pare de mudar o código. Explique em linguagem simples o que você acha
que está causando este problema, o que já tentou e por que não funcionou.
Depois me dê dois jeitos diferentes de corrigir, com os riscos de cada um,
e espere eu escolher.

Risco 4: dívida técnica que ninguém consegue manter

Software precisa de manutenção, e código que ninguém entende se acumula como dívida técnica: cada mudança fica mais lenta e mais arriscada. Em dezembro de 2025, a equipe do React divulgou uma falha nos React Server Components (CVE-2025-55182) que deixava atacantes rodarem código nos servidores afetados, com nota 10.0, o máximo na escala padrão de gravidade.

Apps construídos com frameworks como o Next.js precisaram atualizar na hora, e a equipe do React avisou para não confiar nas proteções temporárias dos provedores de hospedagem. Um app feito com vibe coding sem ninguém acompanhando avisos como esse simplesmente continua exposto.

• Escolha a stack mais simples. Apps sem servidor não foram afetados por essa falha, então siga a abordagem de HTML simples de criar um site com IA sempre que ela servir.
• Documente. Peça para a IA um README e um arquivo CLAUDE.md que expliquem como o projeto funciona e como mudá-lo.
• Marque uma revisão mensal. Peça para a sua ferramenta de IA procurar dependências desatualizadas ou vulneráveis e atualizá-las uma por vez.
• Evite ficar preso. Garanta que você consegue exportar o código ou sincronizá-lo com o GitHub.

Risco 5: falhas de privacidade e legais

Até uma página simples cria obrigações quando coleta nomes, e-mails ou telefones. As leis de privacidade de onde vivem os seus clientes, como a LGPD no Brasil, podem exigir um aviso de privacidade, consentimento para marketing e limites para o uso dos dados.

• Colete só o que precisa. Um nome e um telefone podem bastar para um agendamento.
• Diga o que você coleta. Publique uma página de privacidade curta que explique o que o formulário recolhe e para onde vai.
• Confira o seu rastreamento. Ferramentas de análise e pixels de anúncio podem exigir um banner de consentimento, dependendo de onde estão os seus visitantes.
• Trate textos legais da IA como rascunho. A IA pode rascunhar uma política de privacidade ou termos, mas não pode assumir a responsabilidade por eles.

Vibe coding é ruim para uma pequena empresa? Prós e contras

Para muitas pequenas empresas, a alternativa a uma ferramenta feita com vibe coding não é um app cuidadosamente projetado. É nada, ou um site de modelo de que elas não gostam e não conseguem mudar. Veja os prós e contras do vibe coding lado a lado:

Quando você revisa e testa o que a IA constrói, já não está fazendo vibe coding puro, como explica o guia sobre o que é vibe coding. Quando construo para clientes com IA, a ferramenta nunca é o que deixa o resultado seguro. As conferências chatas em volta dela é que deixam, e é para isso que serve o checklist abaixo.

Sinais de alerta e o que fazer

O checklist de segurança do vibe coding

Antes de construir

Enquanto constrói

Antes do lançamento

Depois do lançamento

O que fazer agora

Encontre o seu projeto atual ou planejado na tabela de risco e passe pelas seções correspondentes do checklist antes de publicar qualquer coisa. Se ele estiver nas duas últimas linhas, reserve orçamento para uma revisão de um desenvolvedor agora, e não depois do lançamento.

Para comparar ferramentas pelas proteções e pelos preços, veja as melhores ferramentas de vibe coding. O curso Builders inclui aulas sobre o básico de segurança, acessibilidade e privacidade para sites que você constrói com IA.