Seu protótipo construído com IA funciona. Está pronto para usuários reais?
Fez seu app com Lovable, Bolt ou Cursor? O que o código de IA costuma errar, as dez verificações antes do lançamento e quando reconstruir em vez de corrigir.
Nesta página · 5 seções
Principais pontos
- Construtores de apps com IA produzem protótipos convincentes rapidamente, mas em testes independentes cerca de 45% do código gerado por IA continha falhas de segurança.
- As lacunas são previsíveis: regras de acesso ao banco de dados, chaves expostas, confiança no input do cliente, pagamentos e backups.
- Corrija o protótipo quando o modelo de dados for sólido; reconstrua o núcleo e mantenha a interface quando não for.
Os construtores de apps com IA mudaram o que um fundador consegue fazer sozinho. Com Lovable, Bolt, Replit ou Cursor, você vai de uma ideia a um produto funcionando num fim de semana, navega por ele, mostra para clientes e até cobra deles. Essa é uma vantagem real, e você deve usá-la.
O problema é o passo seguinte. Um protótipo que funciona numa demo e um produto que guarda dados de usuários reais são coisas diferentes, e a diferença é quase invisível até algo dar errado. Este post mostra o que o código gerado por IA costuma errar, as dez verificações a fazer antes do lançamento e como decidir entre corrigir e reconstruir.
Quão seguro é o código gerado por IA?
Menos seguro do que parece. No estudo de 2025 da Veracode com mais de 100 modelos de linguagem em 80 tarefas de programação, o código gerado por IA introduziu vulnerabilidades de segurança em 45% dos casos. Os modelos não se protegeram contra cross-site scripting em 86% das tarefas relevantes e contra log injection em 88%. Uma atualização em março de 2026 mostrou a taxa de aprovação em segurança ainda travada em cerca de 55% (Veracode).
As falhas não são teóricas. Em 2025, um pesquisador divulgou a CVE-2025-48757: projetos gerados com o Lovable até 15 de abril de 2025 podiam ir ao ar com regras de acesso ao banco de dados ausentes ou insuficientes, permitindo que usuários não autenticados lessem dados pessoais, chaves de API e registros de pagamento direto do navegador.
Nada disso significa que as ferramentas de IA sejam ruins. Significa que elas otimizam para “funciona quando eu clico”, e segurança é principalmente sobre o que acontece quando alguém clica em coisas que você não previu.
O que costuma quebrar primeiro?
As mesmas cinco lacunas aparecem em quase todo app construído com IA, porque são invisíveis numa demo:
- Regras de acesso ao banco de dados. Apps construídos sobre Supabase ou Firebase falam com o banco de dados direto do navegador. Sem row level security ou regras rígidas, qualquer usuário logado, às vezes qualquer visitante, pode ler ou alterar todas as linhas.
- Segredos no frontend. Chaves de API de serviços pagos ou de acesso administrativo acabam no bundle JavaScript, onde qualquer pessoa pode copiá-las.
- Confiar no cliente. Preços, papéis e permissões decididos no navegador podem ser editados no navegador. Um usuário vira admin mudando um único campo.
- Pagamentos sem verificação. O app marca um pedido como pago porque o frontend disse que estava, em vez de confirmar com o webhook do provedor de pagamento.
- Sem backups, sem monitoramento. Ninguém fica sabendo quando algo falha, e não há como voltar atrás quando dados se perdem.
As 10 verificações antes de usuários reais
Você mesmo consegue fazer a maioria delas em poucos minutos cada. Se alguma falhar, corrija antes do lançamento:
| # | Verificação | Como testar |
|---|---|---|
| 1 | Usuários só veem os próprios dados | Entre como usuário A, copie o ID de um registro do usuário B e tente abri-lo |
| 2 | As regras do banco estão ativas em todas as tabelas | No Supabase, confirme que row level security está habilitado e tem policies em cada tabela |
| 3 | Nenhuma chave secreta no navegador | Procure no JavaScript do site (ferramentas de desenvolvedor do navegador) por “key”, “secret” e “token” |
| 4 | Os papéis são aplicados no servidor | Mude seu papel no armazenamento do navegador ou na requisição e veja se aparecem opções novas |
| 5 | Os pagamentos são confirmados por webhook | Verifique se os pedidos só ficam “pagos” depois que o provedor de pagamento chama o seu servidor |
| 6 | As entradas são validadas no servidor | Envie formulários com valores vazios, enormes ou que parecem scripts |
| 7 | Existe rate limit no login e no cadastro | Tente vinte senhas erradas seguidas |
| 8 | Os backups existem e restauram | Restaure o backup de ontem num banco de dados separado |
| 9 | Os erros são rastreados | Provoque um erro e confirme que alguém é notificado |
| 10 | Você é dono de todas as contas | Código, hospedagem, banco de dados, domínio e contas de pagamento no nome da sua empresa |
Se as quatro primeiras passarem, você está à frente da maioria dos apps construídos com IA. Se qualquer uma delas falhar, você tem um risco real de exposição de dados, não um problema de qualidade de código.
Corrigir o protótipo ou reconstruí-lo?
Depende do modelo de dados, não da cara do código. Código gerado por IA costuma ser verboso e repetitivo; isso, por si só, não é motivo para reconstruir.
Corrija quando:
- Você consegue explicar o modelo de dados em poucas frases, e ele bate com o funcionamento do negócio.
- Os problemas são as verificações acima: regras ausentes, chaves expostas, confiança no lado do cliente.
- Há um punhado de achados críticos, não dezenas.
Reconstrua o núcleo quando:
- Os mesmos dados vivem em vários lugares e ninguém sabe qual cópia é a verdadeira.
- Cada mudança quebra algo sem relação, e não há testes para dizer o quê.
- A segurança depende de o frontend se comportar, e corrigir isso significa reescrever a maior parte do backend.
Mesmo assim, raramente é preciso jogar tudo fora. O caminho usual é manter a interface, em que as ferramentas de IA são boas, e reconstruir direito o backend e a camada de dados por trás dela.
O que um engenheiro faz nas duas primeiras semanas?
Blindar um app construído com IA segue a mesma ordem de qualquer transição. Primeiro, garanta os acessos e as contas. Depois, torne o build e o deploy reproduzíveis. Em seguida, mapeie os fluxos que lidam com dinheiro e dados pessoais e corrija primeiro as lacunas de segurança nesses fluxos. Para um MVP típico construído com IA, a parte crítica cabe em cerca de duas semanas.
Perguntas frequentes
Software feito com vibe coding é seguro para lançar?
Não sem revisão. Nos testes da Veracode, cerca de 45% do código gerado por IA continha falhas de segurança, e incidentes reais já expuseram dados de usuários de apps construídos com ferramentas de IA. Um protótipo serve bem para demos e entrevistas; antes de usuários reais e pagamentos, verifique as regras de acesso ao banco de dados, os segredos, a validação no servidor e os backups.
Posso lançar um app construído com Lovable ou Bolt?
Pode, muitos fundadores fazem isso, mas trate o resultado como um primeiro rascunho. Confirme que row level security está habilitado com policies em todas as tabelas, que nenhuma chave secreta vai para o navegador e que os pagamentos são verificados no servidor. Essas três verificações fecham as lacunas mais comuns e mais danosas.
Quanto custa deixar um protótipo feito com IA pronto para produção?
Para um MVP típico, uma revisão de segurança e as correções críticas levam cerca de uma a duas semanas de um engenheiro sênior. Se o modelo de dados precisar ser reconstruído, conte com várias semanas a mais. A própria revisão mostra em qual caso você está, então comece por ela antes de se comprometer com um orçamento.