Vibe coding saiu do protótipo: como levar um app feito com IA para produção

25 de set. de 2026

Notebook representando um app criado com IA indo para produção

Criar a primeira versão deixou de ser a parte mais difícil. O verdadeiro divisor aparece quando o projeto passa a receber usuários reais, armazenar dados e executar operações que não podem depender apenas de “parece estar funcionando”.

É nessa transição que vibe coding e produção deixam de ser apenas uma discussão sobre velocidade. O código pode ter sido gerado em minutos, mas o sistema ainda precisa responder perguntas que um protótipo normalmente ignora: quem pode acessar cada registro, onde estão as chaves, o que acontece quando uma integração falha e como recuperar os dados depois de um erro.

A Vercel informou que mais de 50% dos deployments observados em setembro de 2026 já eram iniciados por coding agents. Agentes não estão apenas criando demos: já participam do caminho até produção. O desafio é construir um processo de revisão à altura dessa velocidade.

Protótipo e produção resolvem problemas diferentes

Um protótipo tenta responder se a ideia funciona e se alguém deseja usá-la. Produção adiciona dados persistentes, usuários com permissões diferentes, operações irreversíveis, integrações instáveis, custos variáveis e incidentes que precisam ser investigados.

Antes do deploy, a pergunta não deveria ser apenas “está funcionando?”. Pergunte: funciona de forma previsível quando algo dá errado ou alguém tenta usar fora do caminho esperado?

1. Crie um mapa real da aplicação

Liste frontend, backend, banco, autenticação, storage, funções, filas, webhooks e serviços externos. Registre onde cada segredo está armazenado e quais componentes possuem acesso à produção.

Peça à IA uma explicação da arquitetura, mas confirme no código e nos painéis dos provedores. Agentes podem descrever o que pretendiam construir em vez do que ficou configurado.

Um mapa simples encontra pontos esquecidos: função administrativa exposta, bucket público, chave privilegiada no navegador ou webhook sem validação.

Seu sistema foi criado com IA?
Organizei em um guia o processo que utilizo para revisar acessos, banco, RLS, chaves, APIs e outros pontos antes do deploy.
Security IA — Guia pré-deploy
R$19,90
Conhecer o guia →

2. Separe autenticação de autorização

Autenticação confirma a identidade. Autorização define o que essa identidade pode fazer. Estar logado não significa poder ler todos os registros ou executar uma ação administrativa.

Teste o sistema com usuário comum, administrador de organização e operador interno. Para cada perfil, tente alterar o identificador na URL, chamar APIs diretamente, consultar dados de outra organização e acessar arquivos privados pelo link.

Em Supabase, políticas de Row Level Security aplicam regras perto dos dados. Mas RLS desligado, políticas amplas ou uma chave de serviço no lugar errado anulam essa proteção.

3. Mantenha segredos fora do cliente

Qualquer variável enviada ao navegador deve ser tratada como pública. Chaves privadas, tokens administrativos, credenciais de banco e segredos de webhook pertencem ao servidor.

Se uma chave apareceu em commit, prompt, captura ou log, considere-a comprometida. Remover do arquivo não basta: revogue ou rotacione.

Aplique menor privilégio. Uma integração que só lê pedidos não precisa alterar usuários nem apagar tabelas.

4. Valide dados e operações no servidor

Validação no frontend melhora a experiência, mas pode ser contornada. O servidor deve verificar formato, tamanho, identidade, permissão e estado atual antes de aceitar uma operação.

Isso é essencial em pagamentos, convites, mudança de plano, uploads e envio de e-mails. Use idempotência quando uma requisição repetida não puder criar resultados duplicados.

Está construindo com IA? Antes de colocar usuários reais no sistema, faça uma revisão pré-deploy. Conheça o Security IA.

5. Planeje volume, abuso e custo

Em produção, pessoas clicam duas vezes, abrem várias abas e repetem requisições. Bots fazem isso em escala.

Implemente rate limiting em login, recuperação de senha, formulários, APIs públicas e IA. Defina limites por usuário e organização, tamanho máximo de entrada, tempo de execução e orçamento.

6. Revise dependências e ações da IA

Verifique quais pacotes foram instalados, por que são necessários, quem mantém o projeto e quais scripts executam durante a instalação. Agentes podem sugerir nomes inexistentes ou parecidos com bibliotecas legítimas.

Mantenha o lockfile versionado e revise alterações. Veja segurança em dependências npm.

7. Prepare observabilidade, backup e rollback

Confirme que erros chegam a um painel, que requisições possuem identificadores e que existem alertas para fluxos críticos. Observabilidade precisa reconstruir o que aconteceu sem registrar senhas ou tokens.

Backup só está validado depois de um teste de restauração. Rollback só é real se a equipe sabe retornar à versão anterior sem improvisar durante um incidente.

Checklist de produção para app feito com IA

Ambientes separados.
Autenticação e autorização testadas com múltiplos perfis.
RLS e regras de storage revisadas.
Segredos no servidor e com menor privilégio.
Validação e idempotência nas operações críticas.
Rate limiting e limites financeiros.
Dependências, scripts e lockfile revisados.
Logs, alertas, backups e rollback testados.

Criar ficou mais rápido. Revisar ficou mais importante. Antes de publicar, revise quem acessa o quê, quais dados estão expostos e quais regras realmente são executadas.

Antes de publicar seu sistema

Se este conteúdo fez você perceber que existem pontos do seu projeto que nunca foram revisados, esse é exatamente o objetivo do Security IA.
O guia reúne meu processo de revisão em um checklist direto ao ponto para você aplicar no seu próprio projeto.
Acessar por R$19,90 →