O que dá para salvar de um código gerado por IA

Por que o vibe coding funciona no começo#

Vibe coding é construir software conversando com uma IA, sem base de engenharia por baixo. O mercado gosta de tratar isso como pecado. Não é: é a forma mais barata que já existiu de descobrir se alguém quer o seu produto.

O caso que sustenta este artigo é exemplar nisso. Uma plataforma gamificada de desenvolvimento pessoal — tarefas, hábitos, metas, finanças, ranking, loja de moedas — construída pelos próprios fundadores conversando com uma IA, sem equipe técnica. Quando fomos chamados, o produto tinha 1.312 usuários ativos, planos mensais, trimestrais, semestrais e vitalícios sendo vendidos, mais de 40 tabelas no banco e oito funções de servidor. Nenhuma software house entrega isso na velocidade que dois fundadores entregaram conversando com uma IA.

O problema aparece depois, e não é onde as pessoas olham.

O que quebra quando o produto cresce#

A intuição diz que o problema do código gerado por IA é a qualidade do código: duplicação, arquivo gigante, nome ruim de variável. Isso existe — no caso acima havia um arquivo de 800 linhas e a regra de XP espalhada por cinco lugares diferentes — mas é dívida técnica, não risco. Dívida cobra juros; risco cobra tudo de uma vez.

O que cobra tudo de uma vez são três coisas, e nenhuma delas é sobre estética:

1. A fronteira: quem pode chamar o quê. No app auditado, as oito funções de servidor estavam configuradas para não exigir autenticação. Entre elas as de pagamento. Quem descobrisse a URL podia enviar uma requisição simulando compra aprovada e conceder a si mesmo assinatura vitalícia, creditar moeda ilimitada ou cancelar a assinatura de outra pessoa. Uma delas permitia apagar registros históricos do sistema.

E a mesma fronteira faltava dentro do banco: tarefas, hábitos, metas e os registros diários de sono, humor e produtividade de qualquer usuário podiam ser lidos por qualquer outro — parte deles sem nem estar logado. Uma tabela tinha regra que permitia a qualquer pessoa criar, editar e excluir registros de qualquer outra.

Repare que nenhum desses é um bug. O código fazia exatamente o que foi pedido. Ninguém pediu "e recuse quem chamar de fora" — e a IA não pergunta.

2. A conta que ninguém está olhando. O ambiente rodava na nuvem gerenciada da própria ferramenta de IA: a opção mais confortável, a mais cara e a menos visível. Havia cobrança diária que passou dias debitando sem ninguém perceber e compra de crédito acima do consumo real. Cerca de R$ 2.000 por mês para um produto que, depois da migração para banco gerenciado próprio mais hospedagem de front dedicada, passou a custar cerca de US$ 20 por mês — agora com backup automático, que a configuração anterior não garantia.

3. O que acontece no dia em que der errado. Nenhum teste automatizado, nenhum monitoramento de erro, nenhum ambiente de homologação e nenhuma documentação. Alteração ia direto para produção, em cima de usuário pagante; se um pagamento falhasse, ninguém era avisado; e o conhecimento de como a plataforma funcionava existia num único lugar — a conversa com a IA.

Não é um caso isolado. A Veracode testou mais de 100 modelos e mediu que 45% das amostras de código geradas introduziram vulnerabilidades do OWASP Top 10, com a taxa de aprovação em segurança estagnada em torno de 55% — e a conclusão mais desconfortável do relatório é que aumentar o tamanho do modelo não melhora a segurança. É problema sistêmico, não questão de esperar o próximo lançamento.

Como se faz o raio-x#

A ordem do diagnóstico é o que separa um relatório que gera decisão de um que gera ansiedade. A nossa é por consequência, não por gosto:

1. O que dá prejuízo direto — pagamento, assinatura, crédito, saldo. Aqui um furo vira dinheiro saindo hoje.
2. O que vaza dado pessoal — regra de acesso ao banco, dado sensível legível por terceiro, acesso sem autenticação.
3. O que impede crescer — regra de negócio no cliente, ausência de camada de servidor para integrar, limites de escala que já estão sendo pagos com recurso cortado do produto.
4. O que é dívida técnica — duplicação, arquivo grande, tipagem frouxa, falta de teste. Importa. Vem por último.

Cada achado sai no mesmo formato, e esse formato é metade do valor: criticidade · urgência · o que está configurado · a evidência no código · o ataque que isso permite · como fica depois. Achado sem evidência não entra. E o relatório precisa dizer também o que não se deve fazer agora — no caso acima, dissemos explicitamente que a arquitetura sem servidor próprio era adequada para aquela escala, e que trocá-la antes de fechar segurança e processo seria gastar dinheiro no lugar errado.

O que se salva, o que se move, o que se refaz#

A leitura da tabela é uma frase: o que a IA fez de bom fica em cima, e o que precisa mudar está embaixo. É por isso que a reescrita completa quase nunca se justifica — ela destrói a camada boa para consertar a camada ruim.

O detalhe que só existe em app feito com IA#

Este é o achado que não está em nenhum artigo sobre vibe coding, e é o mais prático de todos.

A stack de várias ferramentas de IA instala, por padrão, um service worker — a tecnologia que permite ao app funcionar como aplicativo instalado e abrir sem rede. Ótimo para experiência. Péssimo no dia em que você troca de banco de dados.

Quando migramos a infraestrutura, parte dos usuários mais ativos continuou abrindo uma versão do app congelada no cache do próprio aparelho — uma versão que apontava para o banco antigo. Eles seguiram usando o produto e gravando dados, só que no lugar errado. Nada foi perdido: os registros ficaram na base velha e foram resgatados por script e mesclados na nova. Mas a lição é dura e específica:

Migrar o banco de um app gerado por IA sem tratar o service worker deixa usuário escrevendo no lugar errado — e você só descobre quando o cache do primeiro aparelho expira.

O que funciona: subir a versão nova num endereço limpo (um subdomínio que nenhum navegador visitou, onde não existe cache), redirecionar o endereço antigo para ele, e revogar a chave pública do banco antigo para que qualquer app fantasma receba erro em vez de gravar em silêncio.

O que não é preciso fazer#

Esta é a seção mais importante, porque é onde o mercado erra com mais convicção.

Não é preciso reescrever tudo. O desfecho do caso que sustenta este artigo é o oposto: depois do diagnóstico, das correções e da migração, o cliente voltou a evoluir o próprio produto pela mesma ferramenta de IA. O que mudou foi o que estava embaixo.

Não é preciso trocar de ferramenta nem de arquitetura por princípio. Arquitetura sem servidor próprio — front conversando direto com um banco gerenciado — é adequada para muita coisa, e é o que permite dois fundadores chegarem a mil usuários sem equipe. O gatilho para mudar é escala e necessidade de integração, não gosto de engenheiro.

Não é a chave pública no repositório que vai te derrubar. Aqui mora o erro técnico mais comum: encontrar uma chave num arquivo versionado e declarar catástrofe. A documentação do Supabase é explícita — a chave publicável é "safe to expose online: web page, mobile or desktop app, GitHub actions, CLIs, source code", desde que a segurança em nível de linha esteja ativa em todas as tabelas. A camada de segurança real é a regra de acesso ao banco, não o sigilo dessa chave. Versionar credencial continua sendo prática ruim — sobrevive no histórico do Git, expõe a infraestrutura e facilita ataque direcionado. Só não é ela a emergência. A emergência é a chave secreta, que ignora todas as regras de acesso e nunca deve sair do servidor.

Não é preciso parar o produto para arrumar a base. Estabilizar o que está no ar e construir a fundação nova são frentes paralelas. As correções entram por branch e revisão, com o produto vendendo.

Não é auditoria de estilo. Lint, formatação e duplicação não entram no topo da lista. Se um diagnóstico chega com refatoração na primeira página e webhook desprotegido na décima, ele está vendendo retrabalho.

Perguntas frequentes#

Vou precisar jogar fora o que já foi feito com IA?#

Quase nunca. A interface, os fluxos e o modelo de dados costumam ser o ativo mais valioso do produto, porque foram validados com usuário real pagando. O que se troca fica embaixo: onde a regra de negócio roda, quem pode chamar cada endpoint, quem paga a infraestrutura e o que existe de backup. No app que auditamos, o produto continuou no ar durante e depois da correção.

Dá para continuar usando a IA depois de arrumar a base?#

Dá, e é o desfecho mais comum quando a correção é feita direito. Depois do diagnóstico e da migração, o cliente voltou a editar o próprio produto pela mesma ferramenta de IA — a diferença é que passou a fazer isso com o código na conta dele, com um caminho definido entre a branch de trabalho e a produção, e com as regras de acesso ao banco fechadas.

Quanto tempo leva uma auditoria de código gerado por IA?#

Para um produto de porte de MVP em produção, cerca de três semanas cobrem o diagnóstico e a aplicação das correções críticas. O diagnóstico em si é questão de dias; o que consome tempo é corrigir sem tirar o produto do ar. Achado que só é apontado e não é consertado não é diagnóstico, é orçamento.

O que preciso liberar de acesso?#

Código, banco de dados e o painel de infraestrutura — os três. Sem o banco não se avalia a regra de acesso, que é a camada de segurança real numa arquitetura sem servidor próprio; sem o painel de infraestrutura não se avalia custo, backup nem ambiente. Com só um dos três, o resultado é palpite.

Meu MVP feito com IA está seguro para receber dado de cliente?#

Assuma que não até alguém verificar. Nos produtos feitos com IA que vemos, o padrão é ausência de termo de uso e política de privacidade, dado pessoal legível por qualquer usuário autenticado, e nenhum registro de quem acessou o quê. Isso não é falha de código: é ausência de decisão sobre quem pode ver o quê — e ninguém pediu isso à IA.

Fontes#

• Veracode — 2025 GenAI Code Security Report — https://www.veracode.com/blog/genai-code-security-report/
• Veracode — Spring 2026 GenAI Code Security Update — https://www.veracode.com/blog/spring-2026-genai-code-security/
• Supabase — API Keys: Publishable vs Secret — https://supabase.com/docs/guides/api/api-keys

Próximo passo#

O produto deste artigo é real e está no ar: leia o case do Sistema Forja, o app feito com IA que auditamos com 1.312 usuários ativos. Se você construiu com IA e quer saber o que quebra antes de escalar, é exatamente o que fazemos em diagnóstico de vibe coding.