Seu MVP foi feito com IA e travou: o que quebra e como resolver

Você gerou o produto em um fim de semana. Funcionou. Colocou no ar, apareceram usuários, um deles até pagou. E aí começou: o app fica lento com 200 registros, dois clientes enxergaram dados um do outro, ninguém tem coragem de mexer em nada porque qualquer mudança quebra outra coisa, e a IA que escreveu tudo agora se perde no próprio código.

A resposta curta, e ela não é a que você está esperando: o problema quase nunca é a qualidade do código gerado. É que o gerador foi otimizado para a demo funcionar, não para a operação sobreviver. São dois objetivos diferentes, e o segundo nunca esteve no prompt.

Isso também significa que a reação mais comum — "vou jogar fora e reescrever do zero" — costuma ser a decisão mais cara e mais arriscada disponível. Existe um caminho melhor, e ele começa com um diagnóstico honesto.

Por que a demo funciona e a operação não

Uma ferramenta de geração otimiza para você ver algo funcionando na tela o mais rápido possível. Para isso ela toma, silenciosamente, um conjunto de decisões que são perfeitamente racionais em um protótipo e perfeitamente fatais em produção:

• Estado no lugar errado. Lógica de negócio que deveria estar no servidor fica no cliente, porque no cliente aparece mais rápido na tela.
• Sem modelo de isolamento. O conceito de "cliente A não pode ver dado do cliente B" não existe até alguém pedir explicitamente. Ninguém pede na primeira semana.
• Banco sem histórico. Tabelas criadas direto, sem migrations. Você não consegue reproduzir, reverter ou versionar o estado do banco.
• Feliz caminho apenas. O que acontece quando o pagamento falha, o upload trava no meio ou o usuário aperta duas vezes? Não foi gerado, porque não aparece na demo.
• Zero testes. E sem testes, cada alteração é uma aposta. É por isso que você tem medo de mexer.
• Arquivos gigantes. Componentes de mil linhas que a própria IA não consegue mais editar com precisão, porque o contexto estourou.

Nada disso é incompetência da ferramenta. É o resultado esperado de uma ferramenta pedida para mostrar algo funcionando. O erro humano foi tratar o resultado como produto em vez de tratar como maquete — muito bem feita, mas maquete.

A pergunta certa não é "esse código é bom?". É "quais dessas decisões são reversíveis e quais não são?".

O diagnóstico em 4 camadas

Antes de decidir qualquer coisa, passe pelas quatro camadas nesta ordem. Ela não é arbitrária: vai da mais irreversível para a mais barata de arrumar.

Camada 1 — Dados (a única verdadeiramente irreversível)

Código se reescreve em semanas. Dado corrompido, vazado ou perdido não volta.

Verifique, nesta ordem:

• Isolamento entre clientes. Se dois clientes usam o sistema, existe alguma regra no banco que impeça um de ler o outro? Não vale "o frontend só mostra os dele" — isso não é isolamento, é decoração. Em Postgres, isso é Row Level Security ou filtro obrigatório no servidor.
• Migrations. Existe histórico versionado do schema? Se a resposta for "eu fui criando as tabelas pela interface", você não tem como recriar seu banco nem voltar atrás.
• Backup testado. Não "existe backup". Você já restaurou um? Backup nunca restaurado é backup imaginário.
• Integridade. Chaves estrangeiras, campos obrigatórios, unicidade. Sem isso, o banco acumula lixo silencioso que só aparece seis meses depois, num relatório errado.
• Dado sensível. Tem CPF, dado de saúde, documento? Onde está, quem acessa, está cifrado? LGPD não pergunta quem escreveu o código.

Camada 2 — Segurança e acesso

• Chaves e segredos. Alguma chave de API está no código que vai para o navegador? Abra o DevTools do seu próprio app e procure. É o achado mais comum e o mais caro.
• Autorização de verdade. O servidor valida quem pode fazer o quê, ou confia no que o cliente mandou? Se um usuário trocar um ID na requisição, ele acessa o dado de outro?
• Endpoints expostos. Toda rota de API exige autenticação, ou existe alguma aberta "só por enquanto"?
• Rate limiting. Existe algo impedindo alguém de chamar seu endpoint caro dez mil vezes? Se seu app usa LLM, essa conta chega rápido.

Camada 3 — Arquitetura

• Lógica de negócio duplicada entre cliente e servidor — e divergindo.
• Acoplamento com a plataforma. Seu app roda fora de onde ele foi gerado? Se a resposta for não, você não tem um produto, tem uma assinatura.
• Tamanho dos arquivos. Arquivos que nem a IA consegue mais editar direito são o sinal mais objetivo de que a estrutura precisa ser quebrada.
• Dependências. Quantas bibliotecas entraram sem ninguém decidir? Alguma está sem manutenção há anos?

Camada 4 — Operação

• Você sabe quando quebra? Existe monitoramento de erro, ou você descobre pelo WhatsApp do cliente?
• Você consegue voltar atrás? Deploy tem rollback, ou subir errado significa consertar às pressas em produção?
• Você sabe quanto custa? Principalmente com IA no meio: consumo por usuário, teto de gasto, alerta.

Sintoma, causa e o que isso custa

O que você sente	Causa provável	Irreversível?	Urgência
Cliente viu dado de outro	Sem isolamento no banco	Sim — o vazamento já ocorreu	Agora
App lento com poucos dados	Consulta sem índice, dados buscados no cliente	Não	Alta
Medo de alterar qualquer coisa	Sem testes, sem tipagem, arquivos gigantes	Não	Alta
Conta de IA explodindo	Sem rate limit nem teto de gasto	Não (mas o dinheiro foi)	Agora
A IA não consegue mais editar	Arquivos grandes demais para o contexto	Não	Média
Não consigo sair da plataforma	Acoplamento com serviços proprietários	Não, mas fica mais caro a cada mês	Média
Perdi dado e não recuperei	Backup inexistente ou nunca testado	Sim	Agora

Os dois Sim da coluna do meio são a razão pela qual o diagnóstico começa pelos dados. Todo o resto é trabalho; aqueles dois são dano.

Consertar, extrair ou reescrever?

Esta é a decisão que vale dinheiro, e ela tem critério objetivo — não precisa ser no feeling.

Conserte no lugar se: o produto tem usuários pagando, o problema está concentrado em pontos identificáveis (isolamento de dados, uma consulta lenta, uma chave exposta) e você consegue nomear o que está errado. É o caso mais comum, de longe.

Extraia por partes se: o produto funciona mas está preso à plataforma onde nasceu, ou a estrutura atrapalha o dia a dia. Você tira um pedaço por vez — primeiro o banco, depois a API, depois a interface — mantendo tudo no ar.

Reescreva do zero apenas se: não há usuários reais ainda e o modelo de dados está fundamentalmente errado para o que o produto virou. São duas condições simultâneas. Com usuários em produção, reescrita completa é a forma mais eficiente conhecida de passar seis meses sem entregar nada enquanto o produto antigo apodrece.

A regra que a gente aplica em todo projeto de modernização: produto com cliente pagando não para. A substituição acontece por baixo, em pedaços, com os dois mundos convivendo durante a transição.

O caminho de saída, em quatro fases

Se o diagnóstico apontou extração, esta é a sequência que funciona sem derrubar o produto:

1. Estanque o sangramento

   Antes de qualquer melhoria estrutural, resolva só o que é dano: fechar o isolamento entre clientes, rotacionar chaves expostas, ligar backup e testar a restauração, colocar teto de gasto no que consome IA. Isso é questão de dias, não de meses, e é sempre o primeiro passo.

2. Ganhe visibilidade

   Monitoramento de erro, log estruturado e alerta básico. Você não consegue migrar com segurança um sistema cujo comportamento você não enxerga. Esta fase parece burocrática e é a que mais economiza tempo depois.

3. Tire o banco de dentro da plataforma

   Os dados são o ativo; o resto é substituível. Banco gerenciado próprio, migrations versionadas desde o estado atual, integridade e índices no lugar. A partir daqui você deixou de ser refém.

4. Substitua por fatias, com os dois no ar

   Escolha o fluxo mais crítico, reconstrua ele com teste, direcione o tráfego e só então vá para o próximo. Nunca um big bang. O produto continua funcionando o tempo inteiro, e cada fatia entregue já é valor — se o projeto parar no meio por qualquer motivo, o que foi feito continua valendo.

O que manter do vibe coding (porque não é sobre abandonar IA)

Seria desonesto escrever este artigo fingindo que a solução é voltar a escrever tudo à mão. Não é — e a gente usa IA pesadamente na própria operação.

O que muda não é a ferramenta, é o que você exige dela:

• Geração continua ótima para a interface e para o primeiro rascunho. Tela, componente, formulário, transformação de dado: use e abuse.
• Arquitetura, modelo de dados e fronteira de segurança são decisão humana. Peça para a IA implementar a decisão, não tomá-la. A diferença entre "faça um sistema de permissões" e "implemente estas cinco regras de permissão neste modelo" é a diferença entre os dois artigos que você poderia estar lendo.
• Teste automatizado deixa de ser opcional e vira o que torna a IA segura. Com suíte de testes, você aceita uma alteração gerada porque a suíte passou. Sem ela, cada alteração é fé.
• Arquivos pequenos são requisito técnico agora. Módulo pequeno e bem nomeado é o que mantém o código editável por IA. Estrutura boa virou infraestrutura de produtividade.

A maturidade aqui é simples de enunciar e difícil de praticar: a IA acelera a execução de decisões que já estão certas, e acelera igualmente o estrago de decisões erradas.

Checklist: seu MVP aguenta receber cliente pagante?

Marque o que já é verdade hoje:

• Um cliente não consegue ver dado de outro, validado no banco e não no frontend
• Nenhuma chave de API aparece no que é enviado ao navegador
• O servidor valida permissão em toda rota, sem confiar no cliente
• Existe backup automático e você já restaurou um de verdade
• O schema do banco está versionado em migrations
• O fluxo que gera receita tem teste automatizado
• Você é avisado de erro em produção antes do cliente avisar
• Deploy tem rollback em um comando
• Existe teto de gasto e alerta no que consome IA ou infraestrutura
• O app roda fora da plataforma onde foi gerado
• Dado pessoal está mapeado e tratado conforme a LGPD
• Existe alguém, além da IA, que entende como o sistema funciona

Menos de oito marcados significa que a próxima prioridade do produto não é a próxima funcionalidade. Enquanto isso, se quiser um retrato rápido do que qualquer visitante já enxerga do lado de fora — performance, SEO, mobile, cabeçalhos — o Raio-X do Site roda isso de graça em 10 segundos.

Perguntas Frequentes

Código gerado por IA serve para produção?

Serve, desde que passe pelas decisões que a geração não toma sozinha: isolamento de dados entre clientes, autorização validada no servidor, migrations versionadas, tratamento de erro e testes automatizados no fluxo que gera receita. O código em si costuma ser adequado; o que falta é a camada de arquitetura e operação, que precisa ser especificada por uma pessoa.

Devo reescrever meu MVP do zero ou consertar o que existe?

Reescreva do zero apenas se duas condições forem verdadeiras ao mesmo tempo: não há usuários reais ainda e o modelo de dados está fundamentalmente errado para o que o produto se tornou. Com clientes em produção, o caminho de menor risco é substituir por fatias, mantendo o sistema atual no ar enquanto cada fluxo é reconstruído.

Por que meu app fica lento com poucos usuários?

As causas mais comuns em produtos gerados por IA são consultas sem índice no banco, busca de dados completos no cliente para filtrar depois na tela, e chamadas em cascata onde uma tela dispara dezenas de requisições em sequência. São problemas de consulta e de onde o trabalho acontece, não de infraestrutura — trocar de servidor raramente resolve.

O que é multi-tenancy e por que meu MVP provavelmente não tem?

Multi-tenancy é a capacidade de servir vários clientes na mesma aplicação com isolamento garantido entre os dados de cada um. Ferramentas de geração não implementam isso por padrão porque não aparece na demo: com um usuário de teste, um sistema sem isolamento parece idêntico a um sistema com isolamento. A diferença só aparece quando o segundo cliente entra.

Como saber se meu MVP está preso à plataforma onde foi gerado?

Faça o teste direto: tente rodar a aplicação e o banco fora da plataforma. Se o app depende de serviços proprietários de autenticação, banco ou hospedagem que não têm equivalente exportável, você tem acoplamento. Tirar o banco para uma instância gerenciada própria costuma ser o primeiro passo — e o que mais reduz o risco.

Quanto tempo leva para tirar um MVP gerado por IA da zona de risco?

A fase de estancar o sangramento — isolamento de dados, chaves expostas, backup testado, teto de gasto — costuma ser questão de dias. A extração completa da plataforma e a reconstrução por fatias dos fluxos críticos acontece em ciclos de semanas, com o produto no ar o tempo todo. O prazo depende de quantos fluxos são críticos, não do tamanho do código.

O momento certo de trazer gente de fora

Tem um ponto específico em que insistir sozinho fica mais caro do que pedir ajuda, e ele é fácil de reconhecer: quando você já não consegue nomear o que está errado. Enquanto o problema tem nome — "essa consulta está lenta", "falta permissão nessa rota" — você resolve com IA e paciência. Quando vira "está tudo estranho e eu não sei por onde começar", o gargalo deixou de ser execução e virou diagnóstico.

Na Alienhub a gente faz exatamente essa travessia: pega produto que nasceu rápido — gerado por IA, no-code ou escrito às pressas — e leva para uma base que aguenta cliente pagante, sem parar o que já está funcionando. Começa sempre pelo diagnóstico das quatro camadas, e frequentemente a conclusão é que dá para salvar bem mais do que o founder imaginava.

Se você reconheceu seu produto em algum ponto deste artigo, fala com a gente — ou veja como conduzimos modernização de sistemas e arquitetura.