Vibe coding em produção: onde o protótipo trava e o que fazer a respeito

Existe um momento previsível em toda empresa que adotou vibe coding. Alguém — muitas vezes fora do TI — constrói em dois dias uma aplicação que resolve um problema real. A demonstração impressiona. A diretoria aprova. E aí a pergunta muda de "isso funciona?" para "isso pode entrar em produção?".

É onde a conversa trava. Não porque o protótipo seja ruim, mas porque produção cobra um conjunto de coisas que a fase de descoberta não precisou responder.

O que muda quando há usuário real

A diferença entre demonstração e operação raramente está na funcionalidade. Está no entorno:

• Identidade e permissão. Quem entra, com qual perfil, e o que cada perfil pode ver. Login improvisado não sobrevive à primeira revisão de segurança.
• Integração com o que já existe. A aplicação corporativa quase nunca vive sozinha: precisa falar com ERP, CRM, base de conhecimento e o diretório de identidade, respeitando o controle de acesso vigente.
• Dado de verdade. Prototipar com dado real de cliente é comum e quase nunca passou por base legal, avaliação de fornecedor ou previsão contratual.
• Continuidade. Backup, plano de recuperação, monitoramento e alguém de plantão quando quebra às onze da noite.
• Evolução. Alguém precisa conseguir ler, testar e mudar o que foi gerado daqui a um ano, quando quem prototipou já mudou de área.

Nenhum desses itens é exótico. Todos são o padrão de qualquer software corporativo — e é exatamente por isso que o protótipo trava: ele não foi construído para respondê-los.

Os três impasses estruturais

1. O ambiente é do fornecedor

A maioria das plataformas de vibe coding gera e executa a aplicação dentro do próprio ambiente. Isso é ótimo para começar e problemático para operar: auditar o que está rodando, atender exigência de residência de dado ou mudar de fornecedor deixam de ser decisões da empresa.

A pergunta que resolve esse ponto é simples e vale fazer cedo: se amanhã eu quiser sair, o que eu levo comigo? Se a resposta não for "o código", há dependência estrutural.

2. Ninguém governa o que a IA gerou

Empresas que investiram em governança de IA costumam ter política, guardrails e trilha de auditoria para o uso de IA — o que as pessoas perguntam ao modelo. Poucas estenderam isso ao que é construído com IA.

O resultado é uma assimetria estranha: um colaborador é impedido de colar um documento sensível num chat, mas uma aplicação inteira gerada por prompt entra em produção sem passar por revisão equivalente.

3. Falta o que vem depois do "funciona"

Vibe coding entrega velocidade até o ponto em que o problema deixa de ser gerar código e passa a ser arquitetura, integração, performance sob carga e segurança. Esse ponto chega mais cedo do que a demonstração sugere.

O que não é solução

Duas reações comuns pioram a situação.

A primeira é proibir. Bloquear a ferramenta não elimina a necessidade que levou a pessoa a usá-la — apenas empurra o uso para fora do radar, o que já discutimos em shadow AI.

A segunda é fingir que o protótipo é produto. Colocar em produção sem identidade, integração e continuidade funciona por algumas semanas e cobra a conta no primeiro incidente — geralmente com dado de cliente envolvido.

O caminho que funciona: fases com critérios diferentes

A saída é reconhecer que descoberta e produção são fases distintas, com critérios distintos, e que a ferramenta certa muda entre elas.

Na descoberta, velocidade vale mais que governança. Plataformas de vibe coding de mercado — Lovable entre elas — são a escolha certa, e a NOBUG trabalha com elas justamente por isso. O objetivo é descobrir rápido se a ideia se sustenta.

Na produção, o critério inverte: controle, integração, residência de dado e continuidade passam à frente da velocidade. É onde entra o NOBUG CODE — a mesma agilidade de construir por prompt, mas executando na nossa infraestrutura, com dado no Brasil, sob a governança de IA da empresa e com o código entregue ao cliente.

O erro não é usar vibe coding. É usar o critério da descoberta quando o problema já é de produção.

Um teste de cinco perguntas

Antes de aprovar a ida de um protótipo para produção, vale responder:

• Quem é o dono do código, e ele está versionado em repositório da empresa?
• Onde o dado fica, e isso atende à exigência regulatória do nosso setor?
• Qual política de IA se aplica ao que foi construído, e como isso é verificado?
• Com quais sistemas internos ele precisa falar, e isso foi desenhado ou improvisado?
• Quem responde quando parar de funcionar?

Protótipo que responde as cinco está pronto. Protótipo que não responde nenhuma não está atrasado — está apenas em outra fase, e tratá-lo como produto é o que gera dívida.