Um app feito com vibecoding pode ir para produção, e muitos já estão no ar com usuário real. O que decide se ele está pronto são seis pontos que a ferramenta não confere sozinha: autenticação, regras de acesso ao banco, chaves expostas no navegador, backup, custo de infraestrutura e LGPD. O app funcionar na demonstração diz pouco sobre qualquer um deles.
O tema cresceu rápido. As buscas por vibecoding cresceram mais de 50% no último ano, segundo o Google Keyword Planner, e boa parte de quem busca já passou do protótipo: tem gente cadastrada, às vezes gente pagando, e começou a se perguntar o que existe por baixo do que a IA escreveu.
Este artigo mostra o que costuma quebrar, como diferenciar protótipo de produto em produção e um checklist para saber onde o seu app está.
O que é vibecoding, e por que ele funciona tão bem no começo
Vibecoding é construir software conversando com uma ferramenta de IA. A pessoa descreve a tela, a regra e o fluxo, e ferramentas como Lovable, Bolt, Cursor, Claude Code e Replit escrevem o código, montam o banco e publicam.
Para validar uma ideia, é difícil achar coisa melhor. O que antes pedia semanas de um time agora sai em dias, e o fundador consegue testar com cliente real antes de gastar com desenvolvimento.
O problema aparece na transição. A ferramenta otimiza para o app funcionar diante de quem está pedindo, e segurança é justamente a parte que não aparece na tela. Tabela sem regra de acesso carrega igual. Chave exposta no navegador faz a integração funcionar igual. Tudo parece pronto até alguém olhar por outro ângulo.
O código funciona, e mesmo assim pode não estar seguro
Há dado público sobre isso. O relatório GenAI Code Security Report da Veracode, de 2025, testou código gerado por mais de 100 modelos de linguagem e encontrou falhas de segurança da lista OWASP Top 10 em 45% dos testes. No mesmo estudo, a correção de sintaxe passou de 95%.
Na prática, o código compila, a tela abre e o fluxo termina. A falha fica escondida numa camada que só aparece para quem procura por ela, e quem procura primeiro nem sempre é o dono do app.
O que costuma quebrar quando o app vai para produção
Autenticação
Login funcionando é só metade do trabalho. A outra metade é o servidor conferir, em cada chamada, se aquela pessoa pode fazer aquilo. Em app gerado por IA é comum a verificação existir na tela e faltar na rota que a tela chama. Quem chama a rota direto, sem passar pela interface, passa também pela verificação.
Também vale olhar recuperação de senha, expiração de sessão e se existe limite de tentativas no login.
Regras de acesso ao banco
É o ponto mais sensível. Muitos desses apps usam Supabase ou Firebase, que expõem o banco para o navegador e dependem de regras (no Supabase, as políticas de Row Level Security) para decidir quem lê o quê.
Sem essas regras, a chave pública que vai no navegador basta para ler tabelas inteiras. Em 2025, o pesquisador Matt Palmer documentou a falha CVE-2025-48757: de 1.645 apps feitos com Lovable analisados, 170 tinham o banco exposto dessa forma, com dados de usuários acessíveis sem login.
Chaves expostas no navegador
Chave de pagamento, de envio de e-mail, de API de IA. Quando ela vai no código que roda no navegador, qualquer pessoa com as ferramentas de desenvolvedor abertas consegue copiar. O prejuízo mais comum é a conta de uso de terceiros, que dispara em poucas horas quando alguém descobre a chave.
A regra é simples: chave secreta mora no servidor, em variável de ambiente, e nunca no repositório.
Backup e separação entre teste e produção
Em julho de 2025, Jason Lemkin, fundador da SaaStr, relatou publicamente que o agente de IA do Replit apagou o banco de produção do app que ele construía, durante um período em que ele tinha pedido para nada ser alterado. O caso virou referência porque junta os dois problemas: a ferramenta tinha acesso direto à produção, e não havia um ambiente separado para testar mudanças.
A pergunta a fazer sobre o próprio app é direta: se o banco sumir hoje, de quando é a última cópia, e alguém já testou restaurar essa cópia?
Custo de infraestrutura
Consulta sem índice, imagem sem compressão, função que roda a cada clique. Com dez usuários ninguém sente. Com alguns milhares, a conta do provedor cresce mais rápido que a receita. Vale conferir as consultas mais frequentes e configurar alerta de gasto no provedor antes que a fatura avise.
LGPD
A Lei 13.709/2018 vale para qualquer app que trate dado pessoal, sem importar como o código foi escrito. Quando um incidente pode gerar risco ou dano relevante aos titulares, a Resolução CD/ANPD nº 15/2024 pede comunicação à ANPD e aos titulares em até três dias úteis (seis, para agente de tratamento de pequeno porte). A sanção pode chegar a 2% do faturamento, limitada a R$ 50 milhões por infração, conforme o artigo 52 da lei.
Para app pequeno, o risco mais concreto costuma ser outro: perder a confiança de quem pagou quando o vazamento aparece.
Protótipo e produção pedem coisas diferentes
| Ponto | Suficiente no protótipo | Necessário em produção |
|---|---|---|
| Autenticação | Login que funciona | Permissão conferida no servidor, em toda rota |
| Banco | Tabelas que carregam | Regra de acesso por usuário em cada tabela |
| Chaves | No código, para testar rápido | Em variável de ambiente, fora do navegador |
| Backup | Nenhum | Cópia automática e restauração testada |
| Ambientes | Um só | Teste separado de produção |
| Custo | Plano gratuito | Alerta de gasto e consultas revisadas |
| Dados pessoais | Dado fictício | Base legal, política de privacidade e plano de incidente |
Checklist: o seu app está pronto?
Dá para fazer uma primeira leitura em uma tarde. Se algum item abaixo não tem resposta segura, ele é o primeiro a resolver:
- Toda tabela do banco tem regra de acesso ativa, e alguém testou acessar dado de outro usuário e foi bloqueado.
- Nenhuma chave secreta aparece no código do navegador nem no histórico do repositório.
- Toda rota que altera dado confere no servidor quem está chamando.
- Existe backup automático, e uma restauração já foi feita de verdade.
- Mudança nova é testada num ambiente separado antes de chegar em produção.
- Existe alerta de gasto configurado no provedor de infraestrutura.
- Dependências estão atualizadas e sem vulnerabilidade conhecida.
- Existe registro (log) suficiente para saber o que aconteceu depois de um erro.
- A política de privacidade descreve o que o app coleta de fato.
- Alguém além da ferramenta que escreveu o código leu as partes críticas.
O detalhe de cada item, com a lista OWASP Top 10 como referência, está no guia de segurança de aplicativo antes de escalar.
Quando a revisão deixa de ser opcional
Três situações mudam o peso da decisão. A primeira é ter gente pagando: a partir daí, falha vira reembolso, cancelamento e reputação. A segunda é guardar dado de terceiro, como documento, dado de saúde ou dado financeiro de cliente. A terceira é captar investimento ou vender a empresa, porque alguém vai abrir o repositório e fazer as mesmas perguntas deste artigo.
Nas três, o custo de revisar é pequeno perto do custo de descobrir o problema pelo usuário. E quando o app cresce a ponto de precisar de um time para evoluir, os mesmos critérios de como escolher uma software house passam a valer, a começar por quem fica com o código.
O que uma revisão humana olha primeiro
Rodar um scanner ajuda, mas ele lista sintomas sem ordem de prioridade. Na revisão que a gente faz, a ordem segue o tamanho do estrago possível: primeiro o banco e as regras de acesso, depois autenticação e rotas, depois chaves e segredos, e só então custo e desempenho.
Cada ponto encontrado sai com três informações: o que está exposto, o que precisa mudar e se a correção pode esperar ou não. O que é crítico a gente fecha junto. O resto fica documentado, em linguagem que o fundador entende, para que o conhecimento sobre o próprio app fique com ele e não com quem fez a revisão.
Vibecoding encurtou o caminho até o primeiro usuário. O trecho entre o primeiro usuário e o milésimo continua pedindo o mesmo cuidado de sempre, e ele cabe numa revisão feita no momento certo.
