Do protótipo de IA ao produto em produção: checklist

O gap entre demo e produto

Um protótipo gerado por IA impressiona em minutos e engana pela aparência de produto pronto: a interface funciona, os fluxos principais respondem, tudo parece terminado. O gap entre essa demo e um produto que aguenta usuários reais mora no que não aparece em uma demonstração de cinco minutos: o que acontece quando dois usuários acessam ao mesmo tempo, quando um deles tenta acessar dados de outro, quando o banco de dados cresce, quando uma chave de API vaza, quando o servidor reinicia no meio de uma operação. Nenhuma dessas situações aparece em uma tela de pitch, e todas elas aparecem na primeira semana de produção com usuários de verdade.

Este artigo é um checklist prático das frentes que precisam de auditoria e ajuste entre “a IA gerou um protótipo funcional” e “esse produto está pronto para receber tráfego real”. Não é uma lista de tudo que pode dar errado, é o mínimo que qualquer projeto de Vibe Coding deveria revisar antes do lançamento.

Trate essa auditoria como uma etapa formal do projeto, com tempo reservado no cronograma, não como algo para encaixar nas horas que sobrarem antes do lançamento. Times que pulam essa etapa por pressa costumam descobrir os problemas do jeito mais caro possível: em produção, com clientes reais afetados, em vez de em um ambiente controlado de revisão.

Auditoria do código gerado: por onde começar

Antes de revisar linha por linha, mapeie a estrutura geral: quais camadas o código separa (interface, regras de negócio, acesso a dados), onde ficam as rotas que lidam com dados sensíveis e quais partes do sistema foram geradas com menos contexto (normalmente as que a IA produziu no início da conversa, antes de entender o projeto inteiro). Código gerado em sessões longas e misturadas tende a ter convenções inconsistentes entre arquivos diferentes, o que é um sinal de que aquela parte merece atenção redobrada.

Priorize a auditoria pelas rotas que envolvem autenticação, dados de pagamento, upload de arquivo e qualquer endpoint que aceite entrada do usuário sem validação visível. Essas são as áreas onde falhas geradas por IA tendem a ser mais graves, porque o código “funciona” no teste manual do caminho feliz e esconde brechas que só aparecem sob uso adverso ou malicioso. Procure também trechos de código duplicados ou redundantes, comuns quando a IA resolve o mesmo problema de formas diferentes em telas diferentes: além de aumentar o risco de inconsistência, dificultam a manutenção.

Uma prática útil nessa etapa é pedir para outra pessoa, que não participou da geração do código original, revisar as partes mais sensíveis. Quem gerou o código junto com a IA tende a confiar mais nele por familiaridade, mesmo sem perceber. Um segundo olhar, vindo de alguém acostumado a procurar falhas de segurança e de lógica, encontra problemas que passam despercebidos por quem já viu aquele código dezenas de vezes durante a construção.

Banco de dados: do rascunho ao schema de verdade

Bancos de dados gerados rapidamente por IA tendem a favorecer o que funciona no protótipo, não o que escala: campos sem tipo definido com precisão, ausência de índices em colunas consultadas com frequência, relações entre tabelas sem restrições de integridade e, com frequência, ausência de isolamento claro entre dados de clientes diferentes em produtos multi-tenant. Nenhum desses problemas trava a demo, mas todos eles custam caro para corrigir depois que o banco já tem dados reais.

A revisão de schema antes de produção deveria confirmar: se os tipos de dado fazem sentido para o volume esperado, se existem índices nas colunas usadas em filtros e buscas frequentes, se as relações entre tabelas têm as restrições corretas (chaves estrangeiras, restrições de unicidade onde fazem sentido) e se existe uma estratégia de migração de schema que não trave o sistema quando for preciso alterar uma tabela em produção.

Backup automático, com teste periódico de restauração, entra nessa lista como item não negociável, não como “próximo passo depois que o produto crescer”. Detalhamos esse assunto com mais profundidade no artigo sobre banco de dados em projetos de Vibe Coding.

Autenticação e autorização

Essa é, na prática, a frente onde código gerado por IA mais falha de forma silenciosa. Autenticação (confirmar quem é o usuário) costuma funcionar bem, porque é um fluxo padronizado e bem documentado que a IA reproduz com confiança. Autorização (definir o que cada usuário pode ver e fazer) é onde os problemas aparecem: é comum encontrar protótipos em que qualquer usuário logado consegue acessar o registro de outro usuário só trocando um identificador numérico na URL, porque a checagem de propriedade do dado nunca foi implementada.

A auditoria dessa frente deveria testar, de forma explícita, tentativas de acesso cruzado: um usuário autenticado tentando ler, editar ou apagar um registro que pertence a outro usuário, em cada rota relevante do sistema. Revise também se papéis diferentes (usuário comum, administrador, dono de conta) têm de fato permissões diferentes aplicadas no servidor, não apenas escondidas na interface: esconder um botão na tela não impede alguém de chamar a rota diretamente.

Segredos, chaves e variáveis de ambiente

Chaves de API, tokens de serviços externos e credenciais de banco de dados precisam viver fora do código que roda no navegador e fora do repositório versionado. É comum que protótipos gerados rapidamente coloquem uma chave direto em um arquivo de configuração do lado do cliente, porque naquele momento “só precisava funcionar”. Antes de produção, essa revisão é obrigatória: nenhuma chave sensível deveria aparecer no código-fonte que chega ao navegador do usuário, e variáveis de ambiente de desenvolvimento nunca deveriam se misturar com as de produção.

Revise também o histórico de commits em busca de chaves que tenham sido versionadas em algum momento e depois removidas do código atual: remover do arquivo não remove do histórico do controle de versão, e uma chave exposta em um commit antigo continua exposta até ser revogada e trocada.

Testes: o mínimo digno

Cobertura de teste completa não é realista nem necessária para todo MVP, mas existe um mínimo que separa um produto responsável de um produto arriscado: testes automatizados (ou, no mínimo, um roteiro de teste manual disciplinado) para os fluxos que envolvem dinheiro, dados sensíveis e autenticação. Esses são os pontos onde um bug silencioso custa mais caro, seja financeiramente, seja em confiança do usuário.

Além dos testes de caminho feliz, teste deliberadamente os caminhos de erro: o que acontece quando a rede cai no meio de uma operação, quando um formulário recebe dado inválido, quando duas requisições concorrentes tentam alterar o mesmo registro ao mesmo tempo. Código gerado por IA tende a lidar bem com o caminho feliz e mal com esses cenários de borda, porque eles raramente aparecem no prompt original usado para gerar a funcionalidade.

Deploy e monitoramento

Colocar em produção envolve mais do que publicar o código: exige domínio próprio com certificado SSL configurado, variáveis de ambiente de produção separadas das de desenvolvimento, monitoramento de erros que avise quando algo quebra e monitoramento de disponibilidade que avise quando o sistema fica fora do ar. Sem isso, o time só descobre que algo quebrou quando um cliente reclama, o que é tarde demais para um produto que já cobra por assinatura.

Tenha também um plano de rollback definido antes do primeiro deploy real: se uma atualização quebrar algo em produção, o time precisa conseguir voltar para a versão anterior rapidamente, sem depender de descobrir a causa do problema em tempo real sob pressão. Esse tipo de disciplina de deploy e operação é justamente o que separa um projeto que só “está no ar” de um projeto pronto para escalar, tema que aprofundamos no artigo sobre colocar um projeto Lovable em produção, com um passo a passo aplicável além dessa ferramenta específica.

Quando refazer vale mais que consertar

Nem todo protótipo vale a pena corrigir peça por peça. Quando a auditoria revela que a estrutura de dados inteira precisa mudar (por exemplo, um modelo que não suporta multi-tenancy sendo usado para um produto que precisa disso desde o primeiro cliente), ou que a arquitetura geral mistura camadas de forma tão profunda que qualquer mudança pequena quebra partes não relacionadas, geralmente é mais rápido e mais barato refazer a base com o aprendizado do protótipo do que tentar consertar por cima de uma fundação errada.

O sinal mais claro de que vale refazer é quando cada correção pontual introduz um novo bug em outro lugar do sistema: isso indica acoplamento estrutural, não um problema isolado. Nesses casos, um time com experiência real em colocar produto em produção consegue avaliar rapidamente se vale a pena reconstruir a base de dados e a arquitetura, aproveitando a interface e a lógica de negócio já validadas no protótipo, o que costuma ser bem mais rápido do que recomeçar do zero.

Essa decisão costuma gerar desconforto, porque parece jogar fora trabalho já feito. Mas vale lembrar que o protótipo já cumpriu sua função mais importante: validar que a ideia funciona e que existe caminho de interface e de fluxo que faz sentido para o usuário. Refazer a fundação técnica aproveitando esse aprendizado não é recomeçar do zero, é construir a segunda versão, mais sólida, sobre o que a primeira já ensinou.

Conclusão

O caminho do protótipo gerado por IA até um produto pronto para produção passa por um conjunto conhecido de frentes: auditoria de código, banco de dados sólido, autenticação e autorização corretas, segredos protegidos, testes mínimos dos fluxos críticos e um processo de deploy com monitoramento de verdade. Nenhuma dessas frentes é opcional para quem pretende cobrar de usuários reais, e todas elas são exatamente o tipo de trabalho que separa quem só gera código com IA de quem entrega produto pronto para produção.

Se o seu protótipo já existe e você precisa de um time para revisar essas frentes e destravar o caminho até produção com segurança, converse com a MVP Plus sobre o Vibe Squad.