App feito com vibe coding: o que acontece quando chegam usuários reais

Um app feito com vibe coding é um app construído principalmente dando prompts a uma ferramenta de IA e aceitando o que ela gera. Ele pode parecer pronto e ainda assim se comportar mal quando desconhecidos começam a usar, pagar e forçar o app de formas que você nunca testou.

Este artigo trata do que costuma quebrar quando chegam usuários reais, por que o código fica frágil e como decidir entre consertar e reescrever. Sou um engenheiro sênior brasileiro, e é isso que eu procuro quando leio essas bases de código.

O que é um app feito com vibe coding?

É um software em que quem conduz a construção é a pessoa que descreve a funcionalidade, não um desenvolvedor lendo cada linha. Ferramentas como Lovable, Bolt e Base44, muitas vezes combinadas com Supabase, produzem um front-end funcionando, um banco de dados e alguma lógica a partir de prompts.

Isso é realmente útil para protótipos e validação inicial. O problema é que a ferramenta otimiza para algo que funcione no caminho feliz. Ninguém revisou casos de borda, permissões ou modos de falha, a não ser que você tenha revisado.

Também ajuda saber quem é responsável pelo quê. O construtor protege a própria infraestrutura e as próprias contas. Você, como dono do app, é responsável por quem pode ler quais dados, pelas chaves no navegador, pela confirmação de pagamentos e pelos backups.

O que costuma quebrar primeiro com usuários reais?

Na minha experiência, raramente é a interface. Quatro verificações cobrem a maior parte do risco antes de os usuários reais chegarem.

1. Regras de acesso a dados

Apps construídos com Lovable têm mostrado um padrão de regras fracas de row level security (RLS) no Supabase. Se as regras estiverem ausentes ou permissivas demais, um usuário logado pode conseguir ler ou editar os registros de outro usuário só alterando uma requisição. Funciona perfeitamente nos seus testes, porque você só vê os seus próprios dados.

Um exemplo público relacionado: em julho de 2025, pesquisadores da Wiz descobriram que o Base44, o construtor que pertence à Wix, permitia que um atacante se cadastrasse em apps que deveriam ser privados usando apenas o ID do app. Foi corrigido em um dia, mas mostra por que o controle de acesso merece a sua própria atenção.

2. Chaves expostas

Chaves secretas colocadas no código do front-end ficam visíveis para qualquer pessoa que abra as ferramentas do navegador. Tudo o que precisa continuar secreto pertence a um servidor, não ao bundle do cliente.

3. Confirmação de pagamento

Um padrão comum é confiar no redirecionamento do navegador depois do checkout como prova de pagamento. A fonte confiável é um webhook do Stripe verificado no seu servidor. Sem isso, você tem pedidos pagos que nunca são ativados, ou pedidos ativados que nunca foram pagos, e eventos duplicados podem criar pedidos duplicados.

4. Backups

Pergunte se você consegue restaurar o seu banco de dados para o estado de ontem, e se já tentou fazer isso alguma vez. Muitos fundadores descobrem a resposta durante um incidente.

Desempenho é o quinto problema, mais silencioso. Queries que buscam tudo e filtram no navegador parecem rápidas com dez linhas e lentas com dez mil.

Por que pequenas mudanças começam a quebrar outras funcionalidades?

Esse é o sintoma que os fundadores mais descrevem: você pede à IA para ajustar uma coisa e algo sem relação para de funcionar. Normalmente há algumas causas.

• Nenhum teste. Nada avisa que uma mudança quebrou um fluxo existente até um usuário encontrar o problema.
• Lógica duplicada. A mesma regra, como um cálculo de preço, está copiada em vários componentes. Você corrige uma cópia e as outras continuam erradas.
• Arquivos emaranhados. Componentes grandes misturam exibição, busca de dados e regras de negócio, então qualquer edição mexe nos três.
• Perda de contexto. A IA vê só uma parte do projeto de cada vez, então pode criar um novo helper em vez de reaproveitar o existente, ou reescrever código sem saber que outras partes dependem dele.

Nada disso significa que a ferramenta é ruim. Significa que o código não tem rede de segurança, e cada prompt é uma aposta em um sistema que ninguém entende por completo.

Devo consertar o app feito com vibe coding ou reescrevê-lo?

Comece pela regra que eu sigo: código gerado por IA é um primeiro rascunho. Um rascunho vale a pena ser editado antes de ir para o lixo. Corrigir os problemas de maior risco no código existente vem antes de qualquer reescrita.

Uma reescrita joga fora comportamentos que já funcionam, incluindo pequenas decisões que você esqueceu e das quais os usuários dependem. Ela também leva mais tempo do que parece e atrasa todo o resto.

Continuar no construtor às vezes é a escolha certa, principalmente enquanto você ainda está testando a demanda e não lida com dados sensíveis nem pagamentos. Saia quando precisar de controle, não por uma sensação vaga de que produtos de verdade vivem em outro lugar.

Também já vi o caso em escala maior. Liderei a migração completa de uma plataforma de candidatura automática a vagas, que estava no ar, de uma stack legada para uma nova, enquanto os usuários continuavam usando. A lição que tirei foi evitar parar tudo para reconstruir. O mesmo raciocínio incremental vale para um app feito com vibe coding.

Como deixar o código sustentável para um desenvolvedor?

O objetivo é que um engenheiro novo consiga abrir o repositório, rodar e mudar o código sem medo. Uma ordem prática:

1. Leve o código para o GitHub. Código construído no Lovable pode ser levado para o GitHub e para a sua própria hospedagem, o que dá a você histórico, branches e propriedade.
2. Separe os ambientes. Mantenha desenvolvimento e produção separados, com segredos em variáveis de ambiente, nunca no repositório.
3. Corrija os quatro riscos. Aperte as regras de dados, leve os segredos para o servidor, confirme pagamentos por webhooks verificados, configure backups testados.
4. Adicione testes onde estão o dinheiro e as permissões. Checkout, cadastro e controle de acesso primeiro. Não corra atrás de cobertura total.
5. Consolide a lógica duplicada. Coloque as regras de negócio em um só lugar e reaproveite.
6. Escreva um README curto. Como rodar, onde está o deploy, o que cada serviço faz.

Pedir ao construtor com IA para fazer tudo isso não basta por si só. Regras de dados, chaves e fluxos de pagamento são justamente o que essas ferramentas tendem a errar, e um scanner de segurança genérico também deixa passar lógica de negócio, como o tratamento de webhooks do Stripe e pedidos duplicados. Uma pessoa precisa ler esses caminhos.

Quando um engenheiro humano deve assumir?

Minha regra prática, que é uma estimativa e não um limite rígido, é envolver um engenheiro antes que qualquer uma destas coisas aconteça:

• Você começa a cobrar dinheiro de verdade.
• Você armazena dados pessoais ou sensíveis de pessoas reais.
• Cada correção por prompt causa uma nova regressão.
• Você não consegue explicar onde estão os seus dados nem como restaurá-los.
• Um cliente ou investidor pergunta sobre segurança ou due diligence.

A maior parte do risco é encontrada com algumas verificações focadas, não com uma auditoria completa, e o custo de corrigir cresce quando os usuários e os pagamentos estão no ar. Uma revisão curta cedo costuma sair mais barata do que um incidente depois.

Quer uma segunda opinião sobre o seu app?

Se você tem um app feito com vibe coding prestes a receber usuários reais, mande um email para me@filipeeduardo.dev com o link e uma linha sobre o que ele faz, e eu digo o que verificaria primeiro.